Re: [TECH TOPIC] New userspace API for display-panel brightness control

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 6/28/22 15:53, Jani Nikula wrote:
> On Mon, 20 Jun 2022, Hans de Goede <hdegoede@redhat.com> wrote:
>> <resend to both lists, because of confusion of which list to use>
>>
>> Hi All,
>>
>> As requested here is a copy of my LPC kernel summit track submission:
>>
>> Title: 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.
> 
> 6. It's not possible to change both the gamma and the brightness in the
> same KMS atomic commit. You'd want to be able to reduce brightness to
> conserve power, and counter the effects of that by changing gamma to
> reach a visually similar image. And you'd want to have the changes take
> effect at the same time instead of reducing brightness at some frame and
> change gamma at some other frame. This is pretty much impossible to do
> via the sysfs interface.

Ack, that is a good point.

Regards,

Hans



>> 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.
>>
>>
>> Comments:
>> This is a duplicate submission with one which I submitted for
>> the "LPC Refereed Track" before the "Kernel Summit 2022 CFP" posting.
>>
>> I recently send a RFC email about this to the relevant mailinglists:
>> https://lore.kernel.org/dri-devel/0d188965-d809-81b5-74ce-7d30c49fee2d@redhat.com/
>>
>> As well as another RFC laying out some initial backlight code
>> refactoring steps. As there is a bunch of technical debt which
>> needs to be addressed before work on a new uAPI can even begin:
>> https://lore.kernel.org/dri-devel/98519ba0-7f18-201a-ea34-652f50343158@redhat.com/
>>
>> I'm working on the refactoring now. I believe the refactoring
>> is more likely to land in 5.21 then in 5.20. Let alone that
>> the new uAPI on the kernel side + the mandatory userspace code
>> consuming the uAPI will be ready before plumbers.
>>
>> IOW I expect this to still be very much in flux during Plumbers,
>> so this won't be a presentation presenting only already finished
>> work.
>>
>> Regards,
>>
>> Hans
>>
>>
>