On Wed, Jan 4, 2017 at 12:30 AM, Daniel Vetter <daniel@xxxxxxxx> wrote: > On Wed, Dec 21, 2016 at 12:13:06PM -0600, vcaputo@xxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/dri-devel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel