On Thu, Apr 2, 2020 at 2:58 PM Pekka Paalanen <ppaala...@gmail.com> wrote: > > On Thu, 2 Apr 2020 13:39:25 +0200 > Lukas Wunner <lu...@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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
