On Sat, 21 Jan 2012 17:09:25 +0000, Chris Diamand<chris.diamand@xxxxxxxxx> wrote:0x00 is the brightest. It gets very gradually dimmer up to about 0xB0, when the gaps betweenHi,Can you experiment with other values? I'd like to know if it's
I have the problem described in the thread here
(https://lkml.org/lkml/2011/4/29/217) where the backlight
values are reversed so although stuff is displayed on the screen, the
backlight is off. This occurs with kernels from about 2.6.39 onwards.
After booting a "broken" kernel (>~2.6.39), the backlight can be lit
temporarily with:
setpci -s 00:02.0 F4.B=0
and then turned off with:
setpci -s 00:02.0 F4.B=FF
completely reversed, or if there's some other interaction here.
Testing 0x80, 0x7f, 0x01, 0xfe would all be interesting to me.
I suspect that writes to the LPBC value are being trapped by SMI andYes, with Fn-F6. It turns back on again when the mouse is moved or a key is pressed.
'doing things' underneath.
Yesterday I tried this patch, https://lkml.org/lkml/2011/4/30/37 byCan you still turn the backlight off with this patch in place?
manually applying it to the 3.2.1
kernel source - this fixes the problem.
** Unfortunately the LKML thread stops after this patch and given thatThe patch would completely bypass LPBC-based brightness controls if the
the problem is still present in the latest source, this code wasn't
pushed into the kernel. Is there a reason for this or was it just
forgotten about? What can I do about this? I am happy to make a git
patch with the latest source if this will help.
backlight happened to be off when the driver started, which isn't
exactly what you want.