When building feature controls from a unit without a name, we try to derive a name first from the feature unit's input, then fall back to the output terminal. If a feature unit connects directly to a "USB Streaming" input terminal rather than a mixer or other virtual type, the control receives the somewhat meaningless name "PCM", even if the output had a descriptive type such as "Headset" or "Speaker". Here is an example of such AudioControl descriptor from a USB headset which ends up named "PCM Playback" and is therefore not recognized as headphones by userspace: AudioControl Interface Descriptor: bLength 12 bDescriptorType 36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 4 wTerminalType 0x0101 USB Streaming bAssocTerminal 5 bNrChannels 2 wChannelConfig 0x0003 Left Front (L) Right Front (R) iChannelNames 0 iTerminal 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID 5 wTerminalType 0x0402 Headset bAssocTerminal 4 bSourceID 6 iTerminal 0 AudioControl Interface Descriptor: bLength 13 bDescriptorType 36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID 6 bSourceID 4 bControlSize 2 bmaControls(0) 0x0002 Volume Control bmaControls(1) 0x0000 bmaControls(2) 0x0000 iFeature 0 Other headsets and DACs I tried that used their output terminal for naming only did so due to their input being an unnamed sidetone mixer. Instead of always starting with the input terminal, check the type of it first. If it seems uninteresting, invert the order and use the output terminal first for naming. This makes userspace recognize headsets with simple controls as headphones, and leads to more consistent naming of playback devices based on their outputs irrespective of sidetone mixers. Signed-off-by: Kenny Levinsen <kl@kl.wtf> Link: https://lore.kernel.org/r/20240301231107.42679-1-kl@kl.wtf Signed-off-by: Takashi Iwai <tiwai@suse.de>
Linux kernel ============ There are several guides for kernel developers and users. These guides can be rendered in a number of formats, like HTML and PDF. Please read Documentation/admin-guide/README.rst first. In order to build the documentation, use ``make htmldocs`` or ``make pdfdocs``. The formatted documentation can also be read online at: https://www.kernel.org/doc/html/latest/ There are various text files in the Documentation/ subdirectory, several of them using the Restructured Text markup notation. Please read the Documentation/process/changes.rst file, as it contains the requirements for building and running the kernel, and information about the problems which may result by upgrading your kernel.
Description
Languages
C
97.6%
Assembly
1%
Shell
0.5%
Python
0.3%
Makefile
0.3%