How to handle disconnection of eDP panels due to dynamic display mux switches

[Daniel Vetter]

On Thu, Apr 2, 2020 at 2:58 PM Pekka Paalanen <ppaalanen at gmail.com> wrote:
>
> On Thu, 2 Apr 2020 13:39:25 +0200
> Lukas Wunner <lukas at wunner.de> wrote:
>
> > Note that vga_switcheroo is currently controlled via debugfs.
> > That is a historic artefact.  The kernel has since gained a
> > mux subsystem in drivers/mux/ which could be used to represent
> > the display mux in a standardized way in regular sysfs.
>
> Hi,
>
> if mux control was in sysfs, then how would userspace figure out
> which mux state refers to which DRM device and its connector?
>
> Maybe some DRM connector property referring to the mux and its state?
>
> How would a display server running as a regular user gain access to
> sysfs to control the mux?

I think a sysfs interface for vgaswitcheroo would need some kind of
links from drm_device (and for the outpu-only mux from drm_connector
sysfs files) to the corresponding sysfs directory for the
vgaswitcheroo switch.

But actual change of state needs to indeed be done through some other
interface, since sysfs interfaces suck for compositors. We have this
problem already with backlight, and the solution there is a special
backlight frobbing services which compositors can call through udev,
and fun stuff like that. Definitely not an uapi pattern we want to
repeat. So I think sysfs would be only for information links, and
maybe the global switch for the old optimus designs where you can only
switch the entire gpu, and need to delay the switch until all existing
clients are closed. Aka 1) stop compositor 2) write to sysfs 3) start
new compositor on new gpu. For that case compositors don't need to
ever write to sysfs themselves, so I think that's ok. Also only
relevant for rather old hw.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch