On Fri, Jun 28, 2013 at 02:15:16PM +0200, Daniel Vetter wrote:
On Thu, Jun 27, 2013 at 05:05:44PM +0200, Petter Reinholdtsen wrote:
[Daniel Vetter]
The buttons might do something fancy behind the scenes (kernel or userspace), so can you please also check whether directly changing the backlight values in /sys/class/backlight works correctly?
There is full brightness when I set the value of max_brightness into the brightness file (as in 'echo 4882 > brightness'), and complete darkness when it is set to 0. This was using acpi_backlight=vendor. I suspect that mean the intel_backlight driver is working correctly, but am not sure if 0 is supposed to be completely dark or not.
Ok, so the intel backlight actually seems to work here and we only have a funny interaction between the acpi backlight and the intel backlight. I'll drop your patch to invert the i915 backlight brightness again.
acpi can't invert, and the different backlight drivers can affect each another in funny ways. Which is way we have a clearly defined priority order that userspace should use, and then _only_ touch the selected backlight. ACPI wins over i915, so if the ACPI backlight is broken (but the raw i915 backlight driver works) we need to blacklist it.
Right. I guess my findings above mean the hardware should be blacklisted (from acpi?).
Sounds like. Please file a bug report against ACPI -> Video on bugzilla.kernel.org.
When you file that bug please add me and Jani Nikula to the cc list. We have a few other inverted brightness quirks all on similar machines. So this could all be due to the same strange interaction between drm/i915 and teh specific ACPI implementation on these machines.
Thanks, Daniel