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
