Re: Switching to udev?

[Demi Marie Obenour <demiobenour@gmail.com>]

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

On 7/29/25 03:29, Alyssa Ross wrote:
> 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.

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)

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]