Message-ID: <169efa7b-917f-34b8-9edf-1b8c6345c277@leemhuis.info>
Date:   Tue, 10 Jan 2023 10:33:31 +0100
From:   "Linux kernel regression tracking (Thorsten Leemhuis)" 
        <regressions@...mhuis.info>
To:     Jaroslav Kysela <perex@...ex.cz>,
        Pierre-louis Bossart <pierre-louis.bossart@...ux.intel.com>
Cc:     sonic82003@...il.com, plum <plumerlis@...il.com>,
        "regressions@...ts.linux.dev" <regressions@...ts.linux.dev>,
        alsa-devel@...a-project.org, LKML <linux-kernel@...r.kernel.org>,
        Hans de Goede <hdegoede@...hat.com>,
        Takashi Iwai <tiwai@...e.com>
Subject: Re: [regression] Bug 216818 - The microphone mute led not working after linux 6

[now that the holiday season is over I'd like to get this rolling again]

On 19.12.22 18:01, Jaroslav Kysela wrote:
> On 19. 12. 22 11:27, Thorsten Leemhuis wrote:
>> On 19.12.22 11:00, Hans de Goede wrote:
>>> On 12/19/22 10:17, Thorsten Leemhuis wrote:
>>>> I noticed a regression report in bugzilla.kernel.org. As many (most?)
>>>> kernel developer don't keep an eye on it, I decided to forward it by
>>>> mail. Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=216818 :
>>>>
>>>>>   sonic82003@...il.com 2022-12-18 08:52:32 UTC
>>>>>
>>>>> The mic mute led of my ThinkPad X1 Carbon Gen 9 doesn't work
>>>>> anymore after updating linux to version 6.
>>>>> I can still turn it on by  running
>>>>>
>>>>> echo 1 > /sys/class/leds/platform::micmute/brightness
>>>>>
>>>>> With linux-lts it still works fine.
>>>>
>>>> See the ticket for more details.
>>>>
>>>> Note, I found a similar report that (despite my attempts to prevent
>>>> things like this from happening) fell through the cracks here:
>>>> https://bugzilla.kernel.org/show_bug.cgi?id=216355
>>>>
>>>>>   plum 2022-08-13 02:11:01 UTC
>>>>>
>>>>> I upgrade to kernel 5.19.1 but found my thinkpad x1 carbon 2021's
>>>>> mute led stop working.
>>>>>
>>>>> Function is okay but LED won't light up.
>>>>>
>>>>> Back to kernel 5.18 and it's normal and working again.
>>>>>
>>>>> Fedora 36 64 bit
>>>>> Gnome-shell 42
>>>>
>>>>  From a quick research it looks to me like this is an issue for the
>>>> sounds maintainers, as the LED itself apparently works. If that is
>>>> something for the platform people instead please speak up.
>>>
>>> Thanks for bringing this up, we recently hit this in Fedora too
>>> and we have a fix/workaround there. Let me copy and paste what
>>> I just added to bko216355 :
>>
>> Many thx for sharing these details, really helpful.
>>
>>> This is caused by a behavior change of the kernel code controlling
>>> the LED to only turn on the LED when all inputs, including e.g. the
>>> jack mic input are turned off in the alsa-mixer settings.
>>>
>>> But most userspace code only turns the mic which it is actually using
>>> on/off when you hit the mic-mute hotkey.
>>>
>>> Also see: https://bugzilla.redhat.com/show_bug.cgi?id=2134824
>>
>> Ahh, lot's of helpful information and even a bisect there. :-D
>>
>> #regzbot introduced: 9b014266ef8ad0159
> 
> It's not a regression from my view.

Please elaborate. Afaics it is one, as something that used to work
stopped working with a newer kernel version; it doesn't matter it worked
by accident beforehand or can be fixed by updating userland, as Linus
explained multiple times in the past:

https://docs.kernel.org/process/handling-regressions.html#quotes-from-linus-about-regression

But maybe I'm missing something.

>>> Which is the same bug.
>>>
>>> There is a set of fixes available in the form of an alsa-ucm update
>>> which tells the kernel to ignore the state of the jack mic input
>>> restoring the old behavior:
>>>
>>> https://git.alsa-project.org/?p=alsa-ucm-conf.git;a=commitdiff;h=79a8ec44d3dcf097f4a4492c506cbcf338324175
>>> https://git.alsa-project.org/?p=alsa-ucm-conf.git;a=commitdiff;h=9ce9ddb4a84fb467602b716575ea1d8f2bab0c39
>>
>> Hmmm, that's nice, but well, by Linux' "no regressions rule" the issue
>> is caused by kernel change and thus must be fixed in the kernel, e.g.
>> without forcing users to update anything in userspace.
>>
>> Jaroslav, are there any plans to do that?
> 
> I wrote all relevant information to
> https://bugzilla.redhat.com/show_bug.cgi?id=2134824 . The problem exists
> from the initial microphone LED support in the SOF HDA driver, because
> two drivers control the microphone LED simultaneously (sof-hda-dsp +
> hda-intel). My recent update just made this thing more visible - the LED
> state may be updated wrongly in all previous kernels. Original behavior:
> last write wins. New behavior: all off = LED ON. The UCM fix (update the
> default kernel runtime configuration from the user space) is sufficient
> in my eyes for now because even the use case when the microphone LED
> follows the state when all internal inputs are turned off makes sense.
> 
> I think that the sof-hda-dsp driver maintainer may decide to change the
> default settings in the HDA driver when the digital microphone is
> detected. Adding Pierre-Louis to the chain.

Pierre-Louis?

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

#regzbot poke

Powered by blists - more mailing lists