[Intel-gfx] [RFC PATCH 2/2] drm/i915: respect the VBT minimum backlight brightness

[Stéphane Marchesin]

On Tue, Jun 3, 2014 at 1:26 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Tue, Jun 3, 2014 at 6:40 PM, Stéphane Marchesin <marcheu at chromium.org> wrote:
>> On Tue, Apr 29, 2014 at 1:30 PM, Jani Nikula <jani.nikula at intel.com> wrote:
>>> Historically we've exposed the full backlight PWM duty cycle range to
>>> the userspace, in the name of "mechanism, not policy". However, it turns
>>> out there are both panels and board designs where there is a minimum
>>> duty cycle that is required for proper operation. The minimum duty cycle
>>> is available in the VBT.
>>>
>>> The backlight class sysfs interface does not make any promises to the
>>> userspace about the physical meaning of the range
>>> 0..max_brightness. Specifically there is no guarantee that 0 means off;
>>> indeed for acpi_backlight 0 usually is not off, but the minimum
>>> acceptable value.
>>
>> This is the part we've been relying on in Chrome OS (we assume that 0
>> means off). It seems to me that i915 would be the first, or one of the
>> first drivers to violate this rule (in particular you can find a lot
>> of backlight drivers trying hard to ensure that 0 means off in the
>> backlight drivers directory).
>>
>> For context, we use backlight = 0 as a quick "turn the panel off"
>> function where possible. This allows us to avoid the panel off delay
>> where possible. Breaking this assumption means that we'd pay the panel
>> off delay penalty everywhere, not just with BYT.
>
> Well kde is the opposite and I've had users yelling at me that they
> can't use their system, since acpi pretty much always leaves the
> backlight on when set to 0. And acpi kinda rules on intel platforms.
> So I think I'll merge this one since black screens trumps a slight
> functional degration and we didn't duct-tape over the kde assumptions
> either. Essentially you can't assume anything about backlight values
> besides that bigger values tends to mean brigther. Linearity, absolute
> values and endpoints are kinda all off.

It seems fairly wrong to model the backlight behavior after the only
thing everyone agrees is broken (ACPI). If you go through the
backlight drivers, (at least all the ones I've looked at) ensure that
0 really means off.

>
> If we want to specifically expose an intermediate "panel off" level
> because the full link training is too expensive we imo should do this
> as an intermediate dpms level, e.g. dpms standby.

Training isn't the problem, the panel delays are the problem here (and
not something we can work around because it's part of the panel
specifications which we have to follow). Using dpms wouldn't solve
anything.

Stéphane