linux-kernel - Re: [RFC] sound: usb: design for quirk 'mixer_min

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87h5xm5g7f.wl-tiwai@suse.de>
Date: Mon, 01 Sep 2025 17:45:56 +0200
From: Takashi Iwai <tiwai@...e.de>
To: Cryolitia PukNgae <cryolitia@...ontech.com>
Cc: Jaroslav Kysela <perex@...ex.cz>,
	Takashi Iwai <tiwai@...e.com>,
	linux-sound@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Mingcong Bai <jeffbai@...c.io>,
	Kexy Biscuit <kexybiscuit@...c.io>,
	Nie Cheng <niecheng1@...ontech.com>,
	Zhan Jun <zhanjun@...ontech.com>,
	Feng Yuan <fengyuan@...ontech.com>,
	qaqland <anguoli@...ontech.com>
Subject: Re: [RFC] sound: usb: design for quirk 'mixer_min_mute'

On Fri, 29 Aug 2025 11:29:22 +0200,
Cryolitia PukNgae wrote:
> 
> We are discussig about the problem that, on some devices the lowest
> playback value represents muted state instead of minimum audible volume.
> In the previous discussion, we have shown that this problem is widespread
> across a wide range of hardware[1][2]. And we have already added a bit for
> it[1].
> 
> Firstly, we need to discuss about how to design a module param for it. As
> it is needed to debug the device for end users instead of ignoring
> hardware mixer and using soft mixer only in pipewire, which has already
> written in Arch Linux wiki[3], as an imperfect workaround.
> 
> Inspired by Takashi Iwai[4], I would like to design a module param named
> `quirk_names`, to be passed like
> `1234:abcd:mixer_min_mute,4567:efef:ignore_ctl_error`, so that we can
> apply one or more quirk on a specific USB device.

I suppose this will turn on each quirk bit?  We may want to turn *off*
the quirk bit, too, e.g. extend the syntax with '!' marker
`1234:abcd:!mixer_min_mute`.

Also, allowing multiple quirk bits by numbers would be also handy,
e.g. `1234:abcd:003f`.  So, if the last part represents a hex number,
it's treated as the quirk bits.

One more thing would be to allow a wildcard to the device matching,
e.g. `*:*:mixer_min_mute`.

An open question is whether we may want yet a new module option or
rather extend the existing quirk option to accept the strings
instead.  Basically, when the given argument has a colon, it's a new
syntax.  If it's only a number, it's an old syntax, and parse like
before.  But, I'm open for either way (a new option or extend the
existing one).

> And the already existed
> param `ignore_ctl_error` could be deleted, because of included in the
> one.

Dropping an existing option isn't so easy.  It can break users who
already applied it for long time.  So, unless it's really conflicting
and does harmful, I'd rather keep the old option as is.

> >    /* lowest playback value is muted on some devices */
> >    if (mixer->chip->quirk_flags & QUIRK_FLAG_MIXER_MIN_MUTE)
> >        if (strstr(kctl->id.name, "Playback"))
> >            cval->min_mute = 1;
> 
> Secondly, all efforts so far is only for the Playback. But we have found
> some devices have the same problem on the Capture. So for the problem
> that the lowest playback value represents muted state instead of minimum 
> udible volume:
> 
>   1. On some devices we already tested, only happens on their Playback,
>      but their Capture works perfectly. Or they are just a simple
>      earphone without audio input.
>   2. On some devices we already tested, have the problem both on Playback
>      and Capture.
>   3. Maybe on some devices we havn't found yet, have the problem only on
>      Capture but not Playback.
> 
> How could we deal with them? Would two quirk bit seems a little waste?

It's a good question.  My gut feeling so far is to make another quirk
bit for the capture, but we may find some compromised solution, too.
> 
> Thirdly, the most complex situation. We found a device: `3302:12db
> MOONDROP Quark2` , that its volume control has a range 0-120, but acts to
> mute when less than 8. I have no idea about how to deal with it simplly.
> We are actively contacting the manufacturer and informing them of this
> matter.

If that kind of behavior becomes common, we can add a common quirk bit.
Until then, it's handled as an own fix.


thanks,

Takashi