[PATCH v2 0/3] platform/x86: fix fn-lock on ASUS ProArt P16 (WMI DEVS no-op)

Marcus Grenängen posted 3 patches 3 weeks, 2 days ago
There is a newer version of this series
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(-)
[PATCH v2 0/3] platform/x86: fix fn-lock on ASUS ProArt P16 (WMI DEVS no-op)
Posted by Marcus Grenängen 3 weeks, 2 days ago
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