On Thu, Oct 01, 2026 at 03:12:25PM -0400, Harry Wentland wrote: > On 2026-09-08 00:40, Mario Limonciello wrote: > > Backlight brightness is a property of a display, and thus of a DRM > > connector, yet it has historically only been controllable through the > > separate backlight sysfs interface. Add a generic, backend-agnostic > > per-connector LUMINANCE range property so brightness can be driven > > through the atomic modeset path like any other connector state. > > > > A struct drm_backlight is embedded in every connector and initialized by > > the core; drivers do not allocate it. A driver links a backend (today a > > backlight_device, in the future DDC/CI, MIPI-DCS, ...) with > > drm_backlight_link(), which creates the connector's LUMINANCE property > > I didn't follow the whole discussion so I'm curious why we decided to > name this LUMINANCE. I think of nits or cd/m^2 when I hear luminance. > I think it's dangerous when we use for a property that is currently > not able to describe the output in nits. You would also then have to > define whether you're dealing with a fully white screen, or parts that > are white. In short, you're ending up in color management territory where > these things have specific meanings and it's easy to get it wrong if > we don't define the nuances right. > > Why not simply call it BACKLIGHT, which is what it is? Later, if we then > add support for luminance (in absolute nits) we can use the LUMINANCE > term for that. Otherwise it'll be lost to us and be apt to confuse > people. > > I'm on the fence about calling it "drm brightness", as suggested by Jani, > but could get onboard with something like PANEL_BRIGHTNESS.
I don't think we should mention panel here, it will be useful for at least HDMI and DP too. brightness works for me though Maxime
signature.asc
Description: PGP signature
