The virtual DualSense wore a placeholder USB serial no real pad has #307
Assignees
FernandoMX
HitFrostbite
enricobuehler (Enrico Bühler)
kszlim
luxus
nannku
neoney
sassycrown
Clear assignees
FernandoMX
HitFrostbite
enricobuehler (Enrico Bühler)
kszlim
luxus
nannku
neoney
sassycrown
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: unom/punktfunk#307
Reference in New Issue
Block a user
One functional line:
dev.unset_serial_number().UsbDevice::defaultin the vendored usbip server fillsiSerialNumberwith the placeholder string"Serial". A real DualSense reports none — this file's own doc comments assert that twice — and ALSA bakes the value into the card id, so the virtual pad presents as:where the hardware gives
…DualSense_Wireless_Controller-00. PipeWire carries the difference into every node name and intodevice.serial, and udev into every/dev/input/by-id/entry.Clearing it makes every name a matcher can key on byte-identical to a physical pad's.
Scope — this fixes nothing that is currently broken
Stating that plainly, because the commit was written under a wrong hypothesis and it would be easy to read more into it.
It was authored while the
_Serialinfix was a suspect for the dead DualSense haptics. It is not the cause. GE-Proton's winepulse leg has since been observed matchingwith the placeholder still present, so nothing depends on this today. The actual haptics defects were fixed in #291.
It is also not a fix for UCM profile selection, which was my first reading:
alsa-ucm-confkeys on${CardComponents}(USB054c:0ce6), soDualSense-PS5.confmatched with the placeholder present. Which profile a card lands on is decided by verb priority, not by its name. The code comment records that so it does not get re-derived.What is left is removing a gratuitous difference from real hardware, on a device whose entire purpose is to be indistinguishable from one.
Gate
cargo clippy -p pf-inject --all-targets -- -D warningsinpunktfunk-rust-ci:latest(linux/amd64) — exit 0.Behavioural verification is thin by nature: the change alters only descriptor strings, and the pad was already enumerating and binding correctly with the placeholder. Reasonable to reject on the grounds that it is churn.
`UsbDevice::default` in the vendored server fills iSerialNumber with the string "Serial". A real DualSense reports none — this file's own doc comments assert that twice — and ALSA bakes the value into the card id, so the pad presented as `…DualSense_Wireless_Controller_Serial-00` where the hardware gives `…DualSense_Wireless_Controller-00`. PipeWire then carries the difference into every node name and into `device.serial`. Clearing it makes every name a matcher can key on byte-identical to a physical pad's. Scope, honestly: this is fidelity, not a fix for anything currently broken. It was written when the `_Serial` infix was a suspect for the dead haptics; it is not the cause. GE-Proton's winepulse leg has since been observed matching `alsa_output.usb-Sony_Interactive_Entertainment_DualSense_Wireless_Controller_Serial-00.Default__Speaker__sink` with the placeholder present, so nothing depends on this today. It removes a gratuitous difference from real hardware rather than fixing a symptom. Also NOT a fix for UCM profile selection, though that was my first reading: `alsa-ucm-conf` keys on `${CardComponents}` (`USB054c:0ce6`), so `DualSense-PS5.conf` matched with the placeholder still present. Which profile a card lands on is decided by verb priority, not by its name. The comment records that so it is not re-derived. Gated with `cargo clippy -p pf-inject --all-targets -- -D warnings` in `punktfunk-rust-ci:latest` (linux/amd64): exit 0.