My Brightness levels when running 2.6.38-rc6 are much to low, I can change them with the fn keys and /sys/devices/virtual/backlight/acpi_video0 but even the highest setting 15 is far to low and barely readable indoors. I've been running 2.6.37.1 where it works this is the first rc I tested. My video adapter is reported by lspci as 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) (prog-if 00 [VGA controller]) Subsystem: Dell Device 0418 Flags: bus master, fast devsel, latency 0, IRQ 46 Memory at f0000000 (64-bit, non-prefetchable) [size=4M] Memory at d0000000 (64-bit, prefetchable) [size=256M] I/O ports at 1800 [size=8] Expansion ROM at <unassigned> [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 3 Kernel driver in use: i915 Kernel modules: i915 00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) Subsystem: Dell Device 0418 Flags: bus master, fast devsel, latency 0 Memory at f0400000 (64-bit, non-prefetchable) [size=1M] Capabilities: [d0] Power Management version 3
This probably is a graphics driver issue and I believe it's a duplicate of one of the existing bugs.
I also hit this issue on my Lenovo X61s with following graphics card: 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) (prog-if 00 [VGA controller]) Subsystem: Lenovo T61 Flags: bus master, fast devsel, latency 0, IRQ 42 Memory at f8100000 (64-bit, non-prefetchable) [size=1M] Memory at e0000000 (64-bit, prefetchable) [size=256M] I/O ports at 1800 [size=8] Expansion ROM at <unassigned> [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 3 Kernel driver in use: i915
I performed bisection and the first bad commit is: commit 951f3512dba5bd44cda3e5ee22b4b522e4bb09fb Author: Indan Zupancic <indan@nul.nu> Date: Thu Feb 17 02:41:49 2011 +0100 drm/i915: Do not handle backlight combination mode specially The above commit says this in the message: ... IMPORTANT: However, although usually the above is true, it may not be when people ran an older (2.6.37) kernel which messed up the LBPC register, and they are unlucky enough to have a BIOS that saves and restores the LBPC value. Then a good kernel may seem to not work: Max brightness isn't bright enough. If this happens people should boot back into the old kernel, set brightness to the maximum, and then reboot. After that everything should be fine. ... So I booted older 2.6.37.2 kernel and set brightness to maximum. Then I rebooted to 2.6.38-rc7, brightness was same as in 2.6.37.2. After that I set brightness to minimunm (in new kernel, via "Fn + <lower_brightness>" keypress) and then I rebooted again to 2.6.38-rc7. Now brightness was so low and when I tried to set it to maximum, it was still so low.
First-Bad-Commit: 951f3512dba5bd44cda3e5ee22b4b522e4bb09fb
Yeah, my patch should be reverted, apply Takashi Iwai's patch instead: From f6b8a45b9544072e6ddbb944a4c03a9ec8cbca3a Mon Sep 17 00:00:00 2001 From: Takashi Iwai <tiwai@suse.de> Date: Mon, 21 Feb 2011 14:19:27 +0100 Subject: [PATCH] drm/i915: Fix calculation of backlight value in combined mode The commit a95735569312f2ab0c80425e2cd1e5cb0b4e1870 drm/i915: Refactor panel backlight controls causes a regression for GM45 that is using the combined mode for controlling the backlight brightness. The commit introduced a wrong bit shift for computing the current backlight level. Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=672946 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34524 Signed-off-by: Takashi Iwai <tiwai@suse.de> Cc: <stable@kernel.org> --- drivers/gpu/drm/i915/intel_panel.c | 1 - 1 file changed, 1 deletion(-) --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -176,7 +176,6 @@ val &= ~1; pci_read_config_byte(dev->pdev, PCI_LBPC, &lbpc); val *= lbpc; - val >>= 1; } }
(In reply to comment #5) > Yeah, my patch should be reverted, apply Takashi Iwai's patch instead: I confirm when I revert 951f3512dba5bd44cda3e5ee22b4b522e4bb09fb and apply patch in comment #5 everything works fine for me.
Fixed by commit ba3820ade317ee36e496b9b40d2ec3987dd4aef0 .