Message-ID: 
 <CAGwozwEh32XMcGJPKMRBWd63ybYOxW1Wx4QjU-QErjQgLHwX2g@mail.gmail.com>
Date: Fri, 24 Oct 2025 18:20:13 +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 01:25, Antheas Kapenekakis <lkml@...heas.dev> wrote:
>
> 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.

I was asked by a 2025 Asus Zenbook Duo user to add his IDs in [1]. In
doing so, I updated the rgb and legacy init patches for the new series
and added a quirk for early init of the duo keyboards.

The series is 14 patches long, I don't think my email can take it :(

Should we merge the first part of this series with the legacy init,
then do the backlight refactor, and finally the new Duo stuff + rgb?

Antheas

> 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