Hi all,

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

Changelog:
- v1
  - Initial submission
- v2
  - asus-armoury: drivers should be silent on success
  - asus-armoury: make better use of __free annotation
- v3
  - asus-wmi: use GENMASK for flags
  - asus-armoury: fix error handling in keyboard attribute creation
  - asus-armoury: fix logic bug in error path
  - asus-armoury: use proper defines for keyboard state flags
- v4
  - asus-armoury: reorder variable declarations
  - asus-armoury: add bitfields.h include for BIT and FIELD_PREP
  - asus-armoury: reorganize armoury_kbd_state() for clarity

Denis Benato (3):
  platform/x86: asus-wmi: explicitly mark more code with
    CONFIG_ASUS_WMI_DEPRECATED_ATTRS
  platform/x86: asus-wmi: fix sending OOBE at probe
  platform/x86: asus-armoury: add keyboard control firmware attributes

 drivers/platform/x86/asus-armoury.c        | 253 +++++++++++++++++++++
 drivers/platform/x86/asus-wmi.c            |  13 +-
 include/linux/platform_data/x86/asus-wmi.h |  18 ++
 3 files changed, 283 insertions(+), 1 deletion(-)

-- 
2.52.0

On 1/3/26 00:43, Denis Benato wrote:
> Hi all,
>
> 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
Hi Ilpo, please disregard everything in this patch series except the OOBE fix:
that fix is important and I see it has been picked up.

It's probably much better not to touch keyboard modes without a rework
of the associated RGB interface: it doesn't make sense to move only the
power state and I already saw there have been reported problems
with TUFs.

The original problem I was trying to solve is better solved another way
via userspace saving the last setting with the interface already provided.

Thanks,
Denis
> Regards,
> Denis
>
> Changelog:
> - v1
>   - Initial submission
> - v2
>   - asus-armoury: drivers should be silent on success
>   - asus-armoury: make better use of __free annotation
> - v3
>   - asus-wmi: use GENMASK for flags
>   - asus-armoury: fix error handling in keyboard attribute creation
>   - asus-armoury: fix logic bug in error path
>   - asus-armoury: use proper defines for keyboard state flags
> - v4
>   - asus-armoury: reorder variable declarations
>   - asus-armoury: add bitfields.h include for BIT and FIELD_PREP
>   - asus-armoury: reorganize armoury_kbd_state() for clarity
>
> Denis Benato (3):
>   platform/x86: asus-wmi: explicitly mark more code with
>     CONFIG_ASUS_WMI_DEPRECATED_ATTRS
>   platform/x86: asus-wmi: fix sending OOBE at probe
>   platform/x86: asus-armoury: add keyboard control firmware attributes
>
>  drivers/platform/x86/asus-armoury.c        | 253 +++++++++++++++++++++
>  drivers/platform/x86/asus-wmi.c            |  13 +-
>  include/linux/platform_data/x86/asus-wmi.h |  18 ++
>  3 files changed, 283 insertions(+), 1 deletion(-)
>

On Mon, 26 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
> Hi Ilpo, please disregard everything in this patch series except the OOBE fix:
> that fix is important and I see it has been picked up.
> 
> It's probably much better not to touch keyboard modes without a rework
> of the associated RGB interface: it doesn't make sense to move only the
> power state and I already saw there have been reported problems
> with TUFs.
> 
> The original problem I was trying to solve is better solved another way
> via userspace saving the last setting with the interface already provided.

Yes, OOBE fix is now in Linus' tree.

The other 2 patches eliminated from the patchwork queue, thanks.

-- 
 i.

On 1/3/26 00:43, Denis Benato wrote:
> Hi all,
>
> 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.

Thanks,
Denis
> Changelog:
> - v1
>   - Initial submission
> - v2
>   - asus-armoury: drivers should be silent on success
>   - asus-armoury: make better use of __free annotation
> - v3
>   - asus-wmi: use GENMASK for flags
>   - asus-armoury: fix error handling in keyboard attribute creation
>   - asus-armoury: fix logic bug in error path
>   - asus-armoury: use proper defines for keyboard state flags
> - v4
>   - asus-armoury: reorder variable declarations
>   - asus-armoury: add bitfields.h include for BIT and FIELD_PREP
>   - asus-armoury: reorganize armoury_kbd_state() for clarity
>
> Denis Benato (3):
>   platform/x86: asus-wmi: explicitly mark more code with
>     CONFIG_ASUS_WMI_DEPRECATED_ATTRS
>   platform/x86: asus-wmi: fix sending OOBE at probe
>   platform/x86: asus-armoury: add keyboard control firmware attributes
>
>  drivers/platform/x86/asus-armoury.c        | 253 +++++++++++++++++++++
>  drivers/platform/x86/asus-wmi.c            |  13 +-
>  include/linux/platform_data/x86/asus-wmi.h |  18 ++
>  3 files changed, 283 insertions(+), 1 deletion(-)
>

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.

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).

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 
time. But unlike some other subsystems, we don't disallow sending patches 
during merge window or any other time.

-- 
 i.

> > Changelog:
> > - v1
> >   - Initial submission
> > - v2
> >   - asus-armoury: drivers should be silent on success
> >   - asus-armoury: make better use of __free annotation
> > - v3
> >   - asus-wmi: use GENMASK for flags
> >   - asus-armoury: fix error handling in keyboard attribute creation
> >   - asus-armoury: fix logic bug in error path
> >   - asus-armoury: use proper defines for keyboard state flags
> > - v4
> >   - asus-armoury: reorder variable declarations
> >   - asus-armoury: add bitfields.h include for BIT and FIELD_PREP
> >   - asus-armoury: reorganize armoury_kbd_state() for clarity
> >
> > Denis Benato (3):
> >   platform/x86: asus-wmi: explicitly mark more code with
> >     CONFIG_ASUS_WMI_DEPRECATED_ATTRS
> >   platform/x86: asus-wmi: fix sending OOBE at probe
> >   platform/x86: asus-armoury: add keyboard control firmware attributes
> >
> >  drivers/platform/x86/asus-armoury.c        | 253 +++++++++++++++++++++
> >  drivers/platform/x86/asus-wmi.c            |  13 +-
> >  include/linux/platform_data/x86/asus-wmi.h |  18 ++
> >  3 files changed, 283 insertions(+), 1 deletion(-)

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 
> 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!

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.

> > 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!
> 

-- 
 i.

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!
>>