[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250112121811.434552-1-hacker1024@users.sourceforge.net>
Date: Sun, 12 Jan 2025 12:18:28 +0000
From: Josh Leivenzon <joshleivenzon@...look.com>
To: "luke@...nes.dev" <luke@...nes.dev>
CC: "bentiss@...nel.org" <bentiss@...nel.org>, "corentin.chary@...il.com"
<corentin.chary@...il.com>, "hdegoede@...hat.com" <hdegoede@...hat.com>,
"ilpo.jarvinen@...ux.intel.com" <ilpo.jarvinen@...ux.intel.com>,
"jikos@...nel.org" <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
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
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.
Are there devices that use the ROG_NKEY_KEYBOARDs where HID doesn't work?
Powered by blists - more mailing lists