Switching to udev?

Switching to udev?

[Demi Marie Obenour]

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

I'm seriously wondering if Spectrum should switch from mdevd to udev.
It's where all of the upstream device detection work happens, and
it would avoid needing to statically configure sound devices for
PipeWire.

The current PipeWire patch statically creates devices.  This works
for VMs because VMs are statically configured and only have virtio
devices.  This was also the most challenging part of the effort,
and I still had to guess some of the parameters.  Supporting hotplug
would require either a custom PipeWire module, a custom daemon that
talked to PipeWire, keeping pw-cli running in interactive mode,
or patches to PipeWire to make device lingering work.

In the audio case, ALSA expects device paths of the form
hw:card:device:subdevice.  However, I don't believe card numbers are
stable: they reflect the order in which the kernel enumerates devices,
and that is not at all guaranteed.  A VM that only has a virtio sound
device will only ever have card 0, device 0, and subdevice 0, so
hard-coding hw:0,0,0 is fine.  This is not true if physical hardware
is present.  That requires a lot of device identification logic, and
all of the upstream work on that is in udev or the systemd hardware
database (which udev also uses).

In the future, there may be other projects Spectrum wants to use that
rely on udev for enumerating devices.  Some of them might *only* support
PipeWire and have no other means of configuration.  Even if other means
of configuration *exist*, I expect them to be very rarely used by
upstream and thus poorly tested.

tl;dr: you can get away without udev in VMs, but I expect problems
with physical hardware, and I want to switch to udev as a preemptive
measure to avoid those problems and to ease development.
-- 
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 --]

Re: Switching to udev?

[Demi Marie Obenour]

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

On 7/23/25 13:34, Demi Marie Obenour wrote:
> I'm seriously wondering if Spectrum should switch from mdevd to udev.
> It's where all of the upstream device detection work happens, and
> it would avoid needing to statically configure sound devices for
> PipeWire.
> 
> The current PipeWire patch statically creates devices.  This works
> for VMs because VMs are statically configured and only have virtio
> devices.  This was also the most challenging part of the effort,
> and I still had to guess some of the parameters.  Supporting hotplug
> would require either a custom PipeWire module, a custom daemon that
> talked to PipeWire, keeping pw-cli running in interactive mode,
> or patches to PipeWire to make device lingering work.
> 
> In the audio case, ALSA expects device paths of the form
> hw:card:device:subdevice.  However, I don't believe card numbers are
> stable: they reflect the order in which the kernel enumerates devices,
> and that is not at all guaranteed.  A VM that only has a virtio sound
> device will only ever have card 0, device 0, and subdevice 0, so
> hard-coding hw:0,0,0 is fine.  This is not true if physical hardware
> is present.  That requires a lot of device identification logic, and
> all of the upstream work on that is in udev or the systemd hardware
> database (which udev also uses).
> 
> In the future, there may be other projects Spectrum wants to use that
> rely on udev for enumerating devices.  Some of them might *only* support
> PipeWire and have no other means of configuration.  Even if other means
> of configuration *exist*, I expect them to be very rarely used by
> upstream and thus poorly tested.
> 
> tl;dr: you can get away without udev in VMs, but I expect problems
> with physical hardware, and I want to switch to udev as a preemptive
> measure to avoid those problems and to ease development.

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.
-- 
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 --]

Re: Switching to udev?

[Alyssa Ross]

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

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/

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

Re: Switching to udev?

[Demi Marie Obenour]

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

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.
-- 
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 --]

Re: Switching to udev?

[Alyssa Ross]

[-- 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 --]

Re: Switching to udev?

[Demi Marie Obenour]

[-- 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 --]

Re: Switching to udev?

[Alyssa Ross]

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

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/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.

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.

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