New userspace api for display panel brightness-control

The current userspace API for brightness control offered by /sys/class/backlight devices has various problems:

1. There is no way to map the backlight device to a specific display-output / panel

2. On x86 there can be multiple firmware + direct-hw-access methods for controlling the backlight and the kernel may register multiple backlight-devices based on this which are all controlling the brightness for the same display-panel. To make things worse sometimes only one of the registered
backlight devices actually works.

3. Controlling the brightness requires root-rights requiring desktop-environments to use suid-root helpers for this.

4. The scale of the brightness value is unclear, the API does not define if “perceived brightness” or electrical power is being controlled and in practice both are used without userspace knowing which is which.

5. The API does not define if a brightness value of 0 means off, or lowest brightness at which the screen is still readable (in a low lit room), again in practice both variants happen.

This talk will present a proposal for a new userspace API which intends to address these problems in the form of a number of new properties for drm/kms properties on the drm_connector object for the display-panel.

This talk will also focus on how to implement this proposal which brings several challenges with it:

1. The mess of having multiple interfaces to control a laptop’s internal-panel will have to be sorted out because with the new API we can no longer just register multiple backlight devices and let userspace sort things out.

2. In various cases the drm/kms driver driving the panel does not control the brightness itself, but the brightness is controlled through some (ACPI) firmware interface such as the acpi_video or nvidia-wmi-ec-backlight interfaces.

This introduces some challenging probe-ordering issues, the solution for which is not entirely clear yet, so this part of the talk will be actively seeking audience input on this topic.

Hans de Goede, Red Hat

Transcript

1. Hans de Goede This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License New brightness uAPI Principal Engineer, Red Hat Replacing /sys/class/backlight
2. Problems with /sys/class/backlight New uAPI proposal Backlight handling technical debt Probe ordering issues Topics
3. Problems with /sys/class/backlight
4. First gave a talk about this at XDC 2014 https://wiki.freedesktop.org/xorg/Events/XDC2014/ XDC2014GoedeBacklight/ Intel send a proposal to try and fix this in 2017: https://lore.kernel.org/all/4b17ba08-39f3-57dd-5aad- d37d844b02c6@linux.intel.com/ Long unsolved problem
5. No way to map backlight sysfs device to display Often multiple backlight sysfs devices for a single display Leaving userspace to guess which one will work Brightness control requires root rights Meaning of value 0 is undefined Problems with current uAPI
6. New uAPI proposal
7. Add new display_brightness and display_brightness_max properties on the drm connector object display_brightness_max == 0 means brightness control is not supported display_brightness_max may change on hotplug events. E.g. plugging in a monitor which supports brightness control over DDC/CI New uAPI proposal
8. Backlight handling technical debt
9. Multiple laptop brightness control methods: Directly by the GPU driver Other driver(s) using $random firmware interface(s) Current approach: Just register sysfs devices for all of them Userspace picks which sysfs device to use based on the type (firmware platform native) → → If kernel heuristics say the native device should be preferred, unregister the others when the native one registers Technical debt
10. Probe ordering issues
11. The new uAPI requires 1 backlight dev (per panel) The kernel heuristics cannot detect if the GPU driver will offer native control The heuristics will only pick native when available This causes the acpi_video backlight device to register before the native driver To fix this acpi_video backlight registration must be delayed till after the GPU drivers are done probing Probe ordering issue 1
12. Sometimes the heuristics find no known brightness control method Then vendor (aka other) is returned The vendor (dell-laptop, asus-wmi, etc) drivers typically load much later then the GPU drivers This causes there to be no brightness control if userspace looks at the drm connectors early Userspace needs hotplug brightness control support for DCC/CI anyways, so the plan is to rely on this Probe ordering issue 2
13. Questions / Discussion hdegoede@redhat.com https://github.com/jwrdegoede/