at 00:03, <Mario.Limonciello@xxxxxxxx> <Mario.Limonciello@xxxxxxxx> wrote:
-----Original Message-----
From: Daniel Vetter <daniel.vetter@xxxxxxxx> On Behalf Of Daniel Vetter
Sent: Wednesday, July 24, 2019 6:49 AM
To: Kai-Heng Feng
Cc: dri-devel@xxxxxxxxxxxxxxxxxxxxx; Anthony Wong; Limonciello, Mario
Subject: Re: OLED panel brightness support
[EXTERNAL EMAIL]
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.
Where are you thinking that the opt in magic would occur then? Userspace?
As KH said, at least on Dell it's a known location in EDID to indicate
panel
is OLED, so it seems like this could be a kernel time documented magic at
least
to turn this on in the important scenarios.
I think what Daniel says is to keep a uniform backlight interface.
The next question is, how do we change the brightness level for OLED
displays? Is changing gamma value a good way to do it?
Kai-Heng
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
