Re: [PATCH 00/11] HID: asus: hid-asus and asus-wmi backlight unification, Z13 QOL improvements

[Luke Jones]

Hi Antheas,

On Thu, 20 Mar 2025, at 8:13 AM, Antheas Kapenekakis wrote:
> 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.

This makes me wish there was better standardization. Maybe filing some reports upstream to those various projects could get the ball rolling?

> 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.

Nice, I'd been looking at doing something similar but unfortunately hadn't the time for it, nor the device appropriate for testing (keyboard, detachable, lightbar). TBH I wish there was a much better way in kernel to handle these sorts of lighting situations, especially given that we have laptops across vendors and models with different modes, zones, per-key, MCU mode vs software mode etc etc. There is a *very* long thread on lkml bikeshedding it all too - see https://lore.kernel.org/lkml/20231011190017.1230898-1-wse@xxxxxxxxxxxxxxxxxxx/

The LampArray thing is out of scope for this, but I thought maybe worth mentioning in case you weren't aware. The major pitfall of it is that per-key devices update per-row and when you do a single key update to update a whole keyboard it sends N-Key amounts of packets..

Off-topic though. But if you have some ideas please email me.

> 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.

I have a handful of laptops I can test, including my old GA501, I'll get on it.

> 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).

Very good. This will make a lot of folks happy, I suspect the Z13 is going to be a very popular device.

> 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,

After a quick cursory look, this looks good so far. Perhaps after review and iteration you could submit as an independent series to get those parts in quicker - but hey we can cross that when we get to it.

> 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?

I would hope the armoury driver stays out of the way of most things, I tried to make it independent. The handshakes are needed for sure, depending on device it may be partial or more, but it's always been the same ASCII right back to when I first started on this with a 2018 laptop - we never bothered with the response check though. I do forget what required the 0x5e init, I'll need to check through some old notes.

I'll apologize in advance for the time it might take me to review - I'll attempt some now for the smaller patches, but hopefully I can get some time in this weekend and we can work together to make asus stuff even better.

Cheers,
Luke.

> 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