From: Demi Marie Obenour <demiobenour@gmail.com>
To: Spectrum OS Development <devel@spectrum-os.org>
Subject: Switching to udev?
Date: Wed, 23 Jul 2025 13:34:56 -0400 [thread overview]
Message-ID: <aefe36d5-2924-439e-b093-be78d0de7fa0@gmail.com> (raw)
[-- 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 --]
next reply other threads:[~2025-07-23 17:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-23 17:34 Demi Marie Obenour [this message]
2025-07-23 18:59 ` Switching to udev? Demi Marie Obenour
2025-07-26 10:06 ` Alyssa Ross
2025-07-27 21:36 ` Demi Marie Obenour
2025-07-29 7:29 ` Alyssa Ross
2025-07-29 7:48 ` Demi Marie Obenour
2025-08-20 17:11 ` Alyssa Ross
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aefe36d5-2924-439e-b093-be78d0de7fa0@gmail.com \
--to=demiobenour@gmail.com \
--cc=devel@spectrum-os.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://spectrum-os.org/git/crosvm
https://spectrum-os.org/git/doc
https://spectrum-os.org/git/mktuntap
https://spectrum-os.org/git/nixpkgs
https://spectrum-os.org/git/spectrum
https://spectrum-os.org/git/ucspi-vsock
https://spectrum-os.org/git/www
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).