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?expan...
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
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
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@lists.freedesktop.org
-
Daniel Vetter -
Stéphane Marchesin -
vcaputo＠pengaru.com