Skip to content

Move brightness control to KWin

I think that we should do this for a few reasons:

  1. With future kernel APIs for this, brightness will be set as a property on the connector. So eventually this will be a thing we have to do anyways
  2. Many desktop monitors don't have a brightness setting in HDR mode. Even with monitors that do have it, we could support a per screen brightness setting in software, which is nicer than needing to fiddle with monitor controls
  3. KWin may want to know the currently used brightness value, in order to handle peak brightness of the display better
  4. With some non-HDR screens it would be beneficial to do brightness changes in software too, like for example with OLED screens that are missing "proper" brightness control
  5. With HDR laptops it might be useful for KWin to dynamically adjust the backlight brightness, to save power while HDR isn't actually used. I'm not sure yet about how this works on laptops though, it might be that they'll automatically adjust the backlight brightness like desktop monitors too

The proposed architecture would be that powerdevil sets some brightness setting in 0-100% per screen, and KWin then uses one of the external and/or internal available APIs to make it happen.

This becomes a bit more challenging with HDR though, as we have up to four relevant brightness values:

  • SDR brightness (full screen)
  • HDR brightness (full screen)
  • HDR highlight brightness (small part of the screen only, as a limitation of the display hardware)
  • the screen's brightness setting

To simplify this, I think we should expose SDR brightness as the normal brightness slider, and for a start just automagically extrapolate the HDR (highlight) brightness to be used - and we can add a calibration page in KScreen to give users more control over it if needed. The screen's actual brightness setting should imo just be an implementation detail in all cases, one that KWin will most likely just slam to 100%, at least with normal HDR monitors.

Edit: How this plan now actually worked out is

  • powerdevil uses the output management protocol to set an opaque 0-100% brightness setting per screen that KWin advertises brightness controls for
  • powerdevil exposes the real underlying brightness devices (of internal panels with sysfs and external monitors with ddc/ci) for exclusively KWin to control
  • for SDR mode, KWin sets the underlying brightness device of a given output to the appropriate value - which might be the opaque settings value, or something else (auto brightness, backlight control for HDR, whatever we come up with)
  • for HDR mode, KWin sets the underlying brightness device to 100% (just in case it actually does something) and controls the actual brightness level in compositing
  • for SDR mode when no brightness device is available, KWin also controls the actual brightness level in compositing. This is needed for some OLED displays
Edited by Xaver Hugl