new randr feature: brightness control

[metux]

Describe the idea

Add randr output properties to retrieve and control output brightness.

• BRIGHTNESS_MIN (CARD32, ro) - minimal brightness value
• BRIGHTNESS_MAX (CARD32, ro) - maximum brightness value
• BRIGHTNESS_CURRENT (CARD32, rw) - current brightness value
• BRIGHTNESS_STEP (CARD32, ro) - brightness stepping interval

If monitors are properly calibrated (not in scope here), then:

• BRIGHTNESS_CURRENT=0 means 100% black (0 nits)
• BRIGHTNESS_MAX > 65535 should not happen
• all monitors should have the same BRIGHTNESS_MAX values (for proposed DRM changes, it's always 65535)
• BRIGHTNESS_CURRENT=BRIGHTNESS_MAX -> 100% possible luminance
• full black and full white should have the same luminance on all outputs

The implementation can happen in each driver individually (they're already taking care of output properties on their own), so no extra support code needed. First driver implementation could be done in modesetting.

Usage advice:

• clients should be aware of these values might always change (even the ro ones, eg. on powercap)
• when there's more than one output, they should consider different steppings (eg. round up to the biggest one of all outputs)
• brightness 0 might make the display completely dark (eg. PWM backlight might be completely off)
• brightness might also be changed by other entities than the Xserver (eg. firmware, hotkeys, ...)

It should be done because

Brightness control historically always been ugly: X11 has no common interface for this. Applications need to resort to different, OS specific (and so local-only) interfaces, which might even need root privileges. And it's complicated to match up xrandr outputs with the OS specific output device objects (eg. drm outputs)

Instead of various competing and heavily OS specific out-out-band mechanisms, X11 should have a OS agnostic standard protocol.

What are the alternatives?

No response

Additional context

Futher reading:
https://lore.kernel.org/dri-devel/[email protected]/

Extra fields

• I have checked the existing New Ideas, RFCs Of The Core Team, Ideas Soon To Be Addressed and Someday Ideas
• I have read the Contributing Guidelines
• I'd like to work on this idea

[metux]

@callmetango @cepelinas9000 @mikedld @josephcrowell @jonhermansen @probonopd @artist4xlibre @algrid @b-aaz
what are your thoughts ?

[cepelinas9000]

I agree, it is part of output at device level. I suggest in one swoop add additional output attributes to be in one place (in not implemented case MIN/MAX -1):

• Contrast
• Backlight - for laptop screens
• Audio speaker volume - audio works when monitor is on...

Although these are controlled by DDC/CI and add extra code (I2C is slow bus) - but benefit will be: main/common screen attributes in one place.

[probonopd]

Let's just make sure that no Linux-isms creep in and that it'll work on e.g., the BSDs, too.

[callmetango]

@metux Can we ensure that?

[algrid]

Looks like a good proposal!

@metux what's the idea behind making those values 32bit, but limiting them by 65535 which is basically 16bit? Is it just some protocol nuance?

[metux]

Looks like a good proposal!

@metux what's the idea behind making those values 32bit, but limiting them by 65535 which is basically 16bit? Is it just some protocol nuance?

I knew this question is coming ;-)

Since it's becoming public protocol, just in case that we might need bigger values in the future.
(don't mind if you guys really want it as CARD16)

The max value is coming from the current Linux DRM proposal. No idea what other OS'es might do here.

[algrid]

Makes sense, I'm totally fine with 32bits there :)

[callmetango]

I really like the idea! Brightness control has always been "delicate", to put it very diplomatically. Backlight - ArchWiki lists many of the different solutions that may or may not work depending on the particular hardware.

@metux Is it technically possible to unify all of this?

[metux]

@metux Is it technically possible to unify all of this?

Well, that's the idea behind.
In contrast to the Backlight property that some drivers already have (which more or less maps directly to the backlight sysfs values - iow: PWM values, in various different steppings), this one shall actually represent the white luminance (relative to the display's physical maximum - which more or less is what the new proposed DRM properties shall do).

The tricky part is bringing them all to the same scale.
If monitors are calibrated well, setting all displays to some value X, then the max-white and min-black shall have the same luminance on all displays.

[callmetango]

Sounds great and adds an incentive to calibrate ones monitors. 👍 by me. I am happy to create a feature request ticket once the details are fleshed out.