Hi all,
Some time ago, I asked some questions about how to handle issues with DRM drivers attempting to touch eDP while muxed away, due to implicit assumptions about eDP being permanently connected. I've proposed some changes which prevent eDP access on switched-away eDP outputs for at least i915, but now I'd like to follow up on one of the topics that was brought up during that previous conversation: namely, how to deal with systems with multiple mux devices, where it may be desirable to address the muxes independently of each other. Currently, the apple-gmux driver seems to support multiple muxes by just switching them in sync with each other, exposing only one logical mux device to the vga-switcheroo subsystem to control both physical muxes.
Since then, I've proposed a driver for a mux that is present on some upcoming notebook designs, some of which have distinct muxes for internal and external display connections [1]. I don't believe any of these systems are available publicly just yet, but it's only a matter of time before they are. During the previous discussion, I believe Daniel Vetter stated that the ability to address multiple muxes is something that could be addressed when designing a "proper" userspace API for vga-switcheroo (i.e., not debugfs), so I'd like to get the conversation started on how we could go about designing this API.
On Wed, Sep 02, 2020 at 12:50:18PM -0500, Daniel Dadap wrote:
Hi all,
Some time ago, I asked some questions about how to handle issues with DRM drivers attempting to touch eDP while muxed away, due to implicit assumptions about eDP being permanently connected. I've proposed some changes which prevent eDP access on switched-away eDP outputs for at least i915, but now I'd like to follow up on one of the topics that was brought up during that previous conversation: namely, how to deal with systems with multiple mux devices, where it may be desirable to address the muxes independently of each other. Currently, the apple-gmux driver seems to support multiple muxes by just switching them in sync with each other, exposing only one logical mux device to the vga-switcheroo subsystem to control both physical muxes.
Since then, I've proposed a driver for a mux that is present on some upcoming notebook designs, some of which have distinct muxes for internal and external display connections [1]. I don't believe any of these systems are available publicly just yet, but it's only a matter of time before they are. During the previous discussion, I believe Daniel Vetter stated that the ability to address multiple muxes is something that could be addressed when designing a "proper" userspace API for vga-switcheroo (i.e., not debugfs), so I'd like to get the conversation started on how we could go about designing this API.
I think roughly the pieces we need:
- exposing each mux in sysfs somehow, probably needs a new class for these. We probably also want some flags and stuff about how the mux works, if that has userspace visible impact. Stuff like whether the mux is delayed (gpu level mux wait for all users to close, and iirc your new driver even waits for a reboot), or immediate (I think the display muxes work like that, i.e. gpu will immediate get some hotplug notification and active use will not stop the switch). - add links from each drm connector (those are already in sysfs) to the mux controlling it. - for muxes that also control the entire gpu power supply I think we also want a link from the overall drm device to the mux, so that userspace can realize it'll whack the entire gpu if it touches that mux.
Locking for all this is likely going to be a nightmare, and I have no idea what it should look like :-/
I'm also not sure whether anything like the above already exists and would make sense to reuse for e.g. the mux class. -Daniel
[1] https://patchwork.kernel.org/patch/11751453/
dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
dri-devel@lists.freedesktop.org
-
Daniel Dadap -
Daniel Vetter