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

[Linus Walleij <linus.walleij@linaro.org>]

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
  manner
- Userspace can sit back and enjoy the show, but it works
  out-of-the box. No magic thermal daemon.

Examples:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/thermal/thermal-zones.yaml

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

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