On 7/29/25 03:29, Alyssa Ross wrote: > Demi Marie Obenour writes: > >> On 7/26/25 06:06, Alyssa Ross wrote: >>> Demi Marie Obenour writes: >>> >>>> On 7/23/25 13:34, Demi Marie Obenour wrote: >>>> From https://wiki.gentoo.org/wiki/Mdev: >>>> >>>> - udev is needed to load firmware for AMD Radeon GPUs. >>>> - libusb will not see USB devices unless deprecated kernel >>>> configuration options are set. >>>> >>>> From https://wayland.freedesktop.org/libinput/doc/latest/architecture.html: >>>> >>>> - Wayland compositors use udev (via libinput) to support >>>> device hotplugging. This is needed for USB keyboard >>>> and/or mouse support, which is a hard requirement for >>>> desktops that don't have PS/2 connectors (almost all of >>>> them I believe). >>>> - libinput relies on udev to determine what kind of device >>>> an input device is. >>>> >>>> FreeBSD also switched to udev for Mutter. >>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271824#c4 >>>> states that for Wayland, udev is essentially required. Even >>>> Gentoo uses udev, though systemd is not the default init >>>> system. >>>> >>>> I think avoiding udev is a losing battle in the long run, >>>> except possibly for VMs that will never ever have physical >>>> hardware attached to them. That would require configuring >>>> VMs with and without physical hardware separately, which >>>> I would strongly prefer to avoid. If the memory >>>> consumption or disk space requirements of udev are >>>> excessive, I think this would be better addressed as part >>>> of a broader debloating effort. >>>> >>>> libudev-zero does exist, but it doesn't work with PipeWire >>>> (https://github.com/illiliti/libudev-zero/issues/26, still >>>> unfixed despite being closed) and there are other problems >>>> with it as shown by its issue tracker. Alpine's wiki doesn't >>>> recommend it for desktop environments, and while Spectrum VMs >>>> don't run full desktop environments they do run desktop >>>> software. Such software requires udev more and more nowadays. >>> >>> Broadly it seems like no libudev at all (which was never on the table) >>> is being conflated with not using udevd (but using something like >>> libudev-zero) here. To my knowledge, everything you've outlined should >>> work with libudev-zero, with the exception of PipeWire as you point out, >>> and possibly Radeon firmware loading — I'm very surprised udev would be >>> involved at all in that process so wondering if the wiki is very out of >>> date or something. We have USB input working on the host using >>> libudev-zero, for example. >>> >>> The PipeWire compatibility problems do seem like blockers, but reading >>> the PipeWire issue about it[1], I'm not sure they're fundamental. It >>> sounds like PipeWire might be willing to accomodate a fix, the last >>> activity on the issue was only a month ago, and it doesn't sound like >>> that big of a change is necessary for it to work. I wouldn't be >>> surprised if PipeWire is among the software that has the most complex >>> interaction patterns with udev, and given it might be on the verge of >>> being fixed, I'd prefer to wait and see a bit longer. If that means >>> that we don't have working audio hotplug or whatever in the meantime, >>> that's okay. I've put the PipeWire issue on the upstream bug tracking >>> board[2]. If months go by and no solution is found, I think it would >>> make sense to evaluate switching to systemd-udevd then, but I don't want >>> to do the switch, and then find a weak later that the only firm reason >>> we had for doing it has been solved. If you know about other software >>> that depends on custom udev properties, and isn't on the verge of being >>> fixed like PipeWire is, or if I'm wrong about Radeon, we could also take >>> that into account now, but so far all we know for sure is that PipeWire >>> doesn't work, but might do quite soon. >>> >>> [1]: https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/2398#note_2897989 >>> [2]: https://cryptpad.fr/kanban/#/2/kanban/view/yLtGXWLV6U7X5+Z1ay+oXKZMrSacqQe+51nXZYRh3ck/ >> >> I think libudev-zero can work fine in the VMs that have no physical >> hardware, especially with flatpaks that can't access udev at all. >> It's the host and VMs with physical hardware we don't have, and thus >> cannot test, that I am concerned about. systemd-udevd is much more >> likely to have gotten a patch from someone else to fix an issue we >> would never run into ourselves, and which might well cost us a user. > > Does udev upstream quirk a lot of hardware, then? That wasn't mentioned > so far. See https://github.com/systemd/systemd/tree/db1e099a7aed117e3ffdb1e4c69cf3e37cab0fc6/hwdb.d and the systemd issues that have the "hwdb" label. I'm not sure how much of this is just for human-friendly names and how much of actually affects behavior, but at least the input device quirks seem relevant. -- Sincerely, Demi Marie Obenour (she/her/hers)