[PATCH RFC 0/2] Keyboard lighting for the Lenovo Legion Pro 7 Gen 10

[Ciro Pedrini via B4 Relay]

The keyboard and chassis lighting of the Lenovo Legion Pro 7 16IAX10H
(2025) has no Linux support today: on my unit nothing ever lit, because
the keyboard controller's brightness was 0 from the factory and nothing on
Linux exposes it. This series makes it a regular keyboard backlight.

The lighting is two USB HID devices:

- 048d:c197, the ITE 8258 keyboard controller: the built-in keyboard,
  plus a vendor protocol on feature report 0x07 (960 bytes) with a
  hardware brightness (0..9, stored), the controller's own effects
  (stored profiles), and a switch that hands the LEDs to the LampArray
  below (also stored). Fn+Up/Down/Space are handled by the controller,
  which reports the result on a vendor input report.

- 048d:c193 interface 1, a standard HID LampArray: 319 lamps (keys, front
  strip, rear vents, lid logo) with positions and key usages. It shows
  nothing until the controller hands the LEDs over, its colours are scaled
  by the controller's brightness, and after resume from S3 the kernel
  resets it and it comes back in autonomous mode.

Patch 1 makes ideapad-laptop ignore the EC's copies of those three
hotkeys, which reach userspace as KEY_UNKNOWN today.

Patch 2 adds hid-lenovo-legion, binding both devices: one multicolor LED
(<name>:rgb:kbd_backlight) whose brightness is the controller's, with
brightness_hw_changed from the hotkeys, and whose colour goes to every
lamp. lighting_mode selects "firmware" (default: the controller's effects;
the driver leaves the LEDs alone, so a userspace tool can drive the
LampArray over hidraw) or "color". Per-key control stays in userspace.

This is an RFC because of its shape: one driver spanning two USB devices,
paired by their USB bus. Is that acceptable, or would you rather have it
differently, e.g. a vendor hook in the generic LampArray helper that Aaron
and Werner are working on ("HID: generic: add LampArray support", v7),
which on this machine would register a kbd_backlight that does nothing
visible? The two patches touch two subsystems; I'm happy to split them.

Tested on the 16IAX10H (83F5, BIOS Q7CN77WW, Spanish ISO keyboard) with
7.2, as modules: brightness from sysfs and KDE, the hotkeys' OSD, colours
on every zone, suspend/resume in both modes, a userspace LampArray client
in "firmware" mode, unbinding back to hid-generic. The series is based on
v7.4-rc2 and builds there with W=1.

I worked out the protocol from the device itself (usbmon captures, the
LampArray's attributes) and from analysing the vendor's Windows software
for interoperability. The patches were prepared with Claude Code (Claude
Opus 5.5), see the Assisted-by tags; I reviewed and tested them.
checkpatch reports those tags (non-standard signature, no email address),
and a MAINTAINERS hint for the new files that patch 2 already adds.

To: Mark Pearson <mpearson-lenovo@xxxxxxxxx>
To: Derek J. Clark <derekjohn.clark@xxxxxxxxx>
To: Rong Zhang <i@xxxxxxxx>
To: Ike Panhc <ikepanhc@xxxxxxxxx>
To: Hans de Goede <hansg@xxxxxxxxxx>
To: Ilpo Järvinen <ilpo.jarvinen@xxxxxxxxxxxxxxx>
To: Jiri Kosina <jikos@xxxxxxxxxx>
To: Benjamin Tissoires <bentiss@xxxxxxxxxx>
Cc: platform-driver-x86@xxxxxxxxxxxxxxx
Cc: linux-kernel@xxxxxxxxxxxxxxx
Cc: linux-input@xxxxxxxxxxxxxxx

---
Ciro Pedrini (2):
      platform/x86: ideapad-laptop: Ignore keyboard backlight hotkeys
      HID: lenovo-legion: Add keyboard lighting driver for Legion Gen 10

 .../testing/sysfs-class-led-driver-lenovo-legion   |  20 +
 MAINTAINERS                                        |   2 +
 drivers/hid/Kconfig                                |  13 +
 drivers/hid/Makefile                               |   1 +
 drivers/hid/hid-ids.h                              |   2 +
 drivers/hid/hid-lenovo-legion.c                    | 662 +++++++++++++++++++++
 drivers/platform/x86/lenovo/ideapad-laptop.c       |   4 +
 7 files changed, 704 insertions(+)
---
base-commit: 7475ea8b58616b33c04afb976cf0fbaad9dd63fb
change-id: 20261109-legion-lighting-rfc-dc32165df52d

Best regards,
-- 
Ciro Pedrini <ciro.pedrini@xxxxxxxxx>