From: Seyed Mohammad Mahdi Hosseini <i@smmh.dev>
To: "Hans de Goede" <hansg@kernel.org>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: Corentin Chary <corentin.chary@gmail.com>,
"Luke D. Jones" <luke@ljones.dev>,
Denis Benato <denis.benato@linux.dev>,
platform-driver-x86@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: [PATCH 2/2] platform/x86: asus-nb-wmi: Ignore Windows key lock event 0x4F
Date: Fri, 16 Oct 2026 00:10:55 +0200 [thread overview]
Message-ID: <debbc20cc0fd7e463d934a77979d40e671c49d89.1791672579.git.i@smmh.dev> (raw)
In-Reply-To: <cover.1791672579.git.i@smmh.dev>
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
prev parent reply other threads:[~2026-10-15 22:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=debbc20cc0fd7e463d934a77979d40e671c49d89.1791672579.git.i@smmh.dev \
--to=i@smmh.dev \
--cc=corentin.chary@gmail.com \
--cc=denis.benato@linux.dev \
--cc=hansg@kernel.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luke@ljones.dev \
--cc=platform-driver-x86@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®