Switching to udev?

Demi Marie Obenour
2025-07-23T17:35:18Z

[-- Attachment #1.1.1: Type: text/plain, Size: 1829 bytes --]

I'm seriously wondering if Spectrum should switch from mdevd to udev.
It's where all of the upstream device detection work happens, and
it would avoid needing to statically configure sound devices for
PipeWire.

The current PipeWire patch statically creates devices. This works
for VMs because VMs are statically configured and only have virtio
devices. This was also the most challenging part of the effort,
and I still had to guess some of the parameters. Supporting hotplug
would require either a custom PipeWire module, a custom daemon that
talked to PipeWire, keeping pw-cli running in interactive mode,
or patches to PipeWire to make device lingering work.

In the audio case, ALSA expects device paths of the form
hw:card:device:subdevice. However, I don't believe card numbers are
stable: they reflect the order in which the kernel enumerates devices,
and that is not at all guaranteed. A VM that only has a virtio sound
device will only ever have card 0, device 0, and subdevice 0, so
hard-coding hw:0,0,0 is fine. This is not true if physical hardware
is present. That requires a lot of device identification logic, and
all of the upstream work on that is in udev or the systemd hardware
database (which udev also uses).

In the future, there may be other projects Spectrum wants to use that
rely on udev for enumerating devices. Some of them might *only* support
PipeWire and have no other means of configuration. Even if other means
of configuration *exist*, I expect them to be very rarely used by
upstream and thus poorly tested.

tl;dr: you can get away without udev in VMs, but I expect problems
with physical hardware, and I want to switch to udev as a preemptive
measure to avoid those problems and to ease development.