Message-ID: <84c35953-51ec-4c61-853c-cfd324382271@proton.me>
Date: Wed, 10 Dec 2025 17:19:05 +0000
From: Kelsios <K3lsios@...ton.me>
To: Antheas Kapenekakis <lkml@...heas.dev>, Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
Cc: 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 <hansg@...nel.org>, Denis Benato <benato.denis96@...il.com>
Subject: Re: [PATCH v10 00/11] HID: asus: Fix ASUS ROG Laptop's Keyboard backlight handling



On 12/9/25 11:49 AM, Antheas Kapenekakis wrote:
> On Tue, 9 Dec 2025 at 10:17, Ilpo Järvinen
> <ilpo.jarvinen@...ux.intel.com> wrote:
>>
>> On Sat, 6 Dec 2025, Antheas Kapenekakis wrote:
>>
>>> On Sat, 6 Dec 2025 at 00:03, Antheas Kapenekakis <lkml@...heas.dev> wrote:
>>>>
>>>> On Fri, 5 Dec 2025 at 23:13, Kelsios <K3lsios@...ton.me> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> I would like to report a regression affecting keyboard backlight brightness control on my ASUS ROG Zephyrus G16 (model GU605CW).
>>>>>
>>>>> Using kernel 6.17.9-arch1-1.1-g14 with the latest HID ASUS patchset v10, keyboard *color* control works correctly, but *brightness* control no longer responds at all. The issue is reproducible on every boot. This problem is not present when using patchset v8, where both color and brightness work as expected.
>>>>>
>>>>> Important detail: the issue occurs even **without** asusctl installed, so it must be within the kernel HID/WMI handling and is unrelated to userspace tools.
>>>>>
>>>>> Output of dmesg is available here [1], please let me know if any additional information is required.
>>>>>
>>>>> Thank you for your time and work on supporting these ASUS laptops.
>>>>>
>>>>> Best regards,
>>>>> Kelsios
>>>>>
>>>>> [1] https://pastebin.com/ZFC13Scf
>>>>
>>>> [ 1.035986] asus 0003:0B05:19B6.0001: Asus failed to receive handshake ack: -32
>>>>
>>>> Oh yeah, asus_kbd_init no longer works with spurious inits so it broke
>>>> devices marked with QUIRK_ROG_NKEY_LEGACY
>>>>
>>>> There are three ways to approach this. One is to ignore the error...
>>>> second is to drop the quirk... third is to check for the usages for ID1, ID2...
>>>>
>>>> I would tend towards dropping the ID2 init and ignoring the error for
>>>> ID1... Unless an EPIPE would cause the device to close
>>>
>>> Benjamin correctly caught the deviation
>>
>> BTW, we want to record this knowledge also into the changelog so that the
>> next person who'd want to make the check stricter does not need to guess
>> whether it was based on a real observed problem or mere guessing there
>> could be a problem.
> 
> If we keep the spurious inits, the stricter check will catch them and
> throw errors. This is problematic.
> 
> Kelsios, you have a device that allegedly would not work without those
> inits. Perhaps you could try removing the legacy quirk from your
> device and see if everything is ok?
> 
> If it is, then we have a tested device and a case for removing the
> legacy quirk altogether
> 
> Antheas
> 
>> --
>>  i.
>>
>>
> 
Hello, 

I was able to narrow it down while testing linux-next with the v10 HID ASUS patchset.

Just like you mentioned in the previous email, on this machine the ID2 initialization returns a negative value. Though, when I comment out the two lines that return early after the FEATURE_KBD_LED_REPORT_ID2 init call, brightness control starts working normally again, even after sending the LED reports.

Patchset v8 did not show this behavior.

Best regards,
Kelsios

Powered by blists - more mailing lists