From: Denis Benato <benato.denis96@gmail.com>
To: "Antheas Kapenekakis" <lkml@antheas.dev>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: platform-driver-x86@vger.kernel.org, linux-input@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>,
Jiri Kosina <jikos@kernel.org>,
Benjamin Tissoires <bentiss@kernel.org>,
Corentin Chary <corentin.chary@gmail.com>,
"Luke D . Jones" <luke@ljones.dev>,
Hans de Goede <hdegoede@redhat.com>
Subject: Re: [PATCH v8 01/10] HID: asus: simplify RGB init sequence
Date: Wed, 19 Nov 2025 00:17:56 +0100 [thread overview]
Message-ID: <f4046f26-7d07-41b1-8332-a59fa8903f8f@gmail.com> (raw)
In-Reply-To: <CAGwozwEen-gfuSKhRFXD3i7RpZUVWED+EJnA8R1aYYNs2SaWcA@mail.gmail.com>
On 11/18/25 14:07, Antheas Kapenekakis wrote:
> On Tue, 18 Nov 2025 at 13:23, Ilpo Järvinen
> <ilpo.jarvinen@linux.intel.com> wrote:
>> On Sat, 1 Nov 2025, Antheas Kapenekakis wrote:
>>
>>> Currently, RGB initialization forks depending on whether a device is
>>> NKEY. Then, NKEY devices are initialized using 0x5a, 0x5d, 0x5e
>>> endpoints, and non-NKEY devices with 0x5a and then a
>>> backlight check, which is omitted for NKEY devices.
>>>
>>> Remove the fork, using a common initialization sequence for both,
>>> where they are both only initialized with 0x5a, then checked for
>>> backlight support. This patch should not affect existing functionality.
>>>
>>> 0x5d and 0x5e endpoint initializations are performed by Windows
>>> userspace programs associated with different usages that reside under
>>> the vendor HID. Specifically, 0x5d is used by Armoury Crate, which
>>> controls RGB and 0x5e by an animation program for certain Asus laptops.
>>> Neither is used currently in the driver.
This patch is, as requested, not touching 0x5d and 0x5e so why mentioning them at all?
This text has become out of context IMHO.
>>> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
>>> ---
>>> drivers/hid/hid-asus.c | 56 ++++++++++++++----------------------------
>>> 1 file changed, 19 insertions(+), 37 deletions(-)
>>>
>>> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
>>> index a444d41e53b6..7ea1037c3979 100644
>>> --- a/drivers/hid/hid-asus.c
>>> +++ b/drivers/hid/hid-asus.c
>>> @@ -638,50 +638,32 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
>>> unsigned char kbd_func;
>>> int ret;
>>>
>>> - if (drvdata->quirks & QUIRK_ROG_NKEY_KEYBOARD) {
>>> - /* Initialize keyboard */
>>> - ret = asus_kbd_init(hdev, FEATURE_KBD_REPORT_ID);
>>> - if (ret < 0)
>>> - return ret;
>>> -
>>> - /* The LED endpoint is initialised in two HID */
>>> - ret = asus_kbd_init(hdev, FEATURE_KBD_LED_REPORT_ID1);
>>> - if (ret < 0)
>>> - return ret;
>>> -
>>> - ret = asus_kbd_init(hdev, FEATURE_KBD_LED_REPORT_ID2);
>>> - if (ret < 0)
>>> - return ret;
>> This removal of FEATURE_KBD_LED_REPORT_ID2 should definitely be in own
>> patch so a focused changelog can be written to it (who said it's
>> acceptable, etc. included) and it can be pinpointed with bisect if it
>> causes any issues (but I'm not entirely sure what Denis' stance is on this
>> removal so it's going to be subject to some further scrunity, but in any
>> case it must be in own patch if to be accepted).
> Yeah this is a fair approach.
You unified the init interface, but I see that there was divergence
that now is gone: both FEATURE_KBD_LED_REPORT_ID1 and
FEATURE_KBD_LED_REPORT_ID2 are not used in the initialization
now: I can only see two reasons for this:
- you don't think those are needed
- they will cause problems with asus_kbd_init that is changed in patch 3
What's the given reason here?
You can pretty much re-introduce the if (quirk) { those_two_init }
after the asus_kbd_get_functions as I don't see any reasons to remove that.
If we can't verify with hardware using it that quirk I think we can modify
these to not fail if the HID device doesn't answer back with expected data:
I am cross-referencing patch 3 here.
>> I'm wondering though if QUIRK_ROG_NKEY_LEGACY could also cover this? At
>> least it would look a path of less resistance when it comes to Denis'
>> stance and would decouple the remove or not controversy from acceptance of
>> this series.
Since what I see here is a (qurks excluded) mostly unified path for
all devices I will have to review that, but I already said that if we find
some common denominator to newer devices that could help us
in changing the flow specifically to those I am also open to this
possibility.
> So a way forward would be on the simplify patch, to use an if rog
> statement to do ID1 and ID2 and then on the next patch replace the
> quirk in the if check with the legacy quirk. This is ok with me, as
> those are older devices.
After the fourth time of re-reading this I have no idea what you are
proposing here. Sorry.
> Antheas
I am slowly going through patches and sending comments while also
reviewing them with more detail.
>> --
>> i.
>>
>>> - if (dmi_match(DMI_PRODUCT_FAMILY, "ProArt P16")) {
>>> - ret = asus_kbd_disable_oobe(hdev);
>>> - if (ret < 0)
>>> - return ret;
>>> - }
>>> -
>>> - if (drvdata->quirks & QUIRK_ROG_ALLY_XPAD) {
>>> - intf = to_usb_interface(hdev->dev.parent);
>>> - udev = interface_to_usbdev(intf);
>>> - validate_mcu_fw_version(hdev,
>>> - le16_to_cpu(udev->descriptor.idProduct));
>>> - }
>>> + ret = asus_kbd_init(hdev, FEATURE_KBD_REPORT_ID);
>>> + if (ret < 0)
>>> + return ret;
>>>
>>> - } else {
>>> - /* Initialize keyboard */
>>> - ret = asus_kbd_init(hdev, FEATURE_KBD_REPORT_ID);
>>> - if (ret < 0)
>>> - return ret;
>>> + /* Get keyboard functions */
>>> + ret = asus_kbd_get_functions(hdev, &kbd_func, FEATURE_KBD_REPORT_ID);
>>> + if (ret < 0)
>>> + return ret;
>>>
>>> - /* Get keyboard functions */
>>> - ret = asus_kbd_get_functions(hdev, &kbd_func, FEATURE_KBD_REPORT_ID);
>>> + if (dmi_match(DMI_PRODUCT_FAMILY, "ProArt P16")) {
>>> + ret = asus_kbd_disable_oobe(hdev);
>>> if (ret < 0)
>>> return ret;
>>> + }
>>>
>>> - /* Check for backlight support */
>>> - if (!(kbd_func & SUPPORT_KBD_BACKLIGHT))
>>> - return -ENODEV;
>>> + if (drvdata->quirks & QUIRK_ROG_ALLY_XPAD) {
>>> + intf = to_usb_interface(hdev->dev.parent);
>>> + udev = interface_to_usbdev(intf);
>>> + validate_mcu_fw_version(
>>> + hdev, le16_to_cpu(udev->descriptor.idProduct));
>>> }
>>>
>>> + /* Check for backlight support */
>>> + if (!(kbd_func & SUPPORT_KBD_BACKLIGHT))
>>> + return -ENODEV;
>>> +
>>> drvdata->kbd_backlight = devm_kzalloc(&hdev->dev,
>>> sizeof(struct asus_kbd_leds),
>>> GFP_KERNEL);
>>>
next prev parent reply other threads:[~2025-11-18 23:17 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-01 10:47 [PATCH v8 00/10] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling Antheas Kapenekakis
2025-11-01 10:47 ` [PATCH v8 01/10] HID: asus: simplify RGB init sequence Antheas Kapenekakis
2025-11-18 12:23 ` Ilpo Järvinen
2025-11-18 13:07 ` Antheas Kapenekakis
2025-11-18 23:17 ` Denis Benato [this message]
2025-11-01 10:47 ` [PATCH v8 02/10] HID: asus: use same report_id in response Antheas Kapenekakis
2025-11-18 23:20 ` Denis Benato
2025-11-01 10:47 ` [PATCH v8 03/10] HID: asus: fortify keyboard handshake Antheas Kapenekakis
2025-11-18 23:43 ` Denis Benato
2025-11-18 23:46 ` Antheas Kapenekakis
2025-11-18 23:46 ` luke
2025-11-19 1:46 ` Denis Benato
2025-11-19 7:22 ` Ilpo Järvinen
2025-11-01 10:47 ` [PATCH v8 04/10] HID: asus: prevent binding to all HID devices on ROG Antheas Kapenekakis
2025-11-19 0:38 ` Denis Benato
2025-11-19 1:45 ` Antheas Kapenekakis
2025-11-19 2:33 ` Denis Benato
2025-11-19 8:00 ` Ilpo Järvinen
2025-11-01 10:47 ` [PATCH v8 05/10] HID: asus: initialize LED endpoint early for old NKEY keyboards Antheas Kapenekakis
2025-11-18 12:10 ` Ilpo Järvinen
2025-11-19 0:54 ` Denis Benato
2025-11-19 1:11 ` Antheas Kapenekakis
2025-11-19 1:21 ` Denis Benato
2025-11-19 1:27 ` Antheas Kapenekakis
2025-11-19 7:55 ` Ilpo Järvinen
2025-11-01 10:47 ` [PATCH v8 06/10] platform/x86: asus-wmi: Add support for multiple kbd led handlers Antheas Kapenekakis
2025-11-01 10:47 ` [PATCH v8 07/10] HID: asus: listen to the asus-wmi brightness device instead of creating one Antheas Kapenekakis
2025-11-01 10:47 ` [PATCH v8 08/10] platform/x86: asus-wmi: remove unused keyboard backlight quirk Antheas Kapenekakis
2025-11-01 10:47 ` [PATCH v8 09/10] platform/x86: asus-wmi: add keyboard brightness event handler Antheas Kapenekakis
2025-11-01 10:47 ` [PATCH v8 10/10] HID: asus: add support for the asus-wmi brightness handler Antheas Kapenekakis
2025-11-12 12:44 ` [PATCH v8 00/10] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling Antheas Kapenekakis
2025-11-12 13:21 ` Ilpo Järvinen
2025-11-12 13:41 ` Antheas Kapenekakis
2025-11-12 19:51 ` Denis Benato
2025-11-12 22:08 ` Antheas Kapenekakis
2025-11-12 23:22 ` Antheas Kapenekakis
2025-11-13 0:45 ` Denis Benato
2025-11-13 1:14 ` Denis Benato
2025-11-13 8:44 ` Antheas Kapenekakis
2025-11-13 20:23 ` luke
2025-11-13 21:17 ` Antheas Kapenekakis
2025-11-13 22:09 ` luke
2025-11-13 22:41 ` Antheas Kapenekakis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f4046f26-7d07-41b1-8332-a59fa8903f8f@gmail.com \
--to=benato.denis96@gmail.com \
--cc=bentiss@kernel.org \
--cc=corentin.chary@gmail.com \
--cc=hdegoede@redhat.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=jikos@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkml@antheas.dev \
--cc=luke@ljones.dev \
--cc=platform-driver-x86@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).