Message-ID: <20250319191320.10092-1-lkml@antheas.dev>
Date: Wed, 19 Mar 2025 20:13:08 +0100
From: Antheas Kapenekakis <lkml@...heas.dev>
To: platform-driver-x86@...r.kernel.org,
	linux-input@...r.kernel.org
Cc: linux-kernel@...r.kernel.org,
	Jiri Kosina <jikos@...nel.org>,
	Benjamin Tissoires <bentiss@...nel.org>,
	Corentin Chary <corentin.chary@...il.com>,
	"Luke D . Jones" <luke@...nes.dev>,
	Hans de Goede <hdegoede@...hat.com>,
	Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
	Antheas Kapenekakis <lkml@...heas.dev>
Subject: [PATCH 00/11] HID: asus: hid-asus and asus-wmi backlight unification,
 Z13 QOL improvements

This is a three part series that does the following: first, it cleans up
the hid-asus driver initialization, preventing excess renames and dmesg
errors on ROG devices. Then, it adds support for the Z13 2025 keyboard,
by fixing its keyboard to not be stuck in BIOS mode and enabling its fan
key. Finally, the bigger piece of this series is the unification of the
backlight controls between hid-asus and asus-wmi.

This requires some context. First, some ROG devices expose both WMI and
HID controls for RGB. In addition, some ROG devices (such as the Z13)
have two AURA devices where both have backlight controls (lightbar and
keyboard). Under Windows, Armoury Crate exposes a single brightness control
for all Aura devices.

However, currently in the linux kernel this is not the case, with asus-wmi
and hid-asus relying on a quirk system to figure out which should control
the backlight. But what about the other one? There might be silent
regressions such as part of the RGB of the device not responding properly.

In the Z13, this is the case, with a race condition causing the lightbar
to control the asus::kbd_backlight device most of the time, with the
keyboard being renamed to asus::kbd_backlight_1 and not doing anything
under KDE controls.

Here, we should note that most backlight handlers are hardcoded to check
for backlight once, and for one backlight, during boot, so any other
solution would require a large rewrite of userspace.

Even when brightness controls are fixed, we still have the problem of the
backlight key being on/off when controlled by KDE and 0/33/66/100 when
the device has a WMI keyboard. Ideally, we would like the 0/33/66/100 to
be done under hid as well, regardless of whether the backlight of the
device is controlled by WMI or HID.

Therefore, this is what the third part of this series does. It sets up
asus-wmi to expose accepting listeners for the asus::kbd_backlight device
and being the one that sets it up. Then, it makes hid-asus devices
register a listener there, so that all of them are controlled by
asus::kbd_backlight. Finally, it adds an event handler for keyboard keys,
so that HID led controls are handled by the kernel instead of userspace.
This way, even when userspace is not active the key works, and we get the
desired behavior of 0/33/66/100 across all Aura devices (currently, that
is keyboards, and embedded devices such as lightbars). This results
removing the quirk system as well, eliminating a point of failure.

I tested this on an Asus Z13 2025, and testing by other devices would be
appreciated for sure. This series is designed to be transparent to
userspace behavior-wise compared previous kernels, with all existing
laptops either having the same behavior or being better.

The Z13 keyboard folio RGB controls work beautifully, with KDE led
notifications working and doing 0/33/66/100 as expected. This also happens
with hotplugging, as the lightbar is always available and keeps the
endpoint alive from boot, even if the folio is not connected (a quirk
can be added later if there is a device where this is not the case).

The first two parts of the series can also be merged independently of the
third part, so we can iterate on that more. Perhaps there is a better way
to handle this cohesion,

Oh, by the way Luke, I developed this series with a variant of
your Armoury series merged, and only switched to 6.14-v7 for this
submission. You will be happy to know that there are no conflicts :)
(at least with that version from ~January). Also, please factcheck
my initialization sequence is correct in the 0x5d and 0x5e devices
you added when you made that refactor last year. Are those handshakes
needed?

Antheas Kapenekakis (11):
  HID: asus: refactor init sequence per spec
  HID: asus: cleanup keyboard backlight check
  HID: asus: prevent binding to all HID devices on ROG
  HID: asus: rename keyboard3 to Z13_FOLIO
  HID: asus: add Asus Z13 2025 Fan key
  HID: asus: introduce small delay on Asus Z13 RGB init
  platform/x86: asus-wmi: Add support for multiple kbd RGB handlers
  HID: asus: listen to the asus-wmi brightness device instead of
    creating one
  platform/x86: asus-wmi: remove unused keyboard backlight quirk
  platform/x86: asus-wmi: add keyboard brightness event handler
  HID: asus: add support for the asus-wmi brightness handler

 drivers/hid/hid-asus.c                     | 220 ++++++++++++---------
 drivers/hid/hid-ids.h                      |   2 +-
 drivers/platform/x86/asus-wmi.c            | 137 +++++++++++--
 include/linux/platform_data/x86/asus-wmi.h |  66 +++----
 4 files changed, 279 insertions(+), 146 deletions(-)


base-commit: 4701f33a10702d5fc577c32434eb62adde0a1ae1
-- 
2.48.1

Powered by blists - more mailing lists