* [PATCH 1/2] platform/x86: asus-nb-wmi: Ignore unknown event 0xE5
2026-10-15 22:10 [PATCH 0/2] platform/x86: asus-nb-wmi: Ignore events 0xE5 and 0x4F Seyed Mohammad Mahdi Hosseini
@ 2026-10-15 22:10 ` Seyed Mohammad Mahdi Hosseini
2026-10-15 22:10 ` [PATCH 2/2] platform/x86: asus-nb-wmi: Ignore Windows key lock event 0x4F Seyed Mohammad Mahdi Hosseini
1 sibling, 0 replies; 3+ messages in thread
From: Seyed Mohammad Mahdi Hosseini @ 2026-10-15 22:10 UTC (permalink / raw)
To: Hans de Goede, Ilpo Järvinen
Cc: Corentin Chary, Luke D. Jones, Denis Benato, platform-driver-x86,
linux-kernel
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
^ permalink raw reply [flat|nested] 3+ messages in thread* [PATCH 2/2] platform/x86: asus-nb-wmi: Ignore Windows key lock event 0x4F
2026-10-15 22:10 [PATCH 0/2] platform/x86: asus-nb-wmi: Ignore events 0xE5 and 0x4F Seyed Mohammad Mahdi Hosseini
2026-10-15 22:10 ` [PATCH 1/2] platform/x86: asus-nb-wmi: Ignore unknown event 0xE5 Seyed Mohammad Mahdi Hosseini
@ 2026-10-15 22:10 ` Seyed Mohammad Mahdi Hosseini
1 sibling, 0 replies; 3+ messages in thread
From: Seyed Mohammad Mahdi Hosseini @ 2026-10-15 22:10 UTC (permalink / raw)
To: Hans de Goede, Ilpo Järvinen
Cc: Corentin Chary, Luke D. Jones, Denis Benato, platform-driver-x86,
linux-kernel
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
^ permalink raw reply [flat|nested] 3+ messages in thread