Re: RFC: fb restore on drm master close

["Stéphane Marchesin" <stephane.marchesin@gmail.com>]

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