DRM series moves panel brightness into atomic KMS control

Linux graphics developers are reviewing an eighth revision of patches that would let compositors drive display brightness through DRM connector properties instead of the long-standing backlight sysfs interface.

Mario Limonciello of AMD posted the series following review at Display Next Hackfest 2026. It introduces a per-connector range property, currently named LUMINANCE, that a driver attaches once a backlight backend is linked. Brightness is then staged in atomic connector state and applied on commit, like other modeset properties. Initial driver support covers amdgpu, i915, and Xe on eDP, with room later for DisplayPort panels controllable over DDC. Matching userspace work is already present in Kwin, Mutter, and wlroots.

When a compositor advertises the new client capability, the kernel disables sysfs writes so legacy tools cannot drift out of sync with the compositor. Under older compositors that lack the capability, sysfs remains usable so brightness can still be changed.

That exclusive-takeover design is the sharpest disagreement. Javier Martinez Canillas questioned the value of bridging DRM and the backlight subsystem if modern desktops simply turn sysfs off. Maxime Ripard suggested either routing sysfs writes through an atomic commit so every path shares one code route, or splitting the series so the new UAPI can land apart from legacy handling. Xaver Hugl warned that synthesizing atomic commits from sysfs could stutter, and argued exclusive compositor control is exactly the point: backlight has been an outlier among display properties that already sit under DRM master.

A second design fight is whether luminance should interact with DPMS. Thomas Zimmermann, Leo Li, and Harry Wentland argued the two must stay independent. Backlight off leaves the CRTC active; DPMS off does not. Userspace should set them separately, with any luminance change during DPMS off held in software and restored on power-up, matching current sysfs behavior.

Naming is also unresolved. Wentland prefers BACKLIGHT or PANEL_BRIGHTNESS, warning that LUMINANCE implies absolute units such as nits and bleeds into color-management terminology the property cannot yet honor. Hugl replied that BACKLIGHT is wrong for OLED panels with no backlight, and that luminance is still the most accurate term even without a unit. Ripard favored simply calling it brightness, and noted the property should not say "panel" because HDMI and DisplayPort targets are expected later.