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 subsystem in the kernel will automatically acquire DRM master status on an fd opened against a card, if no other fd open against that card is already a DRM master. * DRI cards do have a human-readable identifier -- the "name" field reported by drmGetVersion() -- which can be used to reliably identify them. But this name is not exposed as a sysfs attribute on the device. So it's invisible to UDev rules. * DRI cards initialize in parallel to each other, so the basic kernel names such as 'card0', 'card1', and similar are not stable.
On a system with multiple cards with each one used by a separate compositor application, this makes it a bit difficult to start each compositor only when its specific card is enumerated in UDev a bit tricky.
* The lack of a sysfs property exposing the drmGetVersion()->name field, makes phrasing a UDev rule directly such as this impossible:
SUBSYSTEM=="drm", ATTRS{name}=="amd", SYMLINK+="card-amd", TAG+="systemd"
* You could imagine writing a helper program invoked by the UDev rule:
SUBSYSTEM=="drm", PROGRAM="print-dri-symlink-name $env{DEVNAME}" SYMLINK+="%c", TAG+="systemd"
The "print-dri-symlink-name" program would be responsible for using the libdrm API to fetch out the card's "name" property.
* But it is not guaranteed that UDev rules fire only once for a given sysfs device. Which means that the next bullet point applies.
* The UDev helper program temporarily acquires DRM master status because of that built-in behavior from the DRI subsystem. If you're unlucky, this will conflict with the compositor's legitimate attempt to become DRM master.
If the systemd .device unit (e.g. dev-dri-card-amd.device) activated by the initial UDev rule firing is already up and running, and a second UDev rule instance executes at the same time that a compositor application is just starting up, there is a small but feasible chance that the UDev helper program will acquire DRM master rights during exactly the duration that the compositor is attempting its own initializer. The compositor will therefore be denied DRM master status, and fail.
I'm not really sure how the race in the final bullet point can be prevented. It seems to me that the only ironclad way to avoid it would be to perform the UDev rule matches strictly based on sysfs attributes. Has there ever been any talk about exporting the DRI card name through sysfs?
On the other hand, maybe I'm approach this problem completely wrongly. Is it a losing game to try to phrase systemd ordering constraints on /dev/dri cards?
-Matt