illiliti
add SOUND_INITIALIZED property and pipewire fix
Adds the SOUND_INITIALIZED property Pipewire looks for when adding sound cards and re-reverts (everts?) https://github.com/illiliti/libudev-zero/commit/4510b27a9b589a0ce82fef776c2648e19e79f2a4 so it can find card[0-9].
Fixes #26 without patching Pipewire.
- [ ] Should
scan_devicesbe rewritten so it starts its search at/sys/class/sound? Adding the parent inadd_devicefeels weird.
It's for the Git master (it doesn't apply to the tagged 1.0.3 due to #62).
If we add this special handling, does it mean that any future requests that introduce more special cased code but for a different property should be added as well? Considering that there is no guarantee that pipewire won't depend on some yet another obscure property someday, I afraid going that route will turn this project into "support pipewire at all cost". Personally, I'd rather stay sensible and support minimal subset of properties enough to run desktop even if that means not supporting some app by default.
Well, it'd mean not supporting sound in ANY flatpak program, and it'd also mean no support for most games, web browsers and such. I think it is okay as long as it is kept track of. Adding small tweaks that make such big projects work is okay with me.
Would reworking this PR into a generic "fetch properties from a directory" patch work? Then users can select whether they want to support SOUND_INITIALIZED (or even all the sucky additional properties that are redundant with pci.ids and other files) without bloating libudev-zero itself.
(I still think SOUND_INTIALIZED is not that bad of an idea; it does solve a race condition when hotplugging devices, and saves audio software from having to check the creation of controlC themselves).
How would this "fetch properties from a directory" work? I'm not sure I follow, but I think everyone'd be happy if Libudev-zero could actually replace udev (without breaking one of the most important functionalities of udev, handling audio)