Message-ID: 
 <CAGwozwEV36Bc0-UgysTv5g7OfrB1=rNfy4XKE7gXOhOvZ1e_6g@mail.gmail.com>
Date: Wed, 19 Nov 2025 02:27:21 +0100
From: Antheas Kapenekakis <lkml@...heas.dev>
To: Denis Benato <benato.denis96@...il.com>
Cc: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
	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 05/10] HID: asus: initialize LED endpoint early for old
 NKEY keyboards

On Wed, 19 Nov 2025 at 02:21, Denis Benato <benato.denis96@...il.com> wrote:
>
>
> On 11/19/25 02:11, Antheas Kapenekakis wrote:
> > On Wed, 19 Nov 2025 at 01:54, Denis Benato <benato.denis96@...il.com> wrote:
> >>
> >> On 11/18/25 13:10, Ilpo Järvinen wrote:
> >>> On Sat, 1 Nov 2025, Antheas Kapenekakis wrote:
> >>>
> >>>> These keyboards have always had initialization in the kernel for 0x5d.
> >>>> At this point, it is hard to verify again and we risk regressions by
> >>>> removing this. Therefore, initialize with 0x5d as well.
> >> See patch 1: unless I missed something you can retain the two
> >> FEATURE_KBD_LED_REPORT_IDx behind the same exact quirk:
> >> why are we adding a quirk to replace a quirk that was removed
> >> in patch 1?
> >>
> >> You are basically doing the pretty-much-but-not-quite
> >> equivalent of what the driver was doing before.
> >>>> Signed-off-by: Antheas Kapenekakis <lkml@...heas.dev>
> >>>> ---
> >>>>  drivers/hid/hid-asus.c | 15 +++++++++++++--
> >>>>  1 file changed, 13 insertions(+), 2 deletions(-)
> >>>>
> >>>> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
> >>>> index 726f5d8e22d1..221c7195e885 100644
> >>>> --- a/drivers/hid/hid-asus.c
> >>>> +++ b/drivers/hid/hid-asus.c
> >>>> @@ -91,6 +91,7 @@ MODULE_DESCRIPTION("Asus HID Keyboard and TouchPad");
> >>>>  #define QUIRK_ROG_CLAYMORE_II_KEYBOARD BIT(12)
> >>>>  #define QUIRK_ROG_ALLY_XPAD         BIT(13)
> >>>>  #define QUIRK_SKIP_REPORT_FIXUP             BIT(14)
> >>>> +#define QUIRK_ROG_NKEY_LEGACY               BIT(15)
> >>>>
> >>>>  #define I2C_KEYBOARD_QUIRKS                 (QUIRK_FIX_NOTEBOOK_REPORT | \
> >>>>                                               QUIRK_NO_INIT_REPORTS | \
> >>>> @@ -669,6 +670,16 @@ static int asus_kbd_register_leds(struct hid_device *hdev)
> >>>>      if (ret < 0)
> >>>>              return ret;
> >>>>
> >>>> +    if (drvdata->quirks & QUIRK_ROG_NKEY_LEGACY) {
> >>>> +            /*
> >>>> +             * These keyboards might need 0x5d for shortcuts to work.
> >>>> +             * As it has been more than 5 years, it is hard to verify.
> >>>> +             */
> >>>> +            ret = asus_kbd_init(hdev, FEATURE_KBD_LED_REPORT_ID1);
> >>>> +            if (ret < 0)
> >>>> +                    return ret;
> >>>> +    }
> >>>> +
> >>>>      /* Get keyboard functions */
> >>>>      ret = asus_kbd_get_functions(hdev, &kbd_func, FEATURE_KBD_REPORT_ID);
> >>>>      if (ret < 0)
> >>>> @@ -1409,10 +1420,10 @@ static const struct hid_device_id asus_devices[] = {
> >>>>        QUIRK_USE_KBD_BACKLIGHT },
> >>>>      { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
> >>>>          USB_DEVICE_ID_ASUSTEK_ROG_NKEY_KEYBOARD),
> >>>> -      QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD },
> >>>> +      QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD | QUIRK_ROG_NKEY_LEGACY },
> >>>>      { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
> >>>>          USB_DEVICE_ID_ASUSTEK_ROG_NKEY_KEYBOARD2),
> >>>> -      QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD },
> >>>> +      QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD | QUIRK_ROG_NKEY_LEGACY },
> >>>>      { HID_USB_DEVICE(USB_VENDOR_ID_ASUSTEK,
> >>>>          USB_DEVICE_ID_ASUSTEK_ROG_Z13_LIGHTBAR),
> >>>>        QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD },
> >>> You should do FEATURE_KBD_LED_REPORT_ID1 refactoring together, not remove
> >>> + add back in different patches.
> >> Granted I still have no idea why that was removed in the first place?
> >> Then re-added but losing FEATURE_KBD_LED_REPORT_ID1 ?
> >>
> >> What's the problem with FEATURE_KBD_LED_REPORT_ID1?
> >>
> >>> I suppose the cleanest would be to add a new patch as first which moves
> >>> asus_kbd_init() outside of if/else so you can make this refactoring of
> >>> FEATURE_KBD_LED_REPORT_ID1 in the 2nd patch.
> >> Again I am missing the point in moving these...
> >>> I note there's still contention with this series overall.
> >>>
> >> There are a few things that have pretty much the potential of making
> >> some laptops act funny due to tinkering with initializations commands.
> >>
> >> The rename will break some tools, but other than that, granted I have yet
> >> to check the rest of the patchset, looks reasonable to me.
> >>
> >> Perhaps I am not entirely happy with how things are worded in
> >> a few instances, but it's a minor issue.
> > Hi Denis,
> > please refrain from repeating yourself, in the same email and across
> > emails, and repeating comments that are already addressed by Ilpo. As
> > that makes it hard to track and respond to your comments.
> My repetitions are due to confusion with different aspects of what
> you are doing, but I'll try to be less repetitive.
>
> Also I don't think I have said the very same exact things as
> Ilpo, unless I misunderstood something.
> > As noted in this chain, the plan for the next version is to include
> > ID2 in this quirk and instead of removing it in the simplify patch,
> > use a gate by the ROG quirk that is then replaced by a gate from this
> > quirk.
> Yeah but I also asked (perhaps too many times?) what's up with _ID1
> and the whole reasoning behind this because as it stands now
> you are replacing X with Y, only to do Z without making clear to me
> the reason of Y, therefore Z also suffers from the same problem.
> > This completely addresses your comment. The legacy quirk only applies
> > to a subset of devices, so it is not the same with this series
> > applied.
> And the reason for this difference is exactly what I am asking for.
>
> I have been trying to suggest things to describe and actions
> to take/specific code changes to ensure we agree...

New devices do not need the 0x5d/0x5e inits. This is especially true
for those that do not have those endpoints. Specifically, devices
without Anime/an S? (I do not recall the name currently) animation
feature do not have a 0x5e endpoint, and devices without RGB do not
have a 0x5d endpoint. But they currently get sent these inits anyway.

For some old devices, they might need 0x5d to init the keyboard
shortcuts, but that is not certain. It is too late by this point to
verify though, so the legacy patch will keep those for the next revision.

Antheas

> > Antheas
> >
>

Powered by blists - more mailing lists