Demi Marie Obenour <demiobenour@gmail.com> writes:
On 7/29/25 03:29, Alyssa Ross wrote:
Demi Marie Obenour <demiobenour@gmail.com> writes:
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/db1e099a7aed117e3ffdb1e4c69cf3e37cab... 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.
Okay, I read through the git log of hwdb.d/60-input-id.hwdb, and it does seem like these quirks will be important for Spectrum users, e.g. https://gitlab.freedesktop.org/libinput/libinput/-/issues/932#note_2069967 Maybe if we manage to move stuff like input handling or even the compositor out of the host system, we can go back to something smaller like we have now, but until then I suppose systemd-udevd is the way to go on the host.