[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <e5091e50-a023-405d-a8f1-058f6a17f9e7@app.fastmail.com>
Date: Mon, 13 Jan 2025 13:37:13 +1300
From: "Luke Jones" <luke@...nes.dev>
To: "Josh Leivenzon" <joshleivenzon@...look.com>
Cc: "Benjamin Tissoires" <bentiss@...nel.org>,
"corentin.chary@...il.com" <corentin.chary@...il.com>,
"Hans de Goede" <hdegoede@...hat.com>,
Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
"Jiri Kosina" <jikos@...nel.org>,
"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"platform-driver-x86@...r.kernel.org" <platform-driver-x86@...r.kernel.org>
Subject: Re: [PATCH v3 1/1] hid-asus: use hid for brightness control on keyboard
On Mon, 13 Jan 2025, at 1:18 AM, Josh Leivenzon wrote:
> Hello,
>
> Thanks for this patch. I'm looking at doing something similar for the Zenbook
> Duo 2024 keyboard, which, I'm discovering, is similar to the ROG_NKEY_KEYBOARD
> devices in a number of ways.
>
> Something unique about the Zenbook Duo keyboard is that it has an external
> data-capable USB-C port, meaning it can be used as a regular USB keyboard for
> any device. This means that even if WMI features work, it is highly preferable
> to use HID alternatives where possible in order to allow those features to work
> on any Linux device that the keyboard is plugged in to.
>
> This leads me to my question: Why the DMI check on the HID side? This is a
It's because I couldn't see a good way to both disable the WMI backlight and use HID. On some laptops both WMI and HID work, but on some WMI methods exist but don't work at all. The DMI check ends up being something of a blanket check across those family or models as they all used different generations of the MCU at one point but all have HID brightness control.
The key part is we need to tell asus-wmi not to use WMI for brightness on those product ranges. I have at least 4 years of data in this rather disorganised repo if you're curious about other models (And I always take contributions) - https://gitlab.com/asus-linux/reverse-engineering
> little problematic for me, as it blocks functionallity on other devices. Would
> it be sufficient to use quirks only in that case? The important part, to my
> understanding, is that the WMI module disables itself properly, which is still
> covered by its own DMI check.
asus-wmi is still used for many things, so it's really only the LED handling that needs disabling when required.
> Are there devices that use the ROG_NKEY_KEYBOARDs where HID doesn't work?
Not that I know of, and I think this goes right back to 2019 with the:
#define USB_DEVICE_ID_ASUSTEK_ROG_NKEY_KEYBOARD 0x1866
These ones span 2015-2019 I think, and are rare to find in use still, but from what I've managed to find and from the odd report back they also use HID:
#define USB_DEVICE_ID_ASUSTEK_ROG_KEYBOARD1 0x1854
#define USB_DEVICE_ID_ASUSTEK_ROG_KEYBOARD2 0x1837
#define USB_DEVICE_ID_ASUSTEK_ROG_KEYBOARD3 0x1822
I would love to have someone withe the hardware help to make this device better for all users. Some issues that may be useful or related are here:
https://github.com/flukejones/asusctl/issues/25
https://github.com/alesya-h/zenbook-duo-2024-ux8406ma-linux/pull/12
I also have a WIP branch here https://github.com/flukejones/linux/tree/wip/ally-6.13 (ignore name, it covers all asus)
If there is anything I can do to further help you please ping whenever you need.
Powered by blists - more mailing lists