Re: ideapad-laptop: duplicate KEY_MICMUTE events (ACPI VPC bit 8 + WMI 0x3e) on ThinkBook 16 G7 ARP

Re: ideapad-laptop: duplicate KEY_MICMUTE events (ACPI VPC bit 8 + WMI 0x3e) on ThinkBook 16 G7 ARP

[Андрей Тишин]

Hi,

On a Lenovo ThinkBook 16 G7 ARP (Ryzen AI, CachyOS/Arch, kernel
7.1.3-2-cachyos), pressing the physical mic-mute key (Fn+F4) toggles
the microphone mute twice, effectively cancelling itself (two
notifications appear in the desktop: "microphone muted" immediately
followed by "microphone unmuted").

Looking at drivers/platform/x86/lenovo/ideapad-laptop.c, I believe
this is because the same physical keypress is reported through two
independent, non-deduplicated paths that both map to KEY_MICMUTE:

1. Legacy ACPI VPC notify, bit 8:
case 8: ... ideapad_input_report(priv, bit);
-> keymap: { KE_KEY, 8, { KEY_MICMUTE } }

2. WMI event 0x3e:
{ KE_KEY, 0x3e | IDEAPAD_WMI_KEY, { KEY_MICMUTE } },
(comment: "Specific to some newer models")

`ideapad_acpi_notify()` and `ideapad_wmi_notify()` are called
independently with no shared debounce/dedup state, so on this model
the firmware appears to fire both notifications for a single physical
press.

evtest output on "Ideapad extra buttons" confirms two distinct
scancodes arriving ~1-2ms apart for one physical press:
Event: ..., type 4 (EV_MSC), code 4 (MSC_SCAN), value 08
Event: ..., type 1 (EV_KEY), code 248 (KEY_MICMUTE), value 1
Event: ..., type 1 (EV_KEY), code 248 (KEY_MICMUTE), value 0
Event: ..., type 4 (EV_MSC), code 4 (MSC_SCAN), value 13e <- 0x100(WMI) | 0x3e
Event: ..., type 1 (EV_KEY), code 248 (KEY_MICMUTE), value 1
Event: ..., type 1 (EV_KEY), code 248 (KEY_MICMUTE), value 0

Separately, the AT Translated Set 2 keyboard on this laptop also
appears to have a related firmware issue: KEY_VOLUMEUP/KEY_VOLUMEDOWN
release events are sometimes delayed by several seconds, causing
volume to run away to 0%/100% via autorepeat before release finally
arrives (this part I've worked around locally via the existing atkbd
force_release sysfs mechanism with scancodes 174,176 - not a
kernel-side issue, just documenting for context in case it's related
to the same buggy EC).

System info:
dmidecode -s system-version: ThinkBook 16 G7 ARP
dmidecode -s baseboard-product-name: LNVNB161216
BIOS version: P6CN34WW
kernel: 7.1.3-2-cachyos

Would something like a jiffies-based debounce between the two report
paths (similar to the approach used in hid-plantronics.c for a
comparable "duplicate volume key press" issue) be an acceptable fix,
or is there a preferred way to detect/disable one of the two reporting
channels for affected models?
Happy to test patches or provide more logs (full evtest dump, acpi
dump, etc.) if useful.

Thanks, Andrey Tishin.

Re: ideapad-laptop: duplicate KEY_MICMUTE events (ACPI VPC bit 8 + WMI 0x3e) on ThinkBook 16 G7 ARP

[Hans de Goede]

Hi,

On 20-Jul-26 22:44, Андрей Тишин wrote:
> Hi,
> 
> On a Lenovo ThinkBook 16 G7 ARP (Ryzen AI, CachyOS/Arch, kernel
> 7.1.3-2-cachyos), pressing the physical mic-mute key (Fn+F4) toggles
> the microphone mute twice, effectively cancelling itself (two
> notifications appear in the desktop: "microphone muted" immediately
> followed by "microphone unmuted").
> 
> Looking at drivers/platform/x86/lenovo/ideapad-laptop.c, I believe
> this is because the same physical keypress is reported through two
> independent, non-deduplicated paths that both map to KEY_MICMUTE:
> 
> 1. Legacy ACPI VPC notify, bit 8:
> case 8: ... ideapad_input_report(priv, bit);
> -> keymap: { KE_KEY, 8, { KEY_MICMUTE } }
> 
> 2. WMI event 0x3e:
> { KE_KEY, 0x3e | IDEAPAD_WMI_KEY, { KEY_MICMUTE } },
> (comment: "Specific to some newer models")
> 
> `ideapad_acpi_notify()` and `ideapad_wmi_notify()` are called
> independently with no shared debounce/dedup state, so on this model
> the firmware appears to fire both notifications for a single physical
> press.
> 
> evtest output on "Ideapad extra buttons" confirms two distinct
> scancodes arriving ~1-2ms apart for one physical press:
> Event: ..., type 4 (EV_MSC), code 4 (MSC_SCAN), value 08
> Event: ..., type 1 (EV_KEY), code 248 (KEY_MICMUTE), value 1
> Event: ..., type 1 (EV_KEY), code 248 (KEY_MICMUTE), value 0
> Event: ..., type 4 (EV_MSC), code 4 (MSC_SCAN), value 13e <- 0x100(WMI) | 0x3e
> Event: ..., type 1 (EV_KEY), code 248 (KEY_MICMUTE), value 1
> Event: ..., type 1 (EV_KEY), code 248 (KEY_MICMUTE), value 0
> 
> Separately, the AT Translated Set 2 keyboard on this laptop also
> appears to have a related firmware issue: KEY_VOLUMEUP/KEY_VOLUMEDOWN
> release events are sometimes delayed by several seconds, causing
> volume to run away to 0%/100% via autorepeat before release finally
> arrives (this part I've worked around locally via the existing atkbd
> force_release sysfs mechanism with scancodes 174,176 - not a
> kernel-side issue, just documenting for context in case it's related
> to the same buggy EC).

I think you should be able to make the force-release stuff
happen automatically by adding a volume-key mapping matching
the DMI strings of your laptop with the "key identifier" string
prefixed with ! in:

/lib/udev/hwdb.d/60-keyboard.hwdb

Look for "ThinkBook16G6IRL" for a set of existing lenovo
models needing this and just add a match line with your DMI
strings there.

Once you've this working please submit a pull-request to systemd
upstream to get this workaround added to the official hwdb.

> System info:
> dmidecode -s system-version: ThinkBook 16 G7 ARP
> dmidecode -s baseboard-product-name: LNVNB161216
> BIOS version: P6CN34WW
> kernel: 7.1.3-2-cachyos
> 
> Would something like a jiffies-based debounce between the two report
> paths (similar to the approach used in hid-plantronics.c for a
> comparable "duplicate volume key press" issue) be an acceptable fix,
> or is there a preferred way to detect/disable one of the two reporting
> channels for affected models?
> Happy to test patches or provide more logs (full evtest dump, acpi
> dump, etc.) if useful.

Unless in the next couple of days someone comes up with a better
fix, then yes I think some jiffies based filtering of the duplicate
events would be useful. This way we fix this issue once and for all
(in case it pops up on other models too) where as a model specific quirk
disabling one of the two paths only fixes it for your model.

Regards,

Hans