leds: dynamic: Add Dynamic Lighting class interface and Aura (hid-asus) support by scardracs · Pull Request #17 · OpenGamingCollective/linux-unstable

scardracs · 2026-09-04T19:39:14Z

Summary

This pull request introduces the Dynamic Lighting LED class to the kernel and adds driver support in hid-asus for ASUS ROG Aura keyboards and chassis lightbars.
It provides a standard sysfs ABI for devices that expose multi-zone effects, palette programming, direct RGB frame streaming, and lighting power-state persistence, without requiring individual drivers to invent ad-hoc sysfs layouts.

NOTE: due to heavy work on both here and linux the text on that OP can or cannot be accurate

Commits Overview

leds: Add LED_DYNAMIC_LIGHTING flag to LED core
- Defines LED_DYNAMIC_LIGHTING in struct led_classdev to enable runtime identification of Dynamic Lighting class devices, following the pattern of LED_MULTI_COLOR.
leds: dynamic: Add Dynamic Lighting core class interface
- Implements the new class (drivers/leds/led-class-dynamic.c, include/linux/led-dynamic-lighting.h) extending led_classdev.
- Exposes common effect, speed, direction, and power-state controls, plus binary direct-buffer and frame write interfaces.
- Serializes writes using led_access and the class mutex to ensure thread safety alongside LED triggers.
docs: leds: Document the Dynamic Lighting class ABI
- Documents the user-facing sysfs interface in Documentation/ABI/testing/sysfs-class-leds-dynamic and Documentation/leds/leds-class-dynamic.rst.
- Updates Documentation/leds/index.rst and registers the subsystem files in MAINTAINERS.
HID: asus: Add Dynamic Lighting support for Aura devices
- Integrates Dynamic Lighting support into hid-asus.
- Discovers keyboard layout and chassis lightbar zones via the Aura probe report.
- Implements zone power unmasking (0xbd), zone activation (0xc0), and hardware effect engine programming (0xb3) with the firmware latch commit sequence (0xb5 SET -> 0xb4 COMMIT -> 0xb5 SET).
- Supports direct per-key/lightbar packed RGB frame writes through the class direct-buffer streaming interface.
- Fully preserves backward compatibility with the existing asus::kbd_backlight brightness control.

Summary by CodeRabbit

New Features
- Added Dynamic Lighting controls for supported devices, including RGB streaming, hardware effects, color palettes, animation speed and direction, power-state persistence, and matrix or zone information.
- Added ASUS Aura lighting support for keyboard, lightbar, and global zones, with selectable automatic, unified, and split modes.
- Added lighting controls for supported ASUS ROG Slash devices.
Documentation
- Added guides and reference information covering Dynamic Lighting controls, supported values, and usage constraints.

scardracs · 2026-09-05T20:40:50Z

I've moved the patch to 7.2 in order to have some stability (7.3 is way too bugged as for now). When the situation will be better I'll move it back to 7.3. I leave that draft open for now

scardracs · 2026-09-08T18:31:31Z

Added an aura:global that controls both keyboard and lightbar for those devices that don't have the ability to control them separately

cifs.idmap key descriptions carry authority-bearing fields (owner and group SIDs and uid/gid values in "os:"/"gs:"/"oi:"/"gi:" form) that the cifs.idmap upcall helper treats as kernel-originating inputs. Unlike its sibling cifs.spnego, the cifs.idmap key type has no vet_description hook, so userspace can create keys of this type through request_key(2)/add_key(2) and supply those fields without CIFS origin. A request_key(2) call with a non-NULL callout then drives a root usermodehelper upcall (/sbin/request-key -> cifs.idmap) that consumes the unvetted description in root context. Only accept cifs.idmap descriptions while CIFS is using its private root_cred to request the key. id_to_sid()/sid_to_id() already run under override_creds(root_cred), so the kernel-originated path is unaffected. This mirrors commit 3da1fdf ("smb: client: reject userspace cifs.spnego descriptions"), which applied the same restriction to cifs.spnego. Fixes: 4d79dba ("cifs: Add idmap key and related data structures and functions (try OpenGamingCollective#17 repost)") Reported-by: TencentOS Corvus AI <corvus@tencent.com> Cc: stable@vger.kernel.org Assisted-by: CodeBuddy:Kimi-K3 Signed-off-by: Aohan Mei <henrymei@tencent.com> Acked-by: David Howells <dhowells@redhat.com> Signed-off-by: Paulo Alcantara <pc@manguebit.org>

pastaq

I'm concerned that this implementation is too restrictive. I was under the impression that the classdev would outline the shape of the ABI, and a generic implementation would also exist that would implement them. Currently I don't see how I can transition the existing hid-[lenovo-go*|oxp|msi] drivers to this which need more dynamic ability to describe built in effects. Ideally this could be a drop in replacement where I just need to define the index/range for each and assign function pointers like I do with brightness/multi_intensity.

init_mount_tree() mounts the mutable rootfs on top of nullfs via LOCK_MOUNT_EXACT(). That declares a pinned mountpoint with a cleanup attribute in the scope of the whole function so the nullfs root inode lock and namespace_sem are only dropped when init_mount_tree() returns. This became a problem when the private nullfs instance for kthreads was added. kern_mount() allocates a new superblock and alloc_super() takes the new s_umount with SINGLE_DEPTH_NESTING and then shrinker_mutex via shrinker_alloc(). Doing that with namespace_sem held teaches lockdep the dependency namespace_sem -> s_umount/1 -> shrinker_mutex With CONFIG_SHRINKER_DEBUG shrinker_debugfs_rename() takes the debugfs directory inode lock under shrinker_mutex every time a block device is mounted and lock_mount_exact() takes namespace_sem under the inode lock of the mountpoint for every mount. So mounting anything on debugfs, e.g. the tracefs automount on /sys/kernel/debug/tracing, closes the cycle: WARNING: possible circular locking dependency detected 7.3.0-rc3+ #17 Not tainted ------------------------------------------------------ rasdaemon/4449 is trying to acquire lock: (namespace_sem){++++}-{4:4}, at: lock_mount_exact+0x4c/0x308 but task is already holding lock: (&sb->s_type->i_mutex_key#17){++++}-{4:4}, at: lock_mount_exact+0x3c/0x308 which lock already depends on the new lock. ... Chain exists of: namespace_sem --> shrinker_mutex --> &sb->s_type->i_mutex_key#17 This can't actually deadlock. init_mount_tree() runs single-threaded during early boot before any other task exists and nothing allocates a superblock under namespace_sem after that. But lockdep can't know that and disables itself for the rest of the boot. Move mounting the rootfs on top of nullfs into a helper so the locks are dropped when it returns. Fixes: 32750c7 ("fs: start all kthreads in nullfs") Reported-by: Zenghui Yu <yuzenghui@huawei.com> Closes: https://lore.kernel.org/15174353-3f4a-a1ca-5bd1-ea2a4c77828e@huawei.com Link: https://patch.msgid.link/20260917-atemtechnik-bleichen-befassen-9a57db01baf0@brauner Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>

scardracs · 2026-10-01T05:57:03Z

Wait I did not close it!

pastaq · 2026-10-04T06:36:00Z

@scardracs can you rebase on the latest master? unstable moves quickly.

@NeroReflex we should figure out a system to make this less of a pain.

NeroReflex · 2026-10-04T12:12:40Z

@scardracs can you rebase on the latest master? unstable moves quickly.

@NeroReflex we should figure out a system to make this less of a pain.

In theory in the action there is nothing referencing master so if users enable actions theirs branch rebases the same way ours did, no?

scardracs · 2026-10-05T05:25:52Z

@scardracs can you rebase on the latest master? unstable moves quickly.

@NeroReflex we should figure out a system to make this less of a pain.

In theory in the action there is nothing referencing master so if users enable actions theirs branch rebases the same way ours did, no?

I had it disabled because it was always failing. Now that you have it fixed i could enable it again

pastaq

I only reviewed the first patch. Looks good enough for an RFC. For ASUS stuff I defer to Nero. I'd like to see what the led subsystem maintainers think before I add an R/b tag.

Please Cc kernel@lists.opengamingcollective.org and derekjohn.clark@gmail.com when submitting.

Thanks!

Add a dedicated Dynamic Lighting LED class for devices that expose multi-LED effects, palette programming, direct RGB streaming or lighting state persistence through sysfs. Define LED_DYNAMIC_LIGHTING on struct led_classdev and an optional led_dynamic back-pointer so the class can wrap a new LED or attach to an already registered one without replacing brightness or multi_intensity. Drivers supply their own effect name table and optional ops. Sysfs exposes only implemented attributes: effect and effect_index, optional enabled and enabled_index, speed and speed_range, direction, palette, power states, and a binary direct_buffer sink. Lighting off is enabled=false, not a dedicated off effect. Directions are left, right, up and down. The driver owns the initial enabled state and may point palette at its own storage so the initial palette is in place before sysfs appears. Registration validates exported capabilities and serializes writes under led_access and the class-private lock so drivers can coexist with LED triggers. A KUnit test covers palette parsing, unknown-effect rejection and attribute visibility without hardware; it drives the show/store callbacks through kernfs so it runs under kunit.py without a mounted sysfs. This provides a common kernel ABI for complex lighting devices without requiring each driver to invent its own sysfs layout or rewrite an existing LED registration. The LED back-pointer is a forward-declared type. The direct-buffer staging area is allocated before the LED locks. The effect-bit helper stops at bit 31, where a u32 mask ends. Signed-off-by: Marco Scardovi <scardracs@disroot.org>

Document the Dynamic Lighting LED class ABI and user-facing sysfs interface. Describe the common attributes, visibility rules for optional controls, and how a vendor driver can attach the class to an existing LED. Effect names are defined by the driver and discovered through effect_index. enabled/enabled_index turn lighting off without changing the selected effect. Writing power_states replaces the active bitmask (an empty list clears all enabled states). Direction values are left, right, up and down. Also add the new document to the LED documentation index and register it in MAINTAINERS. brightness stays intensity. effects_palette is the multi-color stack. brightness 0 is not lighting-off, because removing a trigger sets LED_OFF. Signed-off-by: Marco Scardovi <scardracs@disroot.org>

USB ID 0x193b is shared by standalone Slash MCUs and AniMe Matrix panels. Bind it only when the interface exposes Aura/Slash LED reports (0x5d/0x5e) or a sibling HID LampArray lighting interface. Detect LampArray by report IDs on usage page 0x59 and start that interface without hidraw so lighting is not exported to userspace. Firmware animations stay on the Aura 0x5d interface; Aura 0xBC remains the fallback when LampArray is absent. Signed-off-by: Marco Scardovi <scardracs@disroot.org>

Add Dynamic Lighting class support to hid-asus for Aura-capable ROG keyboards and chassis lightbars. Discover Aura layout, lightbar, and per-key/direct RGB from HID feature reports rather than DMI board lists. Register aura:keyboard and, when the chassis lightbar is present, aura:lightbar. Each node keeps its own effect and palette. The driver owns the palette storage and fills it before the node is registered. Publish the firmware effect list from the 0x9e capability mask (static, breathe, rainbow_cycle, rainbow_wave, star, rain, highlight, laser, ripple, pulse, comet, flash) and advertise direct when the keyboard path supports packed RGB. Lighting off uses enabled rather than a dedicated off effect. Commit firmware effects, including static color, with Aura 0xb3/0xb5/0xb4 so the controller keeps them across reboot. The committed color is the palette itself: brightness uses the firmware backlight command and enabled gates the zone with 0xbd, so neither rewrites the saved color. Direct frames use Aura 0xBC. Before the keyboard handshake, read the feature report: adopt a programmed effect, apply static red only when the report is blank, and leave the controller alone when the payload cannot be decoded. Resume reapplies only an effect this driver has adopted or written. Map boot/awake/sleep/shutdown via power_states to AURA_CMD_POWER (0xbd). Remember the HID write path that the device accepts. Brightness is the firmware backlight and does not gate the zone. enabled owns 0xbd, and the logo tracks the keyboard power states. Speed, direction and palette follow set_effect and do not commit while lighting is off. The HID write path is cached per report id and is kept across timeouts. Power state for the two nodes is stored in the driver so the zones do not read each other's LED lock. Signed-off-by: Marco Scardovi <scardracs@disroot.org>

On N-KEY devices where Aura 0xBC cannot drive the chassis lightbar independently, use the sibling HID LampArray interface as the in-kernel direct-RGB backend and drop the owner reference on unbind. Linux Dynamic Lighting sysfs remains the userspace ABI. Fall back to Aura 0xBC when LampArray is absent. Firmware effects, including static color, stay on Aura 0xb3; release LampArray before committing one. A direct frame updates only the lamps of that zone, so the other zone is not repainted from an empty buffer. The LampArray device reference is dropped outside aura_lock. Signed-off-by: Marco Scardovi <scardracs@disroot.org>

Register Slash when feature report 0x5e is present, or on USB 0x193b when Aura LED report 0x5d exists. Identify Slash from HID reports, never from DMI board lists. Expose asus::slash with mode, interval and brightness controls using the Aura feature-report path already used for keyboard lighting. Probe only runs the Slash handshake and does not overwrite a mode saved in the controller. Signed-off-by: Marco Scardovi <scardracs@disroot.org>

scardracs force-pushed the leds/dynamic-lighting branch 4 times, most recently from 005fb1f to c6ee973 Compare September 5, 2026 12:09

NeroReflex reviewed Sep 5, 2026

View reviewed changes

Comment thread drivers/leds/led-class-dynamic.c Outdated

scardracs force-pushed the leds/dynamic-lighting branch from c6ee973 to 2ce82cc Compare September 5, 2026 14:23

pastaq reviewed Sep 7, 2026

View reviewed changes

Comment thread Documentation/ABI/testing/sysfs-class-leds-dynamic Outdated

scardracs force-pushed the leds/dynamic-lighting branch 2 times, most recently from 45f6a76 to 1a38a2e Compare September 8, 2026 14:19

scardracs changed the title ~~Leds/dynamic lighting~~ leds: dynamic: Add Dynamic Lighting class interface and Aura (hid-asus) support Sep 8, 2026

scardracs force-pushed the leds/dynamic-lighting branch from 1a38a2e to 4e550e9 Compare September 8, 2026 18:30

scardracs mentioned this pull request Sep 8, 2026

feat(aura): support Dynamic Lighting sysfs interface with hidraw fallback OpenGamingCollective/asusctl#369

Draft

7 tasks done

scardracs force-pushed the leds/dynamic-lighting branch 4 times, most recently from 3a706b9 to a4d18f6 Compare September 9, 2026 07:42

scardracs force-pushed the leds/dynamic-lighting branch 4 times, most recently from fb74985 to 907aeed Compare September 13, 2026 10:23

scardracs force-pushed the leds/dynamic-lighting branch 4 times, most recently from 7d4bd15 to 3b75011 Compare September 18, 2026 14:12

scardracs marked this pull request as ready for review September 18, 2026 14:13

scardracs force-pushed the leds/dynamic-lighting branch from 3b75011 to 5a77b23 Compare September 18, 2026 14:21

pastaq reviewed Sep 18, 2026

View reviewed changes

scardracs force-pushed the leds/dynamic-lighting branch 2 times, most recently from f0df561 to 4404570 Compare September 28, 2026 06:29

github-actions Bot force-pushed the master branch 2 times, most recently from 98d39d0 to adfb8ee Compare September 30, 2026 08:12

scardracs closed this Oct 1, 2026

scardracs force-pushed the leds/dynamic-lighting branch from 4404570 to adfb8ee Compare October 1, 2026 05:55

scardracs reopened this Oct 1, 2026

github-actions Bot force-pushed the master branch 3 times, most recently from f3282c8 to a9cf7c7 Compare October 3, 2026 07:48

scardracs closed this Oct 5, 2026

scardracs force-pushed the leds/dynamic-lighting branch from 74f3580 to a9fca3a Compare October 5, 2026 08:19

scardracs reopened this Oct 5, 2026

scardracs force-pushed the leds/dynamic-lighting branch 2 times, most recently from 0533257 to dfe29bf Compare October 9, 2026 09:10

NeroReflex force-pushed the master branch from 6dadeae to 09ceee6 Compare October 9, 2026 12:48

pastaq approved these changes Oct 10, 2026

View reviewed changes

scardracs force-pushed the leds/dynamic-lighting branch from dfe29bf to 3e0a559 Compare October 10, 2026 07:57

scardracs added 6 commits October 10, 2026 09:59

scardracs force-pushed the leds/dynamic-lighting branch from 3e0a559 to 8242ad5 Compare October 10, 2026 07:59

Navigation Menu

Repository navigation

leds: dynamic: Add Dynamic Lighting class interface and Aura (hid-asus) support - #17

leds: dynamic: Add Dynamic Lighting class interface and Aura (hid-asus) support#17
scardracs wants to merge 6 commits into
OpenGamingCollective:masterfrom
scardracs:leds/dynamic-lighting

scardracs commented Sep 4, 2026 •

edited by coderabbitai Bot

Loading

Uh oh!

Uh oh!

scardracs commented Sep 5, 2026

Uh oh!

Uh oh!

scardracs commented Sep 8, 2026

Uh oh!

pastaq left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

scardracs commented Oct 1, 2026

Uh oh!

pastaq commented Oct 4, 2026

Uh oh!

NeroReflex commented Oct 4, 2026

Uh oh!

scardracs commented Oct 5, 2026

Uh oh!

pastaq left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

scardracs commented Sep 4, 2026 • edited by coderabbitai Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Commits Overview

Summary by CodeRabbit

Uh oh!

Uh oh!

scardracs commented Sep 5, 2026

Uh oh!

Uh oh!

scardracs commented Sep 8, 2026

Uh oh!

pastaq left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

scardracs commented Oct 1, 2026

Uh oh!

pastaq commented Oct 4, 2026

Uh oh!

NeroReflex commented Oct 4, 2026

Uh oh!

scardracs commented Oct 5, 2026

Uh oh!

pastaq left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

scardracs commented Sep 4, 2026 •

edited by coderabbitai Bot

Loading