Multiple DRI card detection in compositor systemd units
Matt.Hoosier at garmin.com
Wed Sep 22 16:16:48 UTC 2021
I get the intuition behind the suggestion to aggregate using logind seats, as far as it goes. But it still seems to me that this just pushes the question back: how do you identify which card is which in order to assign it to a seat? Normally this is done using udev rules, right? Additionally, I'm working with some constraints that not all of the compositors are logind-aware. I realize that's not really your problem, and it doesn't really influence the merits of your suggestion.
The /dev/dri/by-path idea works, I suppose, if you have different physical graphics cards. In my case, that's not true. These are virtualized cards that the silicon vendor's DRM drivers use to expose different subsets of DRM resources as different cards. So there's only one /dev/dri/by-path card here. Think: DRM leases, but with the lessees popping out as card nodes rather than arranged dynamically using the drm ioctl()'s to manufature leases.
The use-case here is to allow separate DRM domains for each of several containers. It's not really desirable to try to funnel everybody's graphics through a common compositor that runs all the connectors.
Thanks for the thoughts.
On 9/22/21, 10:29 AM, "Simon Ser" <contact at emersion.fr> wrote:
CAUTION - EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.
Maybe try creating multiple physical seats with logind, and start each
compositor on its own seat? A physical seat is a collection of devices like
DRM nodes and evdev device files.
Also udev creates files in /dev/dri/by-path/, these should be stable across
reboots. `udevadm settle` before a compositor start-up can wait for udev to
finish its job.
Out of curiosity, can you explain your use-case? Why do you need to start
multiple compositors, each on its own GPU?
CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.
More information about the wayland-devel