[PATCH v2] drm/fb-helper: Call drm_fb_helper_hotplug_event() when releasing drm master

[Daniel Vetter]

On Thu, Nov 18, 2021 at 11:23:32AM +0100, Michel Dänzer wrote:
> On 2021-11-08 17:00, Daniel Vetter wrote:
> > On Mon, Nov 08, 2021 at 04:34:53PM +0100, Jocelyn Falempe wrote:
> >> When using Xorg/Logind and an external monitor connected with an MST dock.
> >> After disconnecting the external monitor, switching to VT may not work,
> >> the (internal) monitor sill display Xorg, and you can't see what you are
> >> typing in the VT.
> >>
> >> This is related to commit e2809c7db818 ("drm/fb_helper: move deferred fb
> >> checking into restore mode (v2)")
> >>
> >> When switching to VT, with Xorg and logind, if there
> >> are pending hotplug event (like MST unplugged), the hotplug path
> >> may not be fulfilled, because logind may drop the master a bit later.
> >> It leads to the console not showing up on the monitor.
> >>
> >> So when dropping the drm master, call the delayed hotplug function if
> >> needed.
> >>
> >> v2: rewrote the patch by calling the hotplug function after dropping master
> >>
> >> Signed-off-by: Jocelyn Falempe <jfalempe at redhat.com>
> > 
> > Lastclose console restore is a very gross hack, and generally doesn't work
> > well.
> > 
> > The way this is supposed to work is:
> > - userspace drops drm master (because drm master always wins)
> > - userspace switches the console back to text mode (which will restore the
> >   console)
> > 
> > I guess we could also do this from dropmaster once more (like from
> > lastclose), but that really feels like papering over userspace bugs. And
> > given what a massive mess this entire area is already, I'm not eager to
> > add more hacks here.
> > 
> > So ... can't we fix userspace?
> 
> Sounds like the good old UMS days, when VT switching relied on user space doing the right things in the right order.
> 
> With KMS, surely the kernel needs to be able to get to a known good
> state from scratch when it's in control of the VT, no matter what state
> user space left things in.

Unfortunately not. When your in KD_GRAPHICS mode we explicitly tell fbcon
to shut up and not restore itself, and it shouldn't ever do that.

And afaik there's not really a holder concept for KD_TEXT/GRAPHICS, unlike
the drm master which signifies ownership of kms resources.

Which sucks ofc, but fixing this would mean we need to retrofit ownership
into VT somehow, so that ownership is auto-dropped like drm_master on
close()/exit(). Not sure that's possible without breaking uapi (e.g. with
logind I think it's logind also doing the KD_TEXT/GRAPHICS dance, but
didn't check).

But if we'd have some kind of real ownership for KD_GRAPHICS then we could
tie that to the implied/weak drm_master status of fbdev emulation and make
this work correctly. But as-is the kernel simply doesn't have enough
information to dtrt. Or at least I'm not seeing how exactly, without just
trying to make guesses what userspace wants to do.

Either way I think we need to really clearly spell out how this is all
supposed to work, and not just add random bandaids justified with "works
for me". It is already a byzantine mess as-is.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch