DRM gains atomic LUMINANCE property for panel brightness

Linux DRM is gaining a first-class way to control panel brightness as part of atomic modesetting. Mario Limonciello of AMD has posted version 10 of a series that adds a per-connector LUMINANCE range property so compositors can set relative panel brightness together with the rest of display state, instead of through the separate backlight class sysfs ABI.

The core change is backend-agnostic. Drivers attach a hardware range and implement connector helpers to apply luminance or cut panel emission. Atomic helpers run those callbacks around pipeline enable and disable, including luminance-only commits. A value set while the connector is off is kept and applied on the next enable; turning the pipeline off does not wipe it. Levels are relative and driver-defined, not absolute candelas per square metre, and the design covers both emissive panels and those with a separate backlight.

The new path sits behind a default-off DRM_LUMINANCE Kconfig option. When that option is off, migrated drivers keep registering the legacy backlight class device. When it is on, they stop selecting that ABI so the new UAPI and compatibility policy can land on separate tracks. Earlier revisions still exposed a legacy sysfs brightness path; that is gone in v10. The series is the new API only, not the full userspace cutover.

Driver coverage in this round includes amdgpu, i915 and Xe, Nouveau, Radeon, GMA500, and GUD, plus bridge and panel helpers so chains that own brightness can advertise a range and receive atomic updates. Limonciello reports testing on amdgpu with modetest. Matching compositor work already exists in Kwin, Mutter, and wlroots, though those trees still need updates for v10’s dropped capability bits.

The practical upshot is that brightness becomes ordinary connector state: batched with modesets, retained across power cycles of the pipeline, and controllable by the same KMS clients that already drive the rest of the display.