Re: OLED panel brightness support

[Daniel Vetter <daniel@ffwll.ch>]

On Tue, Jul 23, 2019 at 06:46:55PM +0800, Kai-Heng Feng wrote:
> Hi,
> 
> Currently, OLED panel brightness [1] is not supported.
> We have a similar Dell system that also affect by lack of OLED brightness
> support.
> 
> I’ve investigated both kernel and user space but I haven’t found a good
> general solution yet.
> Dell systems use EDID descriptor 4 as Dell specific descriptor, which
> reports its panel type and we can know it’s an OLED panel or not.
> 
> My initial thought is to add a new attribute “oled" in drm_sysfs.c [2] to
> let userspace like clutter [3] to control the brightness.
> However other DEs may need to implement their own OLED brightness support
> which isn’t ideal.
> 
> So I’d like to know if there’s any good way to support OLED brightness in
> good old backlight sysfs, to let userspace keep to the current interface.
> 
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=97883
> [2] https://pastebin.ubuntu.com/p/QYrRBppVT9/
> [3] https://gitlab.gnome.org/GNOME/clutter/blob/master/clutter/clutter-brightness-contrast-effect.c#L559

I think the Most Proper Solution would be to integrate the backlight
support into drm, by adding the backlight knobs as kms properties to the
correct connector. This would fix a whole bag of issue:
- no more ill-defined magic for userspace to find the right backlight
- we could have well-defined semantics what happens with the backlight
  across a kms modeset
- issues like this could be solved with a small helper and a bit of code
  in the kernel (there's also other DDC knobs to control backlight, which
  we also don't really expose in a consistent way).

Downside is how to roll this out in a backward compatible way, without
breaking the world:
- fbcon/fbdev needs to be taught to not do it's own backlight wrangling
  for kms drivers which handle backlight natively
- we might need an opt-in magic for this, if it turns out that the kms
  driver handling the backlight breaks stuff
- userspace ofc needs to fall back to its current pile of hacks if the
  backlight stuff isn't supported natively.

Adding more ill-defined sysfs files, or more magice ordering rules, or
anything else like that doesn't sound too appealing.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel