Hi Pekka,
Those are fair answers. In my case, it does happen that the configuration
available on the virtual cards includes a way to set distinct names reported by
drmGetVersion()->name.
It looks like the consensus is that UDev rules probably shouldn't be consulting
the name as a
On Wed, 22 Sep 2021 16:16:48 +
"Hoosier, Matt" wrote:
>
> 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
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 trying to find a robust way to handle the phrasing of UDev rules and
systemd dependencies about /dev/dri/cardXXX nodes to ensure that several
compositor services running on different graphics cards of a device all can
reliably start up.
First, some basic observations:
* The DRM
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
