From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx <intel-gfx@lists.freedesktop.org>,
dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH 1/2] drm/core: Preserve the framebuffer after removing it.
Date: Thu, 10 Sep 2015 10:07:41 +0100 [thread overview]
Message-ID: <55F1485D.8060805@linux.intel.com> (raw)
In-Reply-To: <CAKMK7uHqCEf3x7xUdPYCtuMSp8g41P=uoT0Q7Z-MhkicX5z5cg@mail.gmail.com>
On 09/09/2015 08:06 PM, Daniel Vetter wrote:
> On Wed, Sep 9, 2015 at 6:36 PM, Tvrtko Ursulin
> <tvrtko.ursulin@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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2015-09-10 9:07 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-09 14:40 [PATCH 0/2] Preserve framebuffer during rmfb / drm fd close Maarten Lankhorst
2015-09-09 14:40 ` [PATCH 1/2] drm/core: Preserve the framebuffer after removing it Maarten Lankhorst
2015-09-09 14:51 ` Tvrtko Ursulin
2015-09-09 15:04 ` [Intel-gfx] " Daniel Vetter
2015-09-09 15:18 ` Tvrtko Ursulin
2015-09-09 15:29 ` [Intel-gfx] " Daniel Vetter
2015-09-09 15:47 ` Tvrtko Ursulin
2015-09-09 15:56 ` [Intel-gfx] " Daniel Vetter
2015-09-09 16:03 ` Tvrtko Ursulin
2015-09-09 16:07 ` Daniel Vetter
2015-09-09 16:15 ` Tvrtko Ursulin
2015-09-09 16:26 ` Maarten Lankhorst
2015-09-09 16:36 ` Tvrtko Ursulin
2015-09-09 19:06 ` [Intel-gfx] " Daniel Vetter
2015-09-10 9:07 ` Tvrtko Ursulin [this message]
2015-09-10 9:56 ` Daniel Vetter
2015-09-10 10:15 ` Tvrtko Ursulin
2015-09-22 14:53 ` David Herrmann
2015-09-22 15:21 ` Tvrtko Ursulin
2015-10-01 16:04 ` [Intel-gfx] " Vincent ABRIOU
2015-09-09 15:02 ` Daniel Vetter
2015-09-22 14:43 ` David Herrmann
2015-09-09 14:40 ` [PATCH 2/2] drm/core: Preserve the fb id on close Maarten Lankhorst
2015-09-22 14:55 ` David Herrmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55F1485D.8060805@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.