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.