[Intel-gfx] [PATCH 1/2] drm/core: Preserve the framebuffer after removing it.

Tvrtko Ursulin tvrtko.ursulin at linux.intel.com
Thu Sep 10 02:07:41 PDT 2015


On 09/09/2015 08:06 PM, Daniel Vetter wrote:
> On Wed, Sep 9, 2015 at 6:36 PM, Tvrtko Ursulin
> <tvrtko.ursulin at linux.intel.com> wrote:
>> I am not even going that far, just talking about last frame stuck on screen.
>> For me making that easier is a regression.
>
> So let's look at various systems:
> - super-modern fbdev less system: logind keeps a dup of every
> master-capabel drm fd. Compositor crashing won't ever result in
> close() getting called since logind still has its copy. Cleanup needs
> to be done manually anyway with the system compositor.
> - Current systems: Compositor restarts and cleans up the mess we left behind.

What if the compositor doesn't restart? Or logind crashes in the former 
case?

Maybe I don't understand something, but I don't see how it is not quite 
bad to expect userspace to clean up the kernel structures after the 
previous userspace client.

What happens if something keeps crashing leaving framebuffers around?

If the only reason is to avoid modeset, why SETPLANE with NULL fb to 
disable planes associated with a framebuffers to be released wouldn't work?

Regards,

Tvrtko


More information about the dri-devel mailing list