Re: [RFC PATCH 2/2] drm/i915: respect the VBT minimum backlight brightness

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jun 3, 2014 at 6:40 PM, Stéphane Marchesin <marcheu@xxxxxxxxxxxx> wrote:
> On Tue, Apr 29, 2014 at 1:30 PM, Jani Nikula <jani.nikula@xxxxxxxxx> 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.

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.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx





[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux