[PATCH 0/2] platform/x86: asus-nb-wmi: Ignore events 0xE5 and 0x4F

[Seyed Mohammad Mahdi Hosseini]

On the ASUS TUF Gaming A15 FA507RF (BIOS FA507RF.306), two WMI events
reach asus-nb-wmi without a keymap entry, so asus-wmi logs
"Unknown key code" for each and reports KEY_UNKNOWN on the "Asus WMI
hotkeys" input device:

- 0xE5 arrives about every 10 seconds, for many hours at a time, while
  the laptop is on AC power, with nobody touching the keyboard. Desktops
  take each KEY_UNKNOWN as user activity, so the lock screen keeps
  waking up. Patch 1 ignores it.

- 0x4F arrives when Fn+Windows is pressed. The firmware toggles the
  Windows key lock by itself; the event only notifies, and nothing in
  the kernel needs to act on it. Patch 2 ignores it.

Both follow the existing KE_IGNORE entries (0xC6, 0xCF, 0x7B).

Patch 1 overlaps with "platform/x86: asus-nb-wmi: Ignore spurious 0xe5
events on GU605MY" by Evgeny Volferts
(https://patchwork.kernel.org/project/platform-driver-x86/patch/20261015163029.107250-1-eugene.wolferz@xxxxxxxxx/),
which ignores 0xE5 through a DMI quirk for the ROG Zephyrus G16 GU605MY
only. The same event, at the same period, also shows up on this TUF
FA507RF, and users report it on the TUF F15 FX506HE and the TUF A17
(https://bbs.archlinux.org/viewtopic.php?id=305063) and on a Zenbook
(https://forum.manjaro.org/t/kernel-error-message-0xe5/157745). No ASUS
model maps 0xE5 to a key, so patch 1 ignores it in the shared keymap
for every model, the way 0xCF was handled. If a per-model quirk is
preferred, I can send a version adding the FA507RF to that patch's
quirk instead.

Seyed Mohammad Mahdi Hosseini (2):
  platform/x86: asus-nb-wmi: Ignore unknown event 0xE5
  platform/x86: asus-nb-wmi: Ignore Windows key lock event 0x4F

 drivers/platform/x86/asus-nb-wmi.c | 2 ++
 1 file changed, 2 insertions(+)

-- 
2.55.0