lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <e62a1ce6-a74b-4619-b57c-c05c5da8c332@gmail.com>
Date: Fri, 16 Jan 2026 19:10:21 +0100
From: Denis Benato <benato.denis96@...il.com>
To: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
 Denis Benato <denis.benato@...ux.dev>
Cc: LKML <linux-kernel@...r.kernel.org>, platform-driver-x86@...r.kernel.org,
 Hans de Goede <hansg@...nel.org>, "Luke D . Jones" <luke@...nes.dev>,
 Mateusz Schyboll <dragonn@...pl>
Subject: Re: [PATCH v4 0/3] platform/x86: asus-wmi: move keyboard control
 firmware attributes


On 1/14/26 10:04, Ilpo Järvinen wrote:
> On Tue, 13 Jan 2026, Denis Benato wrote:
>
>> On 1/13/26 15:02, Ilpo Järvinen wrote:
>>> On Mon, 12 Jan 2026, Denis Benato wrote:
>>>> On 1/3/26 00:43, Denis Benato wrote:
>>>>> I was recently reading through the asusctl issue tracker and I found
>>>>> out that some users have been having troubles with the keyboard RGB control
>>>>> that was working before since the creation of asus-armoury and subequent
>>>>> deprecation of old sysfs attributes.
>>>>>
>>>>> This patch series aims to re-introduce those attributes in asus-armoury
>>>>> so that userspace tools can still control keyboard RGB lighting
>>>>> without having to rely on deprecated asus-wmi attributes.
>>>>>
>>>>> In addition to that, since disabling OOBE is essential for controlling
>>>>> LEDs on some models and it was incorrectly tied to deprecated attributes,
>>>>> this patch series also fixes sending OOBE at probe time.
>>>>>
>>>>> Link: https://gitlab.com/asus-linux/asusctl/-/issues/619
>>>>>
>>>>> Regards,
>>>>> Denis
>>>> Hi Ilpo,
>>>>
>>>> I see no comments on this revision, did I sent it at wrong time?
>>>> Should I resend some other time?
>>>>
>>>> Sorry for the question but I don't know if something went wrong,
>>>> and if so what exactly.
>>> Hi,
>>>
>>> Nothing is wrong, I've just had to spend time on finally processing 
>>> some larger next series which were even older than yours. And we're only 1 
>>> week past a holiday period which tend to add to delay.
>> Oh okay, thank you for letting me know! I feared I repeated the error
>> I made on the netdev list :)
>>> Patchwork keeps track of pdx86 patches:
>>>
>>> https://patchwork.kernel.org/project/platform-driver-x86/list/
>>>
>>> If your patch is listed there, there's no need to ping as I'll get it it 
>>> eventually (and it won't get forgotten).
>> Understood! Sorry for the inconvenient :D
>>> There's no "wrong time" to send a patch to pdx86, only that when the 
>>> merge window is open, I might do processing of any patches during that 
> In case it wasn't obvious, I meant: I might not do processing of any 
> patches during the merge window.
Sure! Don't worry I was just attempting to avoid ending in a place where
everyone forgot these patches as this feature in particular has been
forgotten already once XD
>>> time. But unlike some other subsystems, we don't disallow sending patches 
>>> during merge window or any other time.
>>>
>> That's very good to know. Thank you very much, always very informative!
>>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ