elogind service starts after sound device initialization, causing permission failures

Display Manager: SDDM
Desktop: KDE Plasma

On a fresh Void Linux installation with elogind, sound devices are created with incorrect permissions at boot, making them inaccessible to logged-in users. This occurs because elogind starts via D-Bus activation after udev has already processed sound devices.

Current Behavior:
At boot (before login):
crw------- 1 root root 116, 12 /dev/snd/controlC0

After manual udev trigger:
crw-rw----+ 1 root audio 116, 12 /dev/snd/controlC0

Void Linux ships elogind with only D-Bus activation enabled (/usr/share/dbus-1/system-services/org.freedesktop.login1.service)

No runit service is enabled by default (/var/service/elogind does not exist)

Boot sequence

1. udev processes sound devices early in boot
2. udev rules tag devices with uaccess (via /usr/lib/udev/rules.d/70-uaccess.rules
3. elogind helper (/usr/libexec/elogind/elogind-uaccess-command) should set ACLs
4. BUT elogind is not running yet (D-Bus hasn't activated it)
5. Devices get root:root 600 permissions
   User logs in → D-Bus now activates elogind → Too late, devices already processed

Sound devices remain inaccessible until manual udevadm trigger --subsystem-match=sound

Attempted Solutions:
ln -s /etc/sv/elogind /var/service/

Service fails to start because /etc/sv/elogind/run contains sv check dbus >/dev/null || exit 1, which fails with permission errors for non-root users. Meanwhile, D-Bus still auto-activates elogind, creating a conflict.

Option 2: Disable D-Bus activation + enable service

mv /usr/share/dbus-1/system-services/org.freedesktop.login1.service
/usr/share/dbus-1/system-services/org.freedesktop.login1.service.disabled
ln -s /etc/sv/elogind /var/service/

Result: SDDM fails to start resulting in no graphical login.

Any workarounds essentially lead me to either using rc.local with sleep and retrigger of udevadm, which is frankly a very bad solution, or rewriting the /etc/sv/sddm/run which I frankly think I shouldn't be doing.

I am not sure if this is even the correct repo to report this to, but this seems like a very obscure timing bug that should be probably looked into. If i am doing something wrong or have any suggestions how to fix this please let me know.

Start by reading /etc/sv/elogind/run and /usr/share/dbus-1/system-services/org.freedesktop.login1.service, then inspect how /etc/sv/sddm/run depends on elogind and D-Bus. Reproduce the boot sequence and compare device permissions before and after udevadm trigger --subsystem-match=sound. Done means elogind starts reliably early enough for sound-device ACLs without breaking SDDM or creating a D-Bus/service conflict.