platform/x86: asus-nb-wmi: Ignore events 0xE5 and 0x4F

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/[email protected]/),
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

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.

---

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(+)

index aeb461b1644d..23dce220f974 100644
@@ -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

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.

---

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(+)

index 23dce220f974..f4a6e9c02b76 100644
@@ -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