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

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

[Kevin Charpentier]

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.

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

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

[Alice Mikityanska]

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

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

[Kevin Charpentier]

On Fri, Sep 11, 2026, Alice wrote:
> Usually, duplicate keys are handled on udev level, see
> /lib/udev/hwdb.d/60-keyboard.hwdb [...] From the source code of
> ideapad-laptop, I see that MICMUTE scan codes are 8 and 0x13e - you need
> to unmap one of those.

That worked, thanks a lot. Confirming with details in case they are useful.

The two paths do use different scan codes, so unmapping one is enough and
the WMI driver can stay bound. Reading the raw evdev stream from "Ideapad
extra buttons" while pressing Fn+F4 three times, before any change:

  +7.176s  MSC_SCAN = 0x8    EV_KEY 248 (KEY_MICMUTE) pressed/released
  +7.182s  MSC_SCAN = 0x13e  EV_KEY 248 (KEY_MICMUTE) pressed/released
  +10.878s MSC_SCAN = 0x8    EV_KEY 248 (KEY_MICMUTE) pressed/released
  +10.878s MSC_SCAN = 0x13e  EV_KEY 248 (KEY_MICMUTE) pressed/released
  +14.747s MSC_SCAN = 0x8    EV_KEY 248 (KEY_MICMUTE) pressed/released
  +14.752s MSC_SCAN = 0x13e  EV_KEY 248 (KEY_MICMUTE) pressed/released

0x8 is the ACPI path (VPC2004:00) and 0x13e is the WMI path
(8FC0DE0C-B4E4-43FD-B0F3-8871711C1294-17). I verified this by unbinding
ideapad_wmi, which left only the 0x8 events.

Your rule worked as written, with no changes and no reboot needed:

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

After `systemd-hwdb update` and `udevadm trigger --action=change
/sys/class/input/event12`, the second event is reported as KEY_UNKNOWN
(240) instead of KEY_MICMUTE, and the key now toggles the microphone
reliably on every press, including the mic-mute LED:

  +5.268s  MSC_SCAN = 0x8    EV_KEY 248 pressed/released
  +5.273s  MSC_SCAN = 0x13e  EV_KEY 240 pressed/released

I will submit this to systemd as a pull request against 60-keyboard.hwdb.

One question, only if it is worth your time: is it expected that this
firmware reports the same key on both paths, or is the ThinkBook 14 G7 ARP
simply a model that was never covered by a quirk? I ask because there is no
entry for this machine (pn21MV) in 60-keyboard.hwdb, while several other
ThinkBook models are listed, so I do not know whether other keys on this
laptop are affected in the same way and just have not been noticed yet.

Thanks again for the quick and clear answer. As a first-time reporter, it
was much easier than I expected.

Kevin Christian Charpentier


On Fri, Sep 11, 2026, Alice wrote:
>
> 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

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

[Alice Mikityanska]

On Fri, Sep 11, 2026, at 17:45, Kevin Charpentier wrote:
> On Fri, Sep 11, 2026, Alice wrote:
>> Usually, duplicate keys are handled on udev level, see
>> /lib/udev/hwdb.d/60-keyboard.hwdb [...] From the source code of
>> ideapad-laptop, I see that MICMUTE scan codes are 8 and 0x13e - you need
>> to unmap one of those.
>
> That worked, thanks a lot. Confirming with details in case they are useful.

Glad that worked!

> The two paths do use different scan codes, so unmapping one is enough and
> the WMI driver can stay bound. Reading the raw evdev stream from "Ideapad
> extra buttons" while pressing Fn+F4 three times, before any change:
>
>   +7.176s  MSC_SCAN = 0x8    EV_KEY 248 (KEY_MICMUTE) pressed/released
>   +7.182s  MSC_SCAN = 0x13e  EV_KEY 248 (KEY_MICMUTE) pressed/released
>   +10.878s MSC_SCAN = 0x8    EV_KEY 248 (KEY_MICMUTE) pressed/released
>   +10.878s MSC_SCAN = 0x13e  EV_KEY 248 (KEY_MICMUTE) pressed/released
>   +14.747s MSC_SCAN = 0x8    EV_KEY 248 (KEY_MICMUTE) pressed/released
>   +14.752s MSC_SCAN = 0x13e  EV_KEY 248 (KEY_MICMUTE) pressed/released
>
> 0x8 is the ACPI path (VPC2004:00) and 0x13e is the WMI path
> (8FC0DE0C-B4E4-43FD-B0F3-8871711C1294-17). I verified this by unbinding
> ideapad_wmi, which left only the 0x8 events.
>
> Your rule worked as written, with no changes and no reboot needed:
>
> evdev:name:Ideapad extra buttons:dmi:*:svnLENOVO:pn21MV:pvrThinkBook14G7ARP:*
>  KEYBOARD_KEY_13e=unknown
>
> After `systemd-hwdb update` and `udevadm trigger --action=change
> /sys/class/input/event12`, the second event is reported as KEY_UNKNOWN
> (240) instead of KEY_MICMUTE, and the key now toggles the microphone
> reliably on every press, including the mic-mute LED:
>
>   +5.268s  MSC_SCAN = 0x8    EV_KEY 248 pressed/released
>   +5.273s  MSC_SCAN = 0x13e  EV_KEY 240 pressed/released
>
> I will submit this to systemd as a pull request against 60-keyboard.hwdb.
>
> One question, only if it is worth your time: is it expected that this
> firmware reports the same key on both paths, or is the ThinkBook 14 G7 ARP
> simply a model that was never covered by a quirk?

Unfortunately, no idea. Having duplicate key reports is not uncommon in
various laptops. I don't know if this particular one is specific for
your model or a wider family. You can start with submitting the hwdb
rule for your specific model, and if other users with other models are
affected too, they can generalize it.

My old IdeaPad Z570 doesn't have a micmute button, as far as I remember.

> I ask because there is no
> entry for this machine (pn21MV) in 60-keyboard.hwdb, while several other
> ThinkBook models are listed, so I do not know whether other keys on this
> laptop are affected in the same way and just have not been noticed yet.

Well, you can test all special keys by pressing them and watching evdev
events to identify all the buggy keys, to submit quirks for all of them
at once. From what I see in the driver, KEY_PROG{1,2,3,4} can be
generated both via ideapad_acpi and ideapad_wmi, so worth checking those
(Fn+Q, dark mode, sound profile, star button, Lenovo proprietary stuff,
and similar, if you have any of those on your laptop). But there is also
a possibility that some keys can be reported via both ideapad_laptop and
atkbd, so it's still worth checking all of the special keys.

Regards,
Alice

> Thanks again for the quick and clear answer. As a first-time reporter, it
> was much easier than I expected.
>
> Kevin Christian Charpentier
>
>
> On Fri, Sep 11, 2026, Alice wrote:
>>
>> 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