Packard Bell EasyNote LV need i915.invert_brightness=1

[Daniel Vetter]

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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch