ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Jani Nikula <jani.nikula@linux.intel.com>,
Subject: Re: [TECH TOPIC] New userspace API for display-panel brightness control
Date: Wed, 29 Jun 2022 21:26:07 +0200	[thread overview]
Message-ID: <011bf067-8e5f-6105-6989-fffcada1e395@redhat.com> (raw)
In-Reply-To: <87k090rj1a.fsf@intel.com>


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.



>> 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

  reply	other threads:[~2022-06-29 19:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-20  7:41 [TECH TOPIC] New userspace API for display-panel brightness control Hans de Goede
2022-06-20  8:07 ` Hans de Goede
2022-06-28 13:53 ` Jani Nikula
2022-06-29 19:26   ` Hans de Goede [this message]
  -- strict thread matches above, loose matches on Subject: below --
2022-06-16  9:32 Hans de Goede
2022-06-16 20:04 ` Linus Walleij

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=011bf067-8e5f-6105-6989-fffcada1e395@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=jani.nikula@linux.intel.com \
    --cc=ksummit-discuss@lists.linuxfoundation.org \
    --cc=ksummit@lists.linux.dev \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).