public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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