RFC: fb restore on drm master close

RFC: fb restore on drm master close

[vcaputo]

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!

Regards,
Vito Caputo


1. https://github.com/vcaputo/rototiller
2. https://github.com/torvalds/linux/compare/master...vcaputo:masterclose?expand=1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: RFC: fb restore on drm master close

[Daniel Vetter]

On Wed, Dec 21, 2016 at 12:13:06PM -0600, vcaputo@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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: RFC: fb restore on drm master close

[Stéphane Marchesin]

On Wed, Jan 4, 2017 at 12:30 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Wed, Dec 21, 2016 at 12:13:06PM -0600, vcaputo@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?

One case where it's useful not to do this is the handoff from a splash
screen to a display server.

Stéphane

>>
>> 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
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: RFC: fb restore on drm master close

[vcaputo]

On Wed, Jan 04, 2017 at 12:38:04AM -0800, St??phane Marchesin wrote:
> On Wed, Jan 4, 2017 at 12:30 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> > On Wed, Dec 21, 2016 at 12:13:06PM -0600, vcaputo@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?
> 
> One case where it's useful not to do this is the handoff from a splash
> screen to a display server.
> 

If the handoff is avoiding the existing lastclose semantics somehow by
having overlapping opens, couldn't drmDropMaster() be employed to avoid
the masterclose restore when the splash screen closes?

Regards,
Vito Caputo
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel