RFC: fb restore on drm master close
Daniel Vetter
daniel at ffwll.ch
Wed Jan 4 08:30:23 UTC 2017
On Wed, Dec 21, 2016 at 12:13:06PM -0600, vcaputo at pengaru.com wrote:
> Hello list,
>
> I've been playing with an unaccelerated drm program[1] and have been
> annoyed that whenever this program exits the fbcon isn't restored, with
> the display left completely off.
>
> This seems to happen because Xorg is still running from a different VT.
>
> Upon further investigation, it seems like the fb restore only occurs on
> "lastclose", which explains what I'm observing.
>
> Why don't we perform the fb restore whenever the current master is
> closed to cover this case, since masters are the ones that can change
> modes?
>
> My github has a quick-n-dirty i915 implementation[2] which seems to fix
> this without negative effects, though I haven't exhaustively tested to
> see what breaks.
>
> This isn't a list I subscribe to so please CC me directly in any
> replies, thanks everyone!
The fbdev restore on lastclose was just a "oops, my X died and I have a
black screen now" debug aid. Apps are supposed to restore fbdev themselves
by switching back to text mode using KD_TEXT, which I think forces the
modeset.
In general though the fbdev vs. kms interaction is very ill-defined and
mostly boils down to fbdev staying out of the way if anyone even might be
using the native drm interfaces. We have the drm_fb_helper_is_bound check,
but it's not used consistently either.
Long story short, the answer to your question is "because no one yet
thought this through", and I'm not clear at all what we should be doing
here (if anything). I'm not sure whether your patch is the right approach,
one issue it definitely has is that it only updates i915.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
More information about the dri-devel
mailing list