Re: ideapad-laptop: duplicate KEY_MICMUTE events on ThinkBook 14 G7 ARP (ACPI and WMI both report)

["Alice Mikityanska" <alice.kernel@fastmail.im>]

On Fri, Sep 11, 2026, at 05:49, Kevin Charpentier wrote:
> Hi,
>
> I am reporting a bug where the mic-mute key (Fn+F4) is reported twice by
> ideapad-laptop on a Lenovo ThinkBook 14 G7 ARP, which makes the key appear
> not to work at all under GNOME.
>
> This is my first report to this list, so please let me know if anything is
> missing or should be sent differently.
>
> System
> ------
> Machine:  Lenovo ThinkBook 14 G7 ARP (21MV)
> BIOS:     P6CN34WW, 03/10/2026 (EC 1.37, BIOS release 1.34)
> Kernel:   7.2.4-200.fc44.x86_64 (Fedora 44)
> Module:   drivers/platform/x86/lenovo/ideapad-laptop.ko
>
> DMI modalias:
> dmi:bvnLENOVO:bvrP6CN34WW:bd03/10/2026:br1.34:efr1.37:svnLENOVO:pn21MV:pvrThinkBook14G7ARP:rvnLENOVO:rnLNVNB161216:rvrNODPK:cvnLENOVO:ct10:cvrThinkBook14G7ARP:skuLENOVO_MT_21MV_BU_idea_FM_ThinkBook14G7ARP:pfaThinkBook14G7ARP:
>
> Symptom
> -------
> Pressing Fn+F4 appears to do nothing. The GNOME on-screen indicator does
> appear and the mic-mute LED blinks, but the microphone mute state is
> unchanged. Roughly one press out of several does take effect, which I
> believe happens when the firmware drops one of the two notifications.
>
> The key is not unmapped: KEY_MICMUTE is emitted correctly. It is emitted
> twice per physical keypress, 1-7 ms apart, so the userspace toggle is
> applied an even number of times and the state returns to its original
> value before anything can observe it.
>
> Note that polling the mute state does not reveal this. Both toggles happen
> within ~7 ms, so a 100 ms poll of the PipeWire source sees no change at all
> and the key looks completely dead.
>
> Evidence
> --------
> Three physical keypresses, via `sudo libinput debug-events --show-keycodes`.
> Note the millisecond-apart pairs, which cannot be produced by a finger:
>
> -event12  KEYBOARD_KEY   +0.860s    KEY_MICMUTE (248) pressed
>  event12  KEYBOARD_KEY   +0.860s    KEY_MICMUTE (248) released
>  event12  KEYBOARD_KEY   +0.867s    KEY_MICMUTE (248) pressed
>  event12  KEYBOARD_KEY   +0.868s    KEY_MICMUTE (248) released
>  event12  KEYBOARD_KEY   +3.137s    KEY_MICMUTE (248) pressed
>  event12  KEYBOARD_KEY   +3.137s    KEY_MICMUTE (248) released
>  event12  KEYBOARD_KEY   +3.140s    KEY_MICMUTE (248) pressed
>  event12  KEYBOARD_KEY   +3.140s    KEY_MICMUTE (248) released
>  event12  KEYBOARD_KEY   +4.886s    KEY_MICMUTE (248) pressed
>  event12  KEYBOARD_KEY   +4.886s    KEY_MICMUTE (248) released
>  event12  KEYBOARD_KEY   +4.891s    KEY_MICMUTE (248) pressed
>  event12  KEYBOARD_KEY   +4.891s    KEY_MICMUTE (248) released
>
> All events come from the same input device, "Ideapad extra buttons"
> (phys=ideapad/input0), created by ideapad-laptop.
>
> Analysis
> --------
> On this machine ideapad-laptop is bound to two devices at the same time,
> and both report this key into the same input device:
>
>   1. ACPI: platform device VPC2004:00 (driver ideapad_acpi)
>   2. WMI:  8FC0DE0C-B4E4-43FD-B0F3-8871711C1294-17 (driver ideapad_wmi),
>            notify_id D0, instance_count 1
>
> Unbinding the WMI device removes the duplicate completely:
>
>   echo 8FC0DE0C-B4E4-43FD-B0F3-8871711C1294-17 > \
>        /sys/bus/wmi/drivers/ideapad_wmi/unbind
>
> After the unbind, the same three keypresses produce single events, with
> human-scale gaps instead of millisecond pairs:
>
>  event12  KEYBOARD_KEY   +0.298s    KEY_MICMUTE (248) pressed/released
>  event12  KEYBOARD_KEY   +1.043s    KEY_MICMUTE (248) pressed/released
>  event12  KEYBOARD_KEY   +2.880s    KEY_MICMUTE (248) pressed/released
>
> The key then works correctly in GNOME, and so does the mic-mute LED.
>
> I also verified that unbinding the WMI device does not regress anything
> else exposed by the driver: fn_lock, conservation_mode, camera_power,
> usb_charging and fan_mode still respond, the platform::fnlock,
> platform::kbd_backlight, platform::mute and platform::micmute LEDs are
> still present, and the kernel logs no errors.
>
> Questions
> ---------
> I am not sure where the fix belongs, so I am reporting rather than
> proposing a patch:
>
>   - Is the firmware expected to notify this key on both the ACPI and the
>     WMI path, with the driver responsible for reporting it only once?
>   - Or should ideapad-laptop not register the WMI hotkey path on models
>     where the ACPI path already reports these keys?
>
> I am happy to test patches or gather any further information. I can also
> provide the full acpidump, the WMI BMOF dump, or udev debug logs if that
> helps.

Hi Kevin,

Thanks for the detailed report!

Usually, duplicate keys are handled on udev level, see /lib/udev/hwdb.d/60-
keyboard.hwdb: it contains lots of definitions with "=unknown", which
unmap certain keys, often because they are already handled by another
input device. Although adding a kernel quirk is also possible.

There is no need to unbind or blacklist the entire WMI driver for this.
You can try adding a rule locally to /etc/udev/hwdb.d/61-keyboard-
custom.hwdb, run `systemd-hwdb update`, and reboot to test it. The rule
will probably look like this (I can't test it):

evdev:name:Ideapad extra buttons:dmi:*:svnLENOVO:pn21MV:pvrThinkBook14G7ARP:*
 KEYBOARD_KEY_13e=unknown

If it doesn't work on the first attempt, try making the DMI match more
generic for testing. From the source code of ideapad-laptop, I see that
MICMUTE scan codes are 8 and 0x13e — you need to unmap one of those.

If that works, you can submit a pull request to systemd.

Hope that helps,
Alice

> Workaround for other users of this model
> ----------------------------------------
> A udev rule that unbinds the WMI device at boot:
>
> ACTION=="bind", SUBSYSTEM=="wmi",
> ATTR{guid}=="8FC0DE0C-B4E4-43FD-B0F3-8871711C1294", RUN+="/bin/sh -c
> 'grep -qx 21MV /sys/class/dmi/id/product_name && echo %k >
> /sys/bus/wmi/drivers/ideapad_wmi/unbind'"
>
> Thanks,
> Kevin Christian Charpentier