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

[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@gmail.com/),
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

[PATCH 1/2] platform/x86: asus-nb-wmi: Ignore unknown event 0xE5

[Seyed Mohammad Mahdi Hosseini]

On the ASUS TUF Gaming A15 FA507RF (BIOS FA507RF.306) the firmware sends
WMI event 0xE5 about every 10 seconds, for many hours at a time, while
the laptop is on AC power. Nobody presses a key when it arrives. The
keymap has no entry for it, so asus-wmi logs

  asus_wmi: Unknown key code 0xe5

each time and reports MSC_SCAN 0xe5 with a KEY_UNKNOWN press and release
on the "Asus WMI hotkeys" input device. Desktop environments take that
as user activity: the session never goes idle and a locked screen wakes
up every 10 seconds.

Owners of other TUF models (F15 FX506HE, A17) report the same periodic
event, and that it stops when the charger is unplugged.

Ignore the event, as was done for the AC and charger notifications 0x79,
0x7B, and 0xCF.

Assisted-by: LLM
Signed-off-by: Seyed Mohammad Mahdi Hosseini <i@smmh.dev>
---

Notes:
    Built against 7.2.8 and loaded on this machine in place of the stock
    asus-nb-wmi. The 0xE5 episode had already ended when it was loaded, so
    this entry has not yet been seen silencing the event; until then the
    events were dropped by an input filter on the same device.
    
    The research, the keymap entry, and this changelog were prepared with an
    LLM coding assistant; the logs and observations are from my machine.

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

diff --git a/drivers/platform/x86/asus-nb-wmi.c b/drivers/platform/x86/asus-nb-wmi.c
index aeb461b1644d..23dce220f974 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -662,6 +662,7 @@ static const struct key_entry asus_nb_wmi_keymap[] = {
 	{ KE_KEY, 0xCB, { KEY_F14 } }, /* Fn+noise-cancel */
 	{ KE_IGNORE, 0xC6, },  /* Ambient Light Sensor notification */
 	{ KE_IGNORE, 0xCF, },	/* AC mode */
+	{ KE_IGNORE, 0xE5, },	/* Periodic notification while on AC */
 	{ KE_KEY, 0xFA, { KEY_PROG2 } },           /* Lid flip action */
 	{ KE_KEY, 0xBD, { KEY_PROG2 } },           /* Lid flip action on ROG xflow laptops */
 	{ KE_KEY, ASUS_WMI_KEY_ARMOURY, { KEY_PROG3 } },
-- 
2.55.0

[PATCH 2/2] platform/x86: asus-nb-wmi: Ignore Windows key lock event 0x4F

[Seyed Mohammad Mahdi Hosseini]

On the ASUS TUF Gaming A15 FA507RF (BIOS FA507RF.306), pressing Fn+Win
makes the firmware send WMI event 0x4F. The keymap has no entry for it,
so each press logs

  asus_wmi: Unknown key code 0x4f

and reports MSC_SCAN 0x4f with a KEY_UNKNOWN press and release on the
"Asus WMI hotkeys" input device. Pressing Fn+Win twice gave two such
lines, one per press.

Fn+Win toggles the Windows key lock, and the firmware applies the lock
by itself; the event only tells the OS that it happened. G-Helper, which
handles the same ATK WMI events on Windows, has "case 79: // Fn + Win"
right after "case 78: // Fn + ESC" (0x4E, NOTIFY_FNLOCK_TOGGLE in
asus-wmi). For Fn+Esc it sets the Fn lock through ATK, as asus-wmi does
for 0x4E; for Fn+Win it only shows a notification.

The event carries no lock state, asus-wmi has no device ID for a
Windows key lock, and there is no input key code that means one, so
neither the kernel nor user space has anything to do with it. Ignore it,
as is done for other events about things the firmware has already
handled, such as 0x2B and 0x2C (keys also sent via PS/2) and the AC and
charger notifications 0x79, 0x7B, and 0xCF.

Assisted-by: LLM
Signed-off-by: Seyed Mohammad Mahdi Hosseini <i@smmh.dev>
---

Notes:
    Tested on this machine with 7.2.8: with this entry, pressing Fn+Win
    twice logs nothing; the 0x4F lines above were logged by the unpatched
    driver for the same presses.
    
    The research, the keymap entry, and this changelog were prepared with an
    LLM coding assistant; the logs and observations are from my machine.

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

diff --git a/drivers/platform/x86/asus-nb-wmi.c b/drivers/platform/x86/asus-nb-wmi.c
index 23dce220f974..f4a6e9c02b76 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -601,6 +601,7 @@ static const struct key_entry asus_nb_wmi_keymap[] = {
 	{ KE_KEY, 0x43, { KEY_STOPCD } }, /* Stop/Eject */
 	{ KE_KEY, 0x45, { KEY_PLAYPAUSE } },
 	{ KE_KEY, 0x4c, { KEY_MEDIA } }, /* WMP Key */
+	{ KE_IGNORE, 0x4F, }, /* Fn+Win, Windows key lock done by firmware */
 	{ KE_KEY, 0x50, { KEY_EMAIL } },
 	{ KE_KEY, 0x51, { KEY_WWW } },
 	{ KE_KEY, 0x55, { KEY_CALC } },
-- 
2.55.0