ksummit.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Linus Walleij <linus.walleij@linaro.org>
To: Hans de Goede <hdegoede@redhat.com>
Cc: ksummit@lists.linux.dev
Subject: Re: [TECH TOPIC] New userspace API for display-panel brightness control
Date: Thu, 16 Jun 2022 22:04:03 +0200	[thread overview]
Message-ID: <CACRpkdaYTFBYFg_Jg1smkXn+FzgWBSk47w6UMFeAx0_VNpkqpg@mail.gmail.com> (raw)
In-Reply-To: <f4a7c2c0-6137-99ff-d216-f09a56031fbb@redhat.com>

On Thu, Jun 16, 2022 at 11:33 AM Hans de Goede <hdegoede@redhat.com> wrote:

> 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

For userspace, using just sysfs you mean?
But that makes it sound like userspace needs to understand
things like backlight-to-panel topology etc.

If you add the presence of ambient light sensors to this mix
things get even messier.

I would rather make the analogy to the thermal subsystem:

- Handles multiple thermal sensors
- Handle linearization of measurements
- Some accumulate and work to monitor a thermal zone
- Handle multiple thermal zones
- Also has cooling devices (such as CPU frequency and fans)
- Policies are applied in the kernel to handle thermal sensors
  and cooling devices and control them in an orchestrated
- Userspace can sit back and enjoy the show, but it works
  out-of-the box. No magic thermal daemon.


Wouldn't backlight rather:

- Handle multiple backlight devices.
- Handle linearization of backlight intensity
- Some accumulate and work as a composite backlight
- Handle multiple composite backlights such as screens
- Also handle ambient light sensors
- Policies are applied in the kernel to handle backlight
  and ambient light sensors together
- Userspace can sit back and enjoy the show but it works
  out-of-the box, no magic backlight daemon

I understand userspace will want to force backlight to user
preferences, older people need more backlight etc.

But isn't it more compelling to handle that as a composite
backlight device than to expose several of them to
userspace? I imagine one big knob per screen
1-100 for userspace, a bool for on/off and a bool to select
augmentation from ambient light sensors or not, the rest
the kernel can figure out.

My point is that this is not just a userspace API, it is
a policy extension of the backlight subsystem.

Maybe this is in line with what you're suggesting.
I guess I just needed to mention ambient light sensors

My personal annoyance is to see several diverging
userspace implementations of policy for using ambient
light sensors with backlight. It is already annoying,
Android has something etc.

I understand that this drives a truck through the old mantra
to keep policy in userspace, but so does thermal already,
so I'd just ask myself what makes most sense.

Just my €0.01

Linus Walleij

  reply	other threads:[~2022-06-16 20:04 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-16  9:32 [TECH TOPIC] New userspace API for display-panel brightness control Hans de Goede
2022-06-16 20:04 ` Linus Walleij [this message]
2022-06-20  7:41 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

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=CACRpkdaYTFBYFg_Jg1smkXn+FzgWBSk47w6UMFeAx0_VNpkqpg@mail.gmail.com \
    --to=linus.walleij@linaro.org \
    --cc=hdegoede@redhat.com \
    --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).