Re: Switching to udev?

[Alyssa Ross <hi@alyssa.is>]

[-- Attachment #1: Type: text/plain, Size: 4621 bytes --]

Demi Marie Obenour <demiobenour@gmail.com> writes:

> On 7/26/25 06:06, Alyssa Ross wrote:
>> Demi Marie Obenour <demiobenour@gmail.com> 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]