Message-ID: <f4046f26-7d07-41b1-8332-a59fa8903f8f@gmail.com>
Date: Wed, 19 Nov 2025 00:17:56 +0100
From: Denis Benato <benato.denis96@...il.com>
To: Antheas Kapenekakis <lkml@...heas.dev>,
 Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc: platform-driver-x86@...r.kernel.org, linux-input@...r.kernel.org,
 LKML <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>
Subject: Re: [PATCH v8 01/10] HID: asus: simplify RGB init sequence


On 11/18/25 14:07, Antheas Kapenekakis wrote:
> On Tue, 18 Nov 2025 at 13:23, Ilpo Järvinen
> <ilpo.jarvinen@...ux.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@...heas.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);
>>>

Powered by blists - more mailing lists