* Re: ideapad-laptop: duplicate KEY_MICMUTE events (ACPI VPC bit 8 + WMI 0x3e) on ThinkBook 16 G7 ARP
2026-07-20 20:44 ` ideapad-laptop: duplicate KEY_MICMUTE events (ACPI VPC bit 8 + WMI 0x3e) on ThinkBook 16 G7 ARP Андрей Тишин
@ 2026-07-21 15:22 ` Hans de Goede
0 siblings, 0 replies; 2+ messages in thread
From: Hans de Goede @ 2026-07-21 15:22 UTC (permalink / raw)
To: Андрей Тишин,
platform-driver-x86
Cc: kepanhc, ilpo.jarvinen
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
^ permalink raw reply [flat|nested] 2+ messages in thread