[Bug 53153] [gm45] Backlight shuts off during boot when KMS is enabled

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=53153

--- Comment #34 from Jay Abbott <jpabbott02 at gmail.com> ---
Trying to change the brightness with the wmi hotkeys DOES send a value to
'/sys/class/backlight/acpi_video0', but the screen does not change. Each time I
press Fn+[RightArrow] the value will change in this sequence: [0,2,4,6,8,9].


I'm stating the obvious here, but to consolidate what we know up to this point:

The ACPI backlight control does not work, so we're forced to use the drm to
adjust it instead. 

The drm backlight control is buggy - the max brightness is the minimum and vice
versa. So when the drm kicks in during boot and tries to set the brightness to
max, the backlight shuts off. 

The parameter i915.invert_brightness=1 solves this problem.

So the issue here is really twofold. There is a buggy ACPI which fails to set
the brightness, and a buggy drm which sees brightness values as their inverse.


Now here's the game-changer:

I was looking at dmesg and I noticed it always returns this line:
[   11.089157] acer_wmi: Brightness must be controlled by acpi video driver

I realized that the above line must be critical in understanding what is wrong
with the brightness controller, but I wasn't sure how to interpret it. So I did
some research on the acer_wmi module, and it turns out I need to enable the
backlight subsystem in my kernel config. Take a look, there needs to be an
additional controller called "backlight" here:

jay at jay-debian:/sys/devices/platform/acer-wmi$ ls
driver  interface  modalias  power  rfkill  subsystem  uevent


I will recompile with this enabled and let you know how it goes.
With this finally out of the way, we can focus on figuring out why the drm
brightness control is working backwards.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20130107/183cfb4a/attachment.html>