Skip to content

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

Open
scardracs wants to merge 1426 commits into
OpenGamingCollective:masterfrom
scardracs:leds/dynamic-lighting
Open

scardracs wants to merge 1426 commits into
OpenGamingCollective:masterfrom
scardracs:leds/dynamic-lighting

Conversation

@scardracs

@scardracs scardracs commented Sep 4, 2026 •

Copy link
Copy Markdown

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

  1. 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.
  2. 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.
  3. 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.
  4. 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
scardracs force-pushed the leds/dynamic-lighting branch 4 times, most recently from 005fb1f to c6ee973 Compare September 5, 2026 12:09
Comment thread drivers/leds/led-class-dynamic.c Outdated
@scardracs
scardracs force-pushed the leds/dynamic-lighting branch from c6ee973 to 2ce82cc Compare September 5, 2026 14:23
@scardracs

Copy link
Copy Markdown
Author

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

Comment thread Documentation/ABI/testing/sysfs-class-leds-dynamic Outdated
@scardracs
scardracs force-pushed the leds/dynamic-lighting branch 2 times, most recently from 45f6a76 to 1a38a2e Compare September 8, 2026 14:19
@scardracs scardracs changed the title Leds/dynamic lighting leds: dynamic: Add Dynamic Lighting class interface and Aura (hid-asus) support Sep 8, 2026
@scardracs
scardracs force-pushed the leds/dynamic-lighting branch from 1a38a2e to 4e550e9 Compare September 8, 2026 18:30
@scardracs

Copy link
Copy Markdown
Author

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

@scardracs
scardracs force-pushed the leds/dynamic-lighting branch 4 times, most recently from 3a706b9 to a4d18f6 Compare September 9, 2026 07:42
Grippy98 pushed a commit to Grippy98/linux-unstable that referenced this pull request Sep 10, 2026
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>
@scardracs
scardracs force-pushed the leds/dynamic-lighting branch 4 times, most recently from fb74985 to 907aeed Compare September 13, 2026 10:23
@scardracs
scardracs force-pushed the leds/dynamic-lighting branch 4 times, most recently from 7d4bd15 to 3b75011 Compare September 18, 2026 14:12
@scardracs
scardracs marked this pull request as ready for review September 18, 2026 14:13
@scardracs
scardracs force-pushed the leds/dynamic-lighting branch from 3b75011 to 5a77b23 Compare September 18, 2026 14:21

@pastaq pastaq left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread Documentation/ABI/testing/sysfs-class-leds-dynamic Outdated
Comment thread Documentation/ABI/testing/sysfs-class-leds-dynamic Outdated
Comment thread Documentation/leds/leds-class-dynamic.rst Outdated
Comment thread Documentation/leds/leds-class-dynamic.rst Outdated
Comment thread drivers/hid/hid-ids.h
broonie and others added 17 commits September 29, 2026 15:15
…he.git

# Conflicts:
#	drivers/gpu/drm/amd/amdkfd/kfd_migrate.c
#	net/ceph/osd_client.c
Signed-off-by: Mark Brown <broonie@kernel.org>
--
2.47.3

(cherry picked from commit 536526d)
(cherry picked from commit 0ebc551)
(cherry picked from commit 2e5980a)
--
2.47.3
--
2.47.3
(cherry picked from commit 82fa594)
--
2.47.3
(cherry picked from commit d62da27)
(cherry picked from commit 9f79951)
(cherry picked from commit 64a1618)
(cherry picked from commit a2c9baf)
(cherry picked from commit 0424d14)
[Why]
Chrontel CH7218 found in Ugreen DP -> HDMI 2.1 adapter (model 85564)
works perfectly with VRR after testing. VRR and FreeSync compatibility
is explicitly advertised as a feature so it's addition is a formality.

Support FreeSync info packet passthrough and "generic" HDMI VRR.

[How]
Add CH7218's ID to dm_helpers_is_vrr_pcon_allowed()

Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/4773

Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
(cherry picked from commit 7b2436287ed953496ad1c9eb5820f00b75db597f)
(cherry picked from commit a9c7548)
(cherry picked from commit 63b562c)
(cherry picked from commit e20d460)
The detachable keyboard shipped with the ROG Zephyrus Duo GX651AR
(0b05:1ce6) is a ROG N-Key keyboard, but it is not listed in
asus_devices[], so its interfaces are left to hid-generic and its
vendor usages are never mapped by asus_input_mapping().

Add it with QUIRK_USE_KBD_BACKLIGHT | QUIRK_ROG_NKEY_KEYBOARD, matching
the other ROG N-Key keyboards.

Tested-by: Cymirk <cymirk@icloud.com>
Signed-off-by: Ahmed Yaseen <yaseen@ghoul.dev>
(cherry picked from commit 8d70b5f)
(cherry picked from commit 9582bd4)
(cherry picked from commit 29ee8b6)
… interfaces

On the ROG Zephyrus Duo GX651AR (0b05:1ce6) the hotkeys live on report
0x5a on an interface whose descriptor holds nothing but two ASUS vendor
collections. Neither satisfies IS_INPUT_APPLICATION(), so
hidinput_connect() creates no input device, asus_input_mapping() never
runs and every hotkey is dropped by asus_event() as unmapped.

Set HID_QUIRK_HIDINPUT_FORCE on ROG N-Key interfaces that carry an ASUS
vendor input report so those usages get mapped. Interfaces left with no
mapped usage are still discarded by hidinput_has_been_populated().

The vendor check reads report_enum[HID_INPUT_REPORT], so interfaces with
no input reports, such as the RGB control interface, are unaffected.

Tested-by: Cymirk <cymirk@icloud.com>
Signed-off-by: Ahmed Yaseen <yaseen@ghoul.dev>
(cherry picked from commit 69887e3)
(cherry picked from commit 4e70783)
(cherry picked from commit b3ceeae)
…Bluetooth

The GX651AR keyboard enumerates as 0b05:1ce6 over USB but pairs as
0b05:1ce7 in Bluetooth mode, where the keyboard, consumer and both ASUS
vendor collections (reports 0x5a and 0x5d) sit on a single HID device.
Add it with the same quirks as the USB entry.

Bind to HID_GROUP_GENERIC so that hid-multitouch keeps the digitizer.

Tested-by: Cymirk <cymirk@icloud.com>
Signed-off-by: Ahmed Yaseen <yaseen@ghoul.dev>
(cherry picked from commit b0dbc09)
(cherry picked from commit f460429)
(cherry picked from commit af0d892)
…X651AR

Fn+F12 on the GX651AR keyboard emits ASUS vendor code 0x9c, which
asus_input_mapping() does not know about, so asus_event() drops it as
unmapped.

Map it to KEY_F19. F13 to F18 are already used for ASUS toggles that
have no generic keycode.

Tested-by: Cymirk <cymirk@icloud.com>
Signed-off-by: Ahmed Yaseen <yaseen@ghoul.dev>
(cherry picked from commit 337a811)
(cherry picked from commit a980051)
(cherry picked from commit aafe6db)
…=7 and dump serial log head on banner failure

The smoke test greps the captured serial console log for the kernel
banner ("Linux version <KREL> "), but the banner is printed at
KERN_NOTICE while some distro configs default the console to a quieter
level: Arch ships CONFIG_CONSOLE_LOGLEVEL_DEFAULT=4, which suppresses
notice (and info) messages entirely. The result was a confusing failure
mode: the kernel booted to userspace just fine (BOOT_OK marker, printed
by init directly on /dev/ttyS0), yet the banner check failed because
the console log only carried a few high-priority lines.

Pin loglevel=7 on the test kernel command line so every distro kernel
logs verbosely enough for the banner to be captured, and replace the
useless "^Linux version" grep in the failure path (banner lines are
prefixed with a "[    0.000000] " timestamp, so that grep could never
match) with a dump of the first serial console lines.

Verified locally against a kernel built with the exact Arch config
pipeline: the run failed identically to CI before the change and passes
both the bios-pc and uefi-q35 legs after it.

(cherry picked from commit af2b902)
(cherry picked from commit 98d39d0)
@scardracs

Copy link
Copy Markdown
Author

Wait I did not close it!

Add a dedicated Dynamic Lighting LED class for devices that expose
multi-LED effects, palette programming, direct frame 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 binary direct/frame sinks. Lighting off is
enabled=false, not a dedicated off effect.

Registration validates exported capabilities and serializes writes
under led_access and the class-private lock so drivers can coexist
with LED triggers.

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.

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

Also add the new document to the LED documentation index and register
it in MAINTAINERS.

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:global,
aura:keyboard and aura:lightbar with aura_mode (auto/unified/split).
auto resolves to split so keyboard and lightbar stay independently
writable.

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.

Drive firmware animations with Aura 0xb3/0xb4/0xb5 and solid/direct
frames with Aura 0xBC. Map boot/awake/sleep/shutdown via power_states
to AURA_CMD_POWER (0xbd). Keep asus::kbd_backlight brightness
behaviour unchanged.

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 animations stay on Aura
0xb3.

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.

Signed-off-by: Marco Scardovi <scardracs@disroot.org>
@scardracs scardracs reopened this Oct 1, 2026
@github-actions
github-actions Bot force-pushed the master branch 2 times, most recently from cf99356 to f3282c8 Compare October 2, 2026 08:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants