From: "Marcus Grenängen" <marcus@grenangen.se>
To: platform-driver-x86@vger.kernel.org, denis.benato@linux.dev
Cc: linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
luke@ljones.dev, hansg@kernel.org, ilpo.jarvinen@linux.intel.com,
jikos@kernel.org, bentiss@kernel.org, corentin.chary@gmail.com,
marcus@grenangen.se
Subject: [PATCH v2 0/3] platform/x86: fix fn-lock on ASUS ProArt P16 (WMI DEVS no-op)
Date: Wed, 6 May 2026 21:33:23 +0200 [thread overview]
Message-ID: <20260506193326.5862-1-marcus@grenangen.se> (raw)
In-Reply-To: <458d9e6c-8702-4cbc-9c4f-33cbd1175e67@linux.dev>
This is v2 of the fn-lock fix for ASUS laptops where the WMI DEVS call
for DEVID 0x00100023 is silently non-functional.
Changes since v1:
- Split into three patches as requested: hid-asus export, nb-wmi quirk,
asus-armoury attribute (the NULL-ptr fix for brightness_set is folded
into patch 1 where the second listener type is introduced)
- Moved the sysfs attribute to asus-armoury's firmware-attributes
interface (fn_lock under /sys/class/firmware-attributes/asus-armoury/)
instead of asus-wmi, as suggested
- asus-armoury now calls asus_hid_fnlock_notify() directly rather than
routing through asus-wmi; this avoids touching asus-wmi.c entirely
- Dropped the asus_hid_listener::fnlock_set callback and the
asus_hid_set_fnlock() / asus_hid_has_fnlock_listener() machinery from
asus-wmi.c — the direct export from hid-asus is simpler and avoids
the module init ordering issue described below
Regarding Denis's question about auto-detection: unfortunately it is not
feasible. On the ProArt P16, DSTS reports DEVID 0x00100023 as present
(ASUS_WMI_DSTS_PRESENCE_BIT set), so the existing WMI probe path finds
it. There is no distinguishing bit in the DSTS result between "WMI works"
and "WMI is silently a no-op". Attempting a test write at probe time would
be unreliable (no readback available on HID-path platforms — the fn_lock
show function intentionally returns -EOPNOTSUPP). A DMI quirk is the
cleanest approach.
Note on module init ordering: asus-armoury and asus-nb-wmi are both
compiled as loadable modules at the same init level. When asus-armoury
initialises it cannot safely dereference asus_ref.asus (set by asus-wmi)
to read the quirk flags, because asus-nb-wmi may not have probed yet.
asus-armoury therefore uses dmi_match() directly rather than an exported
accessor through asus-wmi.
Tested on ASUS ProArt P16 (H7606WI, N-Key keyboard 0B05:19B6):
- fn_lock attribute appears under firmware-attributes/asus-armoury/
- Writing 0/1 to current_value correctly toggles fn-lock state via HID
- asusctl fn-lock -s true/false works end-to-end via asusd
Marcus Grenängen (3):
HID: asus: export asus_hid_fnlock_notify() for direct fn-lock control
platform/x86: asus-nb-wmi: add fnlock_use_hid quirk for ProArt P16
platform/x86: asus-armoury: add fn_lock firmware attribute
drivers/hid/hid-asus.c | 43 +++++++++++++-
drivers/platform/x86/asus-armoury.c | 69 ++++++++++++++++++++++
drivers/platform/x86/asus-nb-wmi.c | 13 ++++
drivers/platform/x86/asus-wmi.h | 5 ++
include/linux/platform_data/x86/asus-wmi.h | 5 ++
5 files changed, 134 insertions(+), 1 deletion(-)
--
2.54.0
next prev parent reply other threads:[~2026-05-06 19:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-30 8:05 [PATCH] platform/x86: asus-wmi: fix fn-lock on platforms where WMI DEVS is a no-op Marcus Grenängen
2026-05-01 15:03 ` Denis Benato
2026-05-06 19:33 ` Marcus Grenängen [this message]
2026-05-06 19:33 ` [PATCH v2 1/3] HID: asus: export asus_hid_fnlock_notify() for direct fn-lock control Marcus Grenängen
2026-05-06 22:00 ` Randy Dunlap
2026-05-06 22:17 ` Denis Benato
2026-05-06 19:33 ` [PATCH v2 2/3] platform/x86: asus-nb-wmi: add fnlock_use_hid quirk for ProArt P16 Marcus Grenängen
2026-05-06 19:33 ` [PATCH v2 3/3] platform/x86: asus-armoury: add fn_lock firmware attribute Marcus Grenängen
2026-05-06 22:10 ` Denis Benato
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=20260506193326.5862-1-marcus@grenangen.se \
--to=marcus@grenangen.se \
--cc=bentiss@kernel.org \
--cc=corentin.chary@gmail.com \
--cc=denis.benato@linux.dev \
--cc=hansg@kernel.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=jikos@kernel.org \
--cc=linux-input@vger.kernel.org \
--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