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 <[email protected]>
---
sound/usb/mixer.c | 49 +++++++++++++++++++++++++++++++++--------------
1 file changed, 35 insertions(+), 14 deletions(-)
diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c
index 409fc1164694..81256ab56835 100644
--- a/sound/usb/mixer.c
+++ b/sound/usb/mixer.c
@@ -1652,6 +1652,34 @@ static const struct usb_feature_control_info *get_feature_control_info(int contr
return NULL;
}
+static int feature_unit_mutevol_ctl_name(struct usb_mixer_interface *mixer,
+ struct snd_kcontrol *kctl,
+ struct usb_audio_term *iterm,
+ struct usb_audio_term *oterm)
+{
+ struct usb_audio_term *aterm, *bterm;
+ bool output_first;
+ int len = 0;
+
+ /*
+ * If the input terminal is USB Streaming, we try getting the name of
+ * the output terminal first in hopes of getting something more
+ * descriptive than "PCM".
+ */
+ output_first = iterm && !(iterm->type >> 16) && (iterm->type & 0xff00) == 0x0100;
+
+ aterm = output_first ? oterm : iterm;
+ bterm = output_first ? iterm : oterm;
+
+ if (aterm)
+ len = get_term_name(mixer->chip, aterm, kctl->id.name,
+ sizeof(kctl->id.name), 1);
+ if (!len && bterm)
+ len = get_term_name(mixer->chip, bterm, kctl->id.name,
+ sizeof(kctl->id.name), 1);
+ return len;
+}
+
static void __build_feature_ctl(struct usb_mixer_interface *mixer,
const struct usbmix_name_map *imap,
unsigned int ctl_mask, int control,
@@ -1733,22 +1761,15 @@ static void __build_feature_ctl(struct usb_mixer_interface *mixer,
case UAC_FU_MUTE:
case UAC_FU_VOLUME:
/*
- * determine the control name. the rule is:
- * - if a name id is given in descriptor, use it.
- * - if the connected input can be determined, then use the name
- * of terminal type.
- * - if the connected output can be determined, use it.
- * - otherwise, anonymous name.
+ * Determine the control name:
+ * - If a name id is given in descriptor, use it.
+ * - If input and output terminals are present, try to derive
+ * the name from either of these.
+ * - Otherwise, make up a name using the feature unit ID.
*/
if (!len) {
- if (iterm)
- len = get_term_name(mixer->chip, iterm,
- kctl->id.name,
- sizeof(kctl->id.name), 1);
- if (!len && oterm)
- len = get_term_name(mixer->chip, oterm,
- kctl->id.name,
- sizeof(kctl->id.name), 1);
+ len = feature_unit_mutevol_ctl_name(mixer, kctl, iterm,
+ oterm);
if (!len)
snprintf(kctl->id.name, sizeof(kctl->id.name),
"Feature %d", unitid);
--
2.44.0
On Sat, 02 Mar 2024 00:11:07 +0100,
Kenny Levinsen wrote:
>
> 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 <[email protected]>
Thanks, applied now to for-next branch.
Takashi