https://bugs.kde.org/show_bug.cgi?id=523256
Bug ID: 523256
Summary: Volume keys from a USB headset adapter's HID interface
adjust the default sink instead of the headset's own
sink
Classification: Plasma
Product: plasmashell
Version First master
Reported In:
Platform: Ubuntu
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: Audio Volume widget
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected]
Target Milestone: 1.0
DESCRIPTION
The Poly BT700 (047f:02e6, paired with a Poly Voyager Focus 2 headset) is
a composite USB device: a USB audio class interface plus a HID
consumer-control interface for the on-headset volume buttons.
The adapter's button behavior is state-dependent:
- When its audio interface is idle/suspended, the buttons adjust the
headset's volume locally in firmware. No evdev events are emitted
(verified with `libinput debug-events` and `evtest`).
- When a stream is active on the device, the firmware stops adjusting
volume locally and instead emits generic KEY_VOLUMEUP / KEY_VOLUMEDOWN
HID events, delegating volume control to the host. This matches the
behavior of the same hardware on Windows, where the OS routes those
events back to the originating device's audio endpoint, so the headset
volume changes.
On Plasma, those events are handled as the global Increase/Decrease
Volume shortcuts and applied to the default audio device (in my case, desktop
speakers). The headset's own volume in KDE is never touched.
Practical impact: the buttons misroute during exactly the situations a
headset is used for. Any softphone call (Teams, Zoom, etc.) holds the
mic/playback streams open for its duration, so for the whole call the
headset's volume buttons change the speaker volume and there is no way
to adjust the headset volume from the headset.
The device-active trigger was confirmed via the Audio Volume
applet/settings window itself: its peak meters open a capture stream on
the adapter's mic, which resumes the suspended node and flips the
firmware into host-controlled mode.
I understand KWin and kglobalaccel are not at fault here (the key event
is delivered faithfully, and the global shortcut API carries no
source-device information), and that a complete fix may belong in
PipeWire/WirePlumber (associating HID volume events from a composite
USB audio device with that device's node).. Filing here as
well since the user-visible symptom is in Plasma's volume handling.
STEPS TO REPRODUCE
1. Connect a Poly BT700 adapter (with paired headset). Leave the
default sink set to a different output (e.g. desktop speakers).
2. Activate a stream on the adapter. Easiest reproduction: open the
Audio Volume applet or the Audio page in System Settings, whose peak
meters open a capture stream on the device. A softphone call
reproduces it identically.
3. Press the volume up/down buttons on the headset.
OBSERVED RESULT
- The default sink (speakers) volume changes.
- The headset sink's volume is unchanged (its slider never moves), and
the headset's local volume-change feedback tones are absent.
- `libinput debug-events` shows the adapter emitting key events, e.g.:
-event14 KEYBOARD_KEY +8.673s KEY_VOLUMEUP (115) pressed
event14 KEYBOARD_KEY +8.675s KEY_VOLUMEUP (115) released
- With no stream active on the device, no evdev events are emitted at
all and the headset adjusts its own volume in firmware (feedback
tones audible), which is the expected behavior.
EXPECTED RESULT
Volume key events originating from an audio device's own HID interface
should adjust that device's sink, not the default sink -- matching the
behavior of the same hardware on Windows.
SOFTWARE/OS VERSIONS
Operating System: Kubuntu 26.04 LTS
KDE Plasma Version: 6.6.5
KDE Frameworks Version: 6.24.0
Qt Version: 6.10.2
ADDITIONAL INFORMATION
- Kernel: 7.0.0-28-generic (64-bit), Graphics Platform: Wayland
- PipeWire 1.6.2 (libpipewire 1.6.2)
- Headset: Poly Voyager Focus 2 via Poly BT700 USB adapter
(lsusb: 047f:02e6 Plantronics, Inc. Poly BT700)
- Related (not duplicate) reports filed under the retired plasma-pa
product: Bug 365771, Bug 456310 -- both concern volume keys targeting
the default device, but neither covers the composite-device HID
delegation described here.
--
You are receiving this mail because:
You are watching all bug changes.
