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.

-Matt

On 9/22/21, 10:29 AM, "Simon Ser" <cont...@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.

Reply via email to