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: <fc8a3843-0f04-ecd7-b30f-d53dbf3fc7e2@linux.intel.com>
Date: Mon, 26 Jan 2026 14:56:01 +0200 (EET)
From: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>
To: 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>, Denis Benato <benato.denis96@...il.com>
Subject: Re: [PATCH v4 0/3] platform/x86: asus-wmi: move keyboard control
 firmware attributes

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.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ