OLED panel brightness support

OLED panel brightness support

[Kai-Heng Feng]

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

Kai-Heng
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: OLED panel brightness support

[Daniel Vetter]

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

Re: OLED panel brightness support

[Kai-Heng Feng]

at 00:03, <Mario.Limonciello@dell.com> <Mario.Limonciello@dell.com> wrote:

>> -----Original Message-----
>> From: Daniel Vetter <daniel.vetter@ffwll.ch> On Behalf Of Daniel Vetter
>> Sent: Wednesday, July 24, 2019 6:49 AM
>> To: Kai-Heng Feng
>> Cc: dri-devel@lists.freedesktop.org; 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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: OLED panel brightness support

[Daniel Vetter]

On Thu, Jul 25, 2019 at 03:35:40PM +0800, Kai-Heng Feng wrote:
> at 00:03, <Mario.Limonciello@dell.com> <Mario.Limonciello@dell.com> wrote:
> 
> > > -----Original Message-----
> > > From: Daniel Vetter <daniel.vetter@ffwll.ch> On Behalf Of Daniel Vetter
> > > Sent: Wednesday, July 24, 2019 6:49 AM
> > > To: Kai-Heng Feng
> > > Cc: dri-devel@lists.freedesktop.org; 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.

Yup. The current approach just doesn't really work, and you end up with
fun like this, where I guess it looks like there's a brightness control,
but it doesn't work.

For opt-in maybe we need a separate per-drm_driver value that indicates
whether this uniform backlight interface is supported. Then userspace
knows that absence of the backlight properties means there's not backlight
support (and it needs to fake it using gamma tables or whatever).

We might also need to set this knob on a per-device/generation/platform
basis, since with long-standing drivers like i915 it'll be a ton of work
to move everything over - essentially we need to implement the current
pile of ad-hoc hacks userspace uses in the kernel, and then improve the
situation going forward.

> The next question is, how do we change the brightness level for OLED
> displays? Is changing gamma value a good way to do it?

There's no overall amplifier knob to set general brightness on these?
-Daniel

> 
> Kai-Heng
> 
> > 
> > > -Daniel
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
> 
> 

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

Re: OLED panel brightness support

[Sam Ravnborg]

Hi Daniel.
 
> 
> > The next question is, how do we change the brightness level for OLED
> > displays? Is changing gamma value a good way to do it?
> 
> There's no overall amplifier knob to set general brightness on these?

I just looked up two random OLED controllers.
They have a "Contrast" - which is wired to set_gamma.
See for example:

fb_sh1106.c:
/* Gamma is used to control Contrast */
static int set_gamma(struct fbtft_par *par, u32 *curves)
{
        /* apply mask */
        curves[0] &= 0xFF;

        /* Set Contrast Control for BANK0 */
        write_reg(par, 0x81, curves[0]);

        return 0;
}


And fb_ssd1306.c:
/* Gamma is used to control Contrast */
static int set_gamma(struct fbtft_par *par, u32 *curves)
{
        /* apply mask */
        curves[0] &= 0xFF;

        /* Set Contrast Control for BANK0 */
        write_reg(par, 0x81);
        write_reg(par, curves[0]);

        return 0;
}

I have a few ssd1306 panels in the mail, so when I get some spare time I
will try to make a tiny DRM driver for them.
But starting on the backlight stuff seems to a bit more complicated.

Hmm... browsing backlight code I see that FB_EARLY_EVENT_BLANK and FB_R_EARLY_EVENT_BLANK
are not used - time to delete some code...

	Sam
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: OLED panel brightness support

[Daniel Vetter]

On Thu, Jul 25, 2019 at 3:12 PM Sam Ravnborg <sam@ravnborg.org> wrote:
>
> Hi Daniel.
>
> >
> > > The next question is, how do we change the brightness level for OLED
> > > displays? Is changing gamma value a good way to do it?
> >
> > There's no overall amplifier knob to set general brightness on these?
>
> I just looked up two random OLED controllers.
> They have a "Contrast" - which is wired to set_gamma.
> See for example:
>
> fb_sh1106.c:
> /* Gamma is used to control Contrast */
> static int set_gamma(struct fbtft_par *par, u32 *curves)
> {
>         /* apply mask */
>         curves[0] &= 0xFF;
>
>         /* Set Contrast Control for BANK0 */
>         write_reg(par, 0x81, curves[0]);
>
>         return 0;
> }
>
>
> And fb_ssd1306.c:
> /* Gamma is used to control Contrast */
> static int set_gamma(struct fbtft_par *par, u32 *curves)
> {
>         /* apply mask */
>         curves[0] &= 0xFF;
>
>         /* Set Contrast Control for BANK0 */
>         write_reg(par, 0x81);
>         write_reg(par, curves[0]);
>
>         return 0;
> }
>
> I have a few ssd1306 panels in the mail, so when I get some spare time I
> will try to make a tiny DRM driver for them.
> But starting on the backlight stuff seems to a bit more complicated.
>
> Hmm... browsing backlight code I see that FB_EARLY_EVENT_BLANK and FB_R_EARLY_EVENT_BLANK
> are not used - time to delete some code...

5.3-rc1 has patches from me to fix that, it's gone already. These two
events are gone from the backlight code. They're still used by the lcd
driver stuff in backlight/lcd.c.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: OLED panel brightness support

[Sam Ravnborg]

Hi Daniel.

> >
> > Hmm... browsing backlight code I see that FB_EARLY_EVENT_BLANK and FB_R_EARLY_EVENT_BLANK
> > are not used - time to delete some code...
> 
> 5.3-rc1 has patches from me to fix that, it's gone already. These two
> events are gone from the backlight code. They're still used by the lcd
> driver stuff in backlight/lcd.c.

backlight/lcd.c call the callbacks.
But the callbacks are never set so we can drop the support.

Patch coming, you are cc:

	Sam
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: OLED panel brightness support

[Jani Nikula]

On Thu, 25 Jul 2019, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Thu, Jul 25, 2019 at 03:35:40PM +0800, Kai-Heng Feng wrote:
>> The next question is, how do we change the brightness level for OLED
>> displays? Is changing gamma value a good way to do it?
>
> There's no overall amplifier knob to set general brightness on these?

Usually there would be. There's no backlight, it's just the OLED
brightness, so you'd need to talk to the panel itself. On eDP this would
be accomplished by using DPCD, on command mode DSI by using DCS
commands. VESA specifies the DPCD commands to use, and we have some
level of support for that in i915 (granted, should be one level higher
in drm core, but I digress).

It's just that at least in the case of the referenced bug, it doesn't
seem to use the standard DPCD commands. To support that, someone would
have to acquire the panel specs or reverse engineer the proprietary
stuff. And then you'd have to mess the driver to do things differently
to cater for individual proprietary panels.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: OLED panel brightness support

[Jani Nikula]

On Tue, 23 Jul 2019, Kai-Heng Feng <kai.heng.feng@canonical.com> wrote:
> Hi,
>
> Currently, OLED panel brightness [1] is not supported.

As a general statement this is not true, and not backed up by the
referenced bug. We just don't know how brightness is controlled on that
particular laptop, because it apparently uses a properietary mechanism.

If it used the brightness control mechamism specified in the VESA eDP
spec, it should work just fine with the i915 aux backlight support, and
we should also export the regular backlight sysfs for this.

BR,
Jani.


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

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: OLED panel brightness support

[Kai-Heng Feng]

at 16:26, Jani Nikula <jani.nikula@linux.intel.com> wrote:

> On Tue, 23 Jul 2019, Kai-Heng Feng <kai.heng.feng@canonical.com> wrote:
>> Hi,
>>
>> Currently, OLED panel brightness [1] is not supported.
>
> As a general statement this is not true, and not backed up by the
> referenced bug. We just don't know how brightness is controlled on that
> particular laptop, because it apparently uses a properietary mechanism.
>
> If it used the brightness control mechamism specified in the VESA eDP
> spec, it should work just fine with the i915 aux backlight support, and
> we should also export the regular backlight sysfs for this.

I am told that Windows introduced “NitsBrightness” [1] to support OLED panel.
I don’t know how it’s plumbed to the aux interface though.

Is it possible to ask Windows graphics team how Windows handle OLED panel?

[1]  
https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/d3dkmdt/ns-d3dkmdt-_dxgk_brightness_caps

Kai-Heng

>
> BR,
> Jani.
>
>
>> 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
>>
>> Kai-Heng
>
> -- 
> Jani Nikula, Intel Open Source Graphics Center


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: OLED panel brightness support

[Jani Nikula]

On Mon, 29 Jul 2019, Kai-Heng Feng <kai.heng.feng@canonical.com> wrote:
> at 16:26, Jani Nikula <jani.nikula@linux.intel.com> wrote:
>
>> On Tue, 23 Jul 2019, Kai-Heng Feng <kai.heng.feng@canonical.com> wrote:
>>> Hi,
>>>
>>> Currently, OLED panel brightness [1] is not supported.
>>
>> As a general statement this is not true, and not backed up by the
>> referenced bug. We just don't know how brightness is controlled on that
>> particular laptop, because it apparently uses a properietary mechanism.
>>
>> If it used the brightness control mechamism specified in the VESA eDP
>> spec, it should work just fine with the i915 aux backlight support, and
>> we should also export the regular backlight sysfs for this.
>
> I am told that Windows introduced “NitsBrightness” [1] to support OLED panel.
> I don’t know how it’s plumbed to the aux interface though.

That would be about what the numbers we expose to userspace mean. That's
a completely different problem from the kernel not being able to adjust
the brightness of a panel, OLED or not, via the DPCD because of the
non-standard interface being used.

BR,
Jani.


>
> Is it possible to ask Windows graphics team how Windows handle OLED panel?
>
> [1]  
> https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/d3dkmdt/ns-d3dkmdt-_dxgk_brightness_caps
>
> Kai-Heng
>
>>
>> BR,
>> Jani.
>>
>>
>>> 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
>>>
>>> Kai-Heng
>>
>> -- 
>> Jani Nikula, Intel Open Source Graphics Center
>
>

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel