Arch Linux

The package build configuration for libdrm is inappropriate.

The current state at https://gitlab.archlinux.org/archlinux/packaging/packages/libdrm/-/blob/88a638bcc7f4212e6b8691ec4f7751222e32d429/PKGBUILD#L28 has build flag "udev" set to false. This is based on https://bugs.archlinux.org/task/57851 where a complaint was raised about dependencies.

Now, the udev build flag in libdrm does not control inclusion of _dependencies_ (any more?), but solely controls the strategy used to acquire a file descriptor for a DRM device (see, ultimately, https://gitlab.freedesktop.org/mesa/drm/-/blob/6acadd495c30678f603c69b8bca456aa3cc8bf38/xf86drm.c#L851)

The following rules apply:
* udev == false: classic mknod dance
* udev == true: polling for udevd creating the device

With Archlinux being a systemd-based distribution, including udevd, building with udev == false is inappropriate.

This most likely has impact the moment that udevd really kicks in - for instance when eGPUs appear on the bus, somehow, or with physical GPUs partitioned into virtual cards or render devices.

At the moment, Archlinux does work with the existing build configuration, in my use case - but, again, this is technically not appropriate.

Do note, though, that switching to "udev == true" may come with unexpected consequences: This local system is a VMware Workstation 17.5 virtual machine. This system has performance properties which causes starting of X11 applications to be delayed. This delay is rooted in Xorg being run rootless, hence some of the logic inside libdrm exhibits undesirable performance behaviour. A recent change on libdrm (https://gitlab.freedesktop.org/mesa/drm/-/commit/4b51e34d1ade77bd5dbd185bf08fb96e993db549) made this even worse - on VMware Workstation!

See https://bugzilla.redhat.com/show_bug.cgi?id=2249838 for some background where I root-caused that for Fedora Linux 39; the linked forum post has additional detail.

Deciding whether or not to keep the inappropriate build configuration is left to the maintainer :)