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.