From: Denis Benato <benato.denis96@gmail.com>
To: Antheas Kapenekakis <lkml@antheas.dev>
Cc: platform-driver-x86@vger.kernel.org, linux-input@vger.kernel.org,
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>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Subject: Re: [PATCH v7 1/9] HID: asus: simplify RGB init sequence
Date: Thu, 23 Oct 2025 22:04:57 +0200 [thread overview]
Message-ID: <3947f772-691b-46a2-af68-15825e7f4939@gmail.com> (raw)
In-Reply-To: <CAGwozwG+gf09PQf9o9YkKFYVgVn-1w5CDVrpOe4uFavVYCNijQ@mail.gmail.com>
On 10/23/25 20:06, Antheas Kapenekakis wrote:
> On Thu, 23 Oct 2025 at 19:38, Denis Benato <benato.denis96@gmail.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.
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.
>>> 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;
>>> -
>>> - 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-10-23 20:05 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-18 10:17 [PATCH v7 0/9] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling Antheas Kapenekakis
2025-10-18 10:17 ` [PATCH v7 1/9] HID: asus: simplify RGB init sequence Antheas Kapenekakis
2025-10-23 17:38 ` Denis Benato
2025-10-23 18:06 ` Antheas Kapenekakis
2025-10-23 20:04 ` Denis Benato [this message]
2025-10-23 21:30 ` Antheas Kapenekakis
2025-10-23 22:53 ` Denis Benato
2025-10-23 23:25 ` Antheas Kapenekakis
2025-10-24 16:20 ` Antheas Kapenekakis
2025-10-24 18:53 ` Denis Benato
2025-10-24 21:20 ` Antheas Kapenekakis
2025-10-25 1:25 ` Denis Benato
2025-10-25 7:20 ` Antheas Kapenekakis
2025-10-18 10:17 ` [PATCH v7 2/9] HID: asus: use same report_id in response Antheas Kapenekakis
2025-10-18 10:17 ` [PATCH v7 3/9] HID: asus: fortify keyboard handshake Antheas Kapenekakis
2025-10-18 10:17 ` [PATCH v7 4/9] HID: asus: prevent binding to all HID devices on ROG Antheas Kapenekakis
2025-10-23 18:23 ` Denis Benato
2025-10-23 18:27 ` Antheas Kapenekakis
2025-10-18 10:17 ` [PATCH v7 5/9] platform/x86: asus-wmi: Add support for multiple kbd led handlers Antheas Kapenekakis
2025-10-22 13:38 ` kernel test robot
2025-10-23 6:56 ` Antheas Kapenekakis
2025-10-31 8:26 ` Jiri Kosina
2025-10-31 12:13 ` Antheas Kapenekakis
2025-11-03 4:28 ` Derek J. Clark
2025-11-03 7:36 ` Antheas Kapenekakis
2025-11-03 8:37 ` luke
2025-11-03 8:48 ` Antheas Kapenekakis
2025-11-03 9:05 ` luke
2025-11-03 9:15 ` Antheas Kapenekakis
2025-10-18 10:17 ` [PATCH v7 6/9] HID: asus: listen to the asus-wmi brightness device instead of creating one Antheas Kapenekakis
2025-10-18 10:17 ` [PATCH v7 7/9] platform/x86: asus-wmi: remove unused keyboard backlight quirk Antheas Kapenekakis
2025-10-18 10:17 ` [PATCH v7 8/9] platform/x86: asus-wmi: add keyboard brightness event handler Antheas Kapenekakis
2025-10-18 10:17 ` [PATCH v7 9/9] HID: asus: add support for the asus-wmi brightness handler 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=3947f772-691b-46a2-af68-15825e7f4939@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