linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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" <hansg@kernel.org>,
	"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Subject: Re: [PATCH v9 06/11] HID: asus: early return for ROG devices
Date: Thu, 20 Nov 2025 15:29:31 +0100	[thread overview]
Message-ID: <5e577dcf-995e-441b-9351-11d6da097fcc@gmail.com> (raw)
In-Reply-To: <CAGwozwEk0k3K8v2GOX2+9Rrcx_pp4xAmiJExzoRNADeridRTfA@mail.gmail.com>


On 11/20/25 15:15, Antheas Kapenekakis wrote:
> On Thu, 20 Nov 2025 at 14:29, Denis Benato <benato.denis96@gmail.com> wrote:
>>
>> On 11/20/25 10:46, Antheas Kapenekakis wrote:
>>> Some ROG devices have a new dynamic backlight interface for control by
>>> Windows. This interface does not create an ->input device, causing the
>>> kernel to print an error message and to eject it. In addition, ROG
>>> devices have proper HID names in their descriptors so renaming them is
>>> not necessary.
>> Is this patchset supposed to work without the renaming, correct?
>>
>> If so consider dropping the drop of renames, taking required time
>> to organize with Derek and resubmit when things are ready:
>> there is no point for the rename to stall the rest and quit renaming
>> is not urgent at all.
> I feel like two months is enough of a timeframe for a simple rename
> fix to go in.
>
> I do not want to have to reorder the checks just so the rename can
> stay in _for now_. Skipping the ->input check is important for both
> Xbox Ally/Z13 as it causes errors and the device to stay partially
> uninitialized.
>
>>> Therefore, if a device is identified as ROG, early return from probe to
>>> skip renaming and ->input checks.
>>>
>>> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
>>> ---
>>>  drivers/hid/hid-asus.c | 7 +++++++
>>>  1 file changed, 7 insertions(+)
>>>
>>> diff --git a/drivers/hid/hid-asus.c b/drivers/hid/hid-asus.c
>>> index 3047bc54bf2e..6193c9483bec 100644
>>> --- a/drivers/hid/hid-asus.c
>>> +++ b/drivers/hid/hid-asus.c
>>> @@ -1236,6 +1236,13 @@ static int asus_probe(struct hid_device *hdev, const struct hid_device_id *id)
>>>           asus_kbd_register_leds(hdev))
>>>               hid_warn(hdev, "Failed to initialize backlight.\n");
>>>
>>> +     /*
>>> +      * For ROG keyboards, skip rename for consistency and ->input check as
>>> +      * some devices do not have inputs.
>>> +      */
>>> +     if (drvdata->quirks & QUIRK_ROG_NKEY_KEYBOARD)
>>> +             return 0;
>>> +
>>>       /*
>>>        * Check that input registration succeeded. Checking that
>>>        * HID_CLAIMED_INPUT is set prevents a UAF when all input devices
>> Just for clarity is this supposed to fix this: https://gitlab.com/asus-linux/asusctl/-/issues/700 ?
>> This model works once in windows users disable  that new feature.
>>
>> Note: that kernel the person submitting the bug is using contains your v8
>> and asus-armoury.
>>
> No. This user has a laptop that has at least a WMI implementation of
> RGB controls (this is why you can see rgb settings). Since you did not
> ask for logs, it is not clear if it also has a HID implementation that
> is skipped due to e.g., a missing product ID. Very likely it is a bug
> on the WMI implementation that is out of scope for this series.
I will ask for logs, but I recall someone with the same model sent dmesg already,
I'll try to find it, but if this is true... Are we lending control of LEDs to a bugged WMI
implementation for this laptop?

  reply	other threads:[~2025-11-20 14:29 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-20  9:46 [PATCH v9 00/11] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling Antheas Kapenekakis
2025-11-20  9:46 ` [PATCH v9 01/11] HID: asus: simplify RGB init sequence Antheas Kapenekakis
2025-11-20  9:46 ` [PATCH v9 02/11] HID: asus: initialize additional endpoints only for legacy devices Antheas Kapenekakis
2025-11-20  9:46 ` [PATCH v9 03/11] HID: asus: use same report_id in response Antheas Kapenekakis
2025-11-20  9:46 ` [PATCH v9 04/11] HID: asus: fortify keyboard handshake Antheas Kapenekakis
2025-11-20 14:15   ` Denis Benato
2025-11-20 14:28     ` Antheas Kapenekakis
2025-11-20 14:31       ` Denis Benato
2025-11-20 16:41       ` Ilpo Järvinen
2025-11-20 21:54         ` Antheas Kapenekakis
2025-11-21 10:11           ` Ilpo Järvinen
2025-11-20  9:46 ` [PATCH v9 05/11] HID: asus: move vendor initialization to probe Antheas Kapenekakis
2025-11-20  9:46 ` [PATCH v9 06/11] HID: asus: early return for ROG devices Antheas Kapenekakis
2025-11-20 13:29   ` Denis Benato
2025-11-20 14:15     ` Antheas Kapenekakis
2025-11-20 14:29       ` Denis Benato [this message]
2025-11-20 14:43         ` Antheas Kapenekakis
2025-11-20  9:46 ` [PATCH v9 07/11] platform/x86: asus-wmi: Add support for multiple kbd led handlers Antheas Kapenekakis
2025-11-20 13:46   ` Denis Benato
2025-11-20 14:40     ` Antheas Kapenekakis
2025-11-20 16:38     ` Ilpo Järvinen
2025-11-20  9:46 ` [PATCH v9 08/11] HID: asus: listen to the asus-wmi brightness device instead of creating one Antheas Kapenekakis
2025-11-20  9:46 ` [PATCH v9 09/11] platform/x86: asus-wmi: remove unused keyboard backlight quirk Antheas Kapenekakis
2025-11-20  9:46 ` [PATCH v9 10/11] platform/x86: asus-wmi: add keyboard brightness event handler Antheas Kapenekakis
2025-11-20  9:46 ` [PATCH v9 11/11] HID: asus: add support for the asus-wmi brightness handler Antheas Kapenekakis
2025-11-20 14:22   ` Denis Benato

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=5e577dcf-995e-441b-9351-11d6da097fcc@gmail.com \
    --to=benato.denis96@gmail.com \
    --cc=bentiss@kernel.org \
    --cc=corentin.chary@gmail.com \
    --cc=hansg@kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).