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

[Lukas Wunner]

On Thu, Apr 02, 2020 at 03:13:26PM +0200, Daniel Vetter wrote:
> 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.
> >
> > 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.

Yes, that would be one way to do it.


> 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.

There's an in-kernel interface in <linux/mux/consumer.h> which
could be invoked from, say, an ioctl(), to control or query the
mux.

I'm not really prepared to answer detailed questions how it should
be done, my point is just that the existing building blocks (such
as the mux subsystem) should be used instead of reinventing the
wheel.  If the mux subsystem lacks specific features needed for
graphics muxes, I think adding them won't face much opposition
from Peter Rosin.

Thanks,

Lukas