Message-ID: 
 <CAGwozwGj-yXHXBan38_NV7G5T66bnjm7om2bz_Bha35AHhtCJQ@mail.gmail.com>
Date: Fri, 24 Oct 2025 01:25:10 +0200
From: Antheas Kapenekakis <lkml@...heas.dev>
To: Denis Benato <benato.denis96@...il.com>
Cc: platform-driver-x86@...r.kernel.org, linux-input@...r.kernel.org,
	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>,
	Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Subject: Re: [PATCH v7 1/9] HID: asus: simplify RGB init sequence

On Fri, 24 Oct 2025 at 00:53, Denis Benato <benato.denis96@...il.com> wrote:
>
>
> On 10/23/25 23:30, Antheas Kapenekakis wrote:
> > On Thu, 23 Oct 2025 at 22:05, Denis Benato <benato.denis96@...il.com> wrote:
> >>
> >> On 10/23/25 20:06, Antheas Kapenekakis wrote:
> >>> On Thu, 23 Oct 2025 at 19:38, Denis Benato <benato.denis96@...il.com> wrote:
> >>>> On 10/18/25 12:17, 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.
> >>>> What benefits do we get from removing the unused initialization?
> >>>>
> >>>> If this has never caused any troubles I don't see the reason for removing
> >>>> them. Moreover the lighting protocol is known and I might as well add
> >>>> support for it in the near future,
> >>> I already have a patch that adds RGB and delay inits that endpoint. It
> >>> got removed to make this easier to merge. See [1].
> >>>
> >>> [1] https://lore.kernel.org/lkml/20250324210151.6042-10-lkml@antheas.dev/
> >> I have to main concerns about this:
> >>
> >> 1. taking away initialization commands in one patchset to make it
> >> easier to merge another unrelated patch doesn't seem the right thing
> >> to do if the other patch it's not in the same series.
> >>
> >> I can see [1] has been removed from the set for a later moment in time,
> >> it's fine if it needs more work, just send something that function in the
> >> same way and do not remove initialization commands when unnecessary,
> >> especially since there will be for sure future development.
> > The initialization was removed as part of general cleanup. Not to make
> > it easier to merge the RGB patch. In addition, the RGB patch only runs
> > the init in a lazy fashion, so if nobody uses the RGB sysfs the init
> > does not run and the behavior is the same.
> There are a few problems here:
> 1. sope creep: either do a cleanup or solve bugs. The fact that your flow z13
> doesn't load hid-asus correctly has nothing to do with the initialization of anime.
> The fact that hid-asus is driving leds instead of asus-wmi has nothing to do with
> anime matrix initialization either.
> 2. not sending the initialization can get hardware misbehave because it
> is left in an uninitialized state.
> 3. there are absolutely zero reasons to do that. There are even less reasons
> as to do it as part of this patchset.
>
> >> 2. Your patchset resolves around keyboard backlight control and how
> >> the keyboard device is exposed to userspace: it's fine but I do not see
> >> the point in removing initialization commands that has nothing to do
> >> with the issue we are trying to solve here.
> >>
> >> Please leave 0x5E and 0x5D initialization commands where they are now.
> > I mean the second part of the patchset does that. The first part is a
> > cleanup. What would be the reason for keeping 0x5E and 0x5D? They are
> > only used when initializing those endpoints to write further commands
> > to them and for identification. The current driver does not write
> > commands to those endpoints and identifies itself over 0x5A.
> There are no bugs opened that ties initialization of devices to bugs.
> Quite the opposite: I can guarantee you that removing part of the
> init will introduce regressions.
>
> The onus is on you to provide strong evidence that the removal is
> a necessary act.
>
> Regardless it is not in the scope of this patchset: remove it.
> > I do get that it is a bit risky as some laptops might be hardcoded to
> > wait for 0x5D to turn on RGB. Which is why we had the last patch until
> > V4. But we have yet to find a laptop that has this problem, so I find
> > it difficult to justify keeping the init.
> Yes it's risky to remove initialization sequences for a device that is
> in every modern ASUS laptop and is tied to the EC.
> > Do note that you might need to add the 0x5D init to your userspace
> > program for certain laptops if you haven't already. But that is ok,
> > since in doing so you are also validating you are speaking to an Asus
> > device, which is important.
> This doesn't make much sense: why would anyone remove
> a command from the kernel, that can be very well essential to some models
> (sleep can break, for example) just to add it back in a userspace program?
>
> What does it mean I have to validate I am speaking to an asus device?
> Software selects devices by known attribute, one of them is the vid:pid....
> Beside what does this have to do with the removal of initialization commands
> from the kernel?
>
> Even late initializing devices can lead to problems. Windows doesn't do that:
> as soon as asus drivers are loaded all relevant initialization sequences are
> sent; Windows is the only officially supported OS: do not introduce commands
> flow divergence without strong reasons backing it up.

If you think keeping 0x5D init is that important, I can spin patch [1]
into this series. But then this quirk will stay in the kernel forever.
I can even add 0x5E since that does not affect newer devices, which I
care for simplifying the sequence.

Luke said these two pairs are the important ones to keep.

I'm not sure what to do.

Antheas

[1] https://lore.kernel.org/all/20250325184601.10990-12-lkml@antheas.dev/

> > Antheas
> >
> Denis
> >>>>> 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;
> >>>>> -
> >>>>> -             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