On Thu, Apr 2, 2020 at 4:31 PM Lukas Wunner <lukas@xxxxxxxxx> wrote: > > 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@xxxxxxxxx> wrote: > > > On Thu, 2 Apr 2020 13:39:25 +0200 Lukas Wunner <lukas@xxxxxxxxx> 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. I guess if someone is bored they could port the internal vgaswitcheroo mux drivers over to that mux subsystem. But we'll still need some amount of graphics specific glue, and that seems perfectly reasonable to have in vgaswitcheroo.c. That stuff isn't about a mux, but the hand-off between the involved gpu (and audio) drivers, to me it doesn't make sense to push all these kind of interactions into a generic mux subsystem. That also applies to the extensions discussed here to better handle per-output muxing between drivers (like the self refresh trick for seamless muxing). That's all graphics, and in practice already possible with the hw vgaswitcheroo supports today (apple does that already in macos). No change on the mux driver side needed at all I think. so tldr I guess if you want add a todo entry to look into porting vgaswitcheroo drivers to the mux framework. But imo that would be orthogonal to what we're discussing here. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
