LCD Brightness on Laptop Always Set Very Low at Boot

Is there a brightness control available in /proc/acpi/video/*/*/brightness ?

It says <Not Supported>. Hmmm...I wonder why. Suse 9.2 did the same
thing at boot, but Mandrake 10.1 did not dim at startup. This was
Mandrake for the i586, since the AMD64 version would not install
properly ;(

Here is the output from 'dmesg' after applying all synaptic updates today (11
Feb 05). I hope this helps with the default screen brightness issue. Also, I
can't hibernate this computer...only screensaver and turn off LCD function properly:

ole=tty0 quiet splash)
Linux version 2.6.10-2-amd64-k8 (buildd@king) (gcc version 3.3.5 (Debian
1:3.3.5-6ubuntu1)) #1 Fri Feb 4 09:19:24 UTC 2005
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
 BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000d8000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001fef0000 (usable)
 BIOS-e820: 000000001fef0000 - 000000001fefb000 (ACPI data)
 BIOS-e820: 000000001fefb000 - 000000001ff00000 (ACPI NVS)
 BIOS-e820: 000000001ff00000 - 0000000020000000 (reserved)
 BIOS-e820: 00000000fffe0000 - 0000000100000000 (reserved)
No mptable found.
On node 0 totalpages: 130800
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 126704 pages, LIFO batch:16
  HighMem zone: 0 pages, LIFO batch:1
ACPI: RSDP (v000 PTLTD ) @ 0x00000000000f8280
ACPI: RSDT (v001 Arima 161Fh 0x06040000 LTP 0x00000000) @ 0x000000001fef6b6e
ACPI: FADT (v001 Arima 161Fh 0x06040000 PTL_ 0x000f4240) @ 0x000000001fefae66
ACPI: SSDT (v001 PTLTD POWERNOW 0x06040000 LTP 0x00000001) @ 0x000000001fefaeda
ACPI: MADT (v001 PTLTD APIC 0x06040000 LTP 0x00000000) @
0x000000001fefafb0
ACPI: DSDT (v001 Arima 161Fh 0x06040000 MSFT 0x0100000e) @ 0x0000000000000000
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:4 APIC version 16
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, version 3, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ10 used by override.
Setting APIC routing to flat
Using ACPI (MADT) for SMP configuration information
Checking aperture...
CPU 0: aperture @ e0000000 size 256 MB
Built 1 zonelists
Kernel command line: root=/dev/hda1 ro console=tty0 quiet splash
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 65536 bytes)
time.c: Using 1.193182 MHz PIT timer.
time.c: Detected 2004.618 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)
Memory: 507040k/523200k available (1767k kernel code, 15496k reserved, 1003k
data, 148k init)
Calibrating delay loop... 3948.54 BogoMIPS (lpj=1974272)
Security Framework v1.0.0 initialized
SELinux: Disabled at boot.
Mount-cache hash table entries: 256 (order: 0, 4096 bytes)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU: Mobile AMD Athlon(tm) 64 Processor 3200+ stepping 0a
ACPI: Looking for DSDT in initrd... not found!
Using local APIC NMI watchdog using perfctr0
Using local APIC timer interrupts.
Detected 12.528 MHz APIC timer.
checking if image is initramfs...it isn't (bad gzip magic numbers); looks like
an init...

You are running an old kernel; please install the "linux-k8" package which will
always give you the latest version.

The screen still dims, and the ACPI issues seem to persist. Here's my latest
'dmesg' output. Is this the latest 'linux-K8' kernel? Thanks.
root@ubuntu:/home/gene # dmesg
Bootdata ok (command line is root=/dev/hda1 ro console=tty0 quiet splash)
Linux version 2.6.10-3-amd64-k8 (buildd@yellow) (gcc version 3.3.5 (Debian
1:3.3.5-8ubuntu2)) #1 Tue Feb 15 09:41:07 UTC 2005
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
 BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000d8000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001fef0000 (usable)
 BIOS-e820: 000000001fef0000 - 000000001fefb000 (ACPI data)
 BIOS-e820: 000000001fefb000 - 000000001ff00000 (ACPI NVS)
 BIOS-e820: 000000001ff00000 - 0000000020000000 (reserved)
 BIOS-e820: 00000000fffe0000 - 0000000100000000 (reserved)
No mptable found.
On node 0 totalpages: 130800
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 126704 pages, LIFO batch:16
  HighMem zone: 0 pages, LIFO batch:1
ACPI: RSDP (v000 PTLTD ) @ 0x00000000000f8280
ACPI: RSDT (v001 Arima 161Fh 0x06040000 LTP 0x00000000) @ 0x000000001fef6b6e
ACPI: FADT (v001 Arima 161Fh 0x06040000 PTL_ 0x000f4240) @ 0x000000001fefae66
ACPI: SSDT (v001 PTLTD POWERNOW 0x06040000 LTP 0x00000001) @ 0x000000001fefaeda
ACPI: MADT (v001 PTLTD APIC 0x06040000 LTP 0x00000000) @
0x000000001fefafb0
ACPI: DSDT (v001 Arima 161Fh 0x06040000 MSFT 0x0100000e) @ 0x0000000000000000
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:4 APIC version 16
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, version 3, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ10 used by override.
Setting APIC routing to flat
Using ACPI (MADT) for SMP configuration information
Checking aperture...
CPU 0: aperture @ e0000000 size 256 MB
Built 1 zonelists
Kernel command line: root=/dev/hda1 ro console=tty0 quiet splash
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 65536 bytes)
time.c: Using 1.193182 MHz PIT timer.
time.c: Detected 2004.609 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)
Memory: 507040k/523200k available (1769k kernel code, 15508k reserved, 1004k
data, 148k init)
Calibrating delay loop... 3948.54 BogoMIPS (lpj=1974272)
Security Framework v1.0.0 initialized
SELinux: Disabled at boot.
Mount-cache hash table entries: 256 (order: 0, 4096 bytes)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU: Mobile AMD Athlon(tm) 64 Processor 3200+ stepping 0a
ACPI: Looking for DSDT in initrd... not found!
Using local APIC NMI watchdog using perfctr0
Using local APIC timer interrupts.
Detected 12.528 MHz APIC timer.
checking if image is initramfs...it isn't (bad gzip magic numbers); looks like
an initrd
NET: Register...

The same issues persist. Here's the 'dmesg' output after a kernel upgrade (25
Feb 05):
gene@ubuntu:~$ dmesg
Bootdata ok (command line is root=/dev/hda1 ro console=tty0 quiet splash)
Linux version 2.6.10-4-amd64-k8 (buildd@king) (gcc version 3.3.5 (Debian
1:3.3.5-8ubuntu2)) #1 Fri Feb 25 05:26:30 UTC 2005
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
 BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000d8000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001fef0000 (usable)
 BIOS-e820: 000000001fef0000 - 000000001fefb000 (ACPI data)
 BIOS-e820: 000000001fefb000 - 000000001ff00000 (ACPI NVS)
 BIOS-e820: 000000001ff00000 - 0000000020000000 (reserved)
 BIOS-e820: 00000000fffe0000 - 0000000100000000 (reserved)
No mptable found.
On node 0 totalpages: 130800
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 126704 pages, LIFO batch:16
  HighMem zone: 0 pages, LIFO batch:1
ACPI: RSDP (v000 PTLTD ) @ 0x00000000000f8280
ACPI: RSDT (v001 Arima 161Fh 0x06040000 LTP 0x00000000) @ 0x000000001fef6b6e
ACPI: FADT (v001 Arima 161Fh 0x06040000 PTL_ 0x000f4240) @ 0x000000001fefae66
ACPI: SSDT (v001 PTLTD POWERNOW 0x06040000 LTP 0x00000001) @ 0x000000001fefaeda
ACPI: MADT (v001 PTLTD APIC 0x06040000 LTP 0x00000000) @
0x000000001fefafb0
ACPI: DSDT (v001 Arima 161Fh 0x06040000 MSFT 0x0100000e) @ 0x0000000000000000
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 15:4 APIC version 16
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 1, version 3, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ10 used by override.
Setting APIC routing to flat
Using ACPI (MADT) for SMP configuration information
Checking aperture...
CPU 0: aperture @ e0000000 size 256 MB
Built 1 zonelists
Kernel command line: root=/dev/hda1 ro console=tty0 quiet splash
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 65536 bytes)
time.c: Using 1.193182 MHz PIT timer.
time.c: Detected 2004.626 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)
Memory: 507088k/523200k available (1732k kernel code, 15460k reserved, 993k
data, 148k init)
Calibrating delay loop... 3948.54 BogoMIPS (lpj=1974272)
Security Framework v1.0.0 initialized
SELinux: Disabled at boot.
Mount-cache hash table entries: 256 (order: 0, 4096 bytes)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU: Mobile AMD Athlon(tm) 64 Processor 3200+ stepping 0a
ACPI: Looking for DSDT in initrd... not found!
Using local APIC NMI watchdog using perfctr0
Using local APIC timer interrupts.
Detected 12.528 MHz APIC timer.
checking if image is initramfs...it isn't (bad gzip magic numbers); looks like
an initrd
NET: Registered protocol family 16
PCI: Using configuration type 1
mtrr: v2.0 (2...

Update on this screen dimming issue. On my AMD64 laptop, Mandriva Limited Edition 2005 (for i386)
does not dim the screen at bootup (Mandrake 10.1 i386 did not either). However, Ubuntu Hoary,
VidaLinux 1.2 (for AMD64), and Suse 9.3 (full version) continue to have this problem. Obviously,
there must be some package/setting that causes it in these distros. It's very annoying since the
screen must be increased from the lowest brightness setting after each reboot/startup of the laptop.
Hibernating does work in Hoary, so that helps keep me from rebooting too much and having to adjust the
brightness. On hibernate, Hoary does report some BIOS bugs, so maybe this has something to do with
the screen dimming. I'm not a programmer, but wanted to report this bug as best I can.

So the brightness changes when you boot normally, but not when you hibernate?
What's the last line that's printed before the screen brightness changes?

If you could please respond to Matthew's questions, it would make it easier for us to debug this problem.

Honestly, I'm putting this laptop on Ebay, because Gateway's lack of support in fixing a hinge
cracking issue has really pissed me off. This is the second time the laptop's hinge has cracked, and
this time they won't ship it to my overseas military address. Anyway, when the laptop boots, the
bootup text quickly scrolls down the screen. When, it says "Ok, booting the kernel...", that's when
brightness is automatically switched to very low. Then, I immediately use th "Fn" + brightness
up/down (F7/F8) to increase it back up. Actually, the laptop buttons [Fn and brightness minus (F7)]
must be used before [Fn and brightness plus (F8)] will work to successfully increase the brightness.
This is probably some sort of BIOS bug, but that's all the information I can provide with my limited
knowledge. Sorry about selling it, but I must do it before the warranty ends. Thanks.

Ok, thank you. This seems to be a kernel bug of some sort, so reassigning.

This bug has been flagged because it is old and possibly inactive. It may or may
not be fixed in the latest release (Breezy Badger 5.10). It is being marked as
"NEEDSINFO". In two weeks time, if the bug is not updated back to "NEW" and
validated against Breezy, it will be closed.

This is needed in order to help manage the current bug list for the kernel. We
would like to fix all bugs, but need users to test and help with debugging.

If this change was in error for this bug, please respond and make the
appropriate change (or email <email address hidden> if you cannot make the
change).

Thanks for your help.

I intended to sell this laptop. However, I am going to hold onto
it. Currently, it's being fixed by Gateway (Arima) for a defective
DVD burner. Hopefully, I will get it shipped back to me within 2
weeks. Immediately upon receiving it, I will test the final Breezy
64-bit release to see if the "brightness bug" still exists. Please
keep this bug report open and I'll report back. Thanks.

Please confirm with breezy. If it still applies to breezy, please also test
dapper kernel (2.6.15) or wait for dapper flight 2 cd's due in a few days.

I just received the laptop back from repair. First, I used an i386 live CD to test out the laptop.
The screen did not dim to the lowest setting when booting from this liveCD. However, when I booted
from the 64bit installation version (5.10 Breezy), the laptop dimming problem returned. As I
previously stated, I must increase the brightness level from bare minimum (can hardly read screen) to
a reasonable level at every reboot. Please advise me on how to capture debug info. to help you out in
solving this pain in the butt issue.

Problem still exists with Dapper Flight 2. Please advise me on how
to capture debug data, etc. to help solve the issue.

(In reply to comment #15)
> I just received the laptop back from repair. First, I used an i386 live CD to
test out the laptop.
> The screen did not dim to the lowest setting when booting from this liveCD.
However, when I booted
> from the 64bit installation version (5.10 Breezy), the laptop dimming problem
returned. As I
> previously stated, I must increase the brightness level from bare minimum (can
hardly read screen) to
> a reasonable level at every reboot. Please advise me on how to capture debug
info. to help you out in
> solving this pain in the butt issue.

Can you send dmesg output from the working i386 boot?

Created an attachment (id=5449)
dmesg output as request

Here's the dmesg output from th i386 5.10 live cd. Hope it helps. Merry
Christmas!

This bug is targeting Dapper, but seems to be an upstream issue with no fix in sight. Ben, is this actually feasible to fix for Dapper?

actually -- to me, this is a showstopper :/ sad day.

Please fix asap!

Problem still exists on Dapper AMD64 RC. What a pain!

It sounds the same problem I ever encountered.

Method: Set up the brightness from the menu:
System -> Preference -> Power manager ~ brightness (AC , battery)

-jame

Thanks. I sold the Gateway 7405GX laptop with that
issue. Overall, it was a low-quality piece of junk.
No more Gateways for me.

--- Jame <email address hidden> wrote:

> It sounds the same problem I ever encountered.
>
> Method: Set up the brightness from the menu:
> System -> Preference -> Power manager ~ brightness
> (AC , battery)
>
> -jame
>
> --
> LCD Brightness on Laptop Always Set Very Low at Boot
> https://launchpad.net/bugs/12637
>

Bug confirmed still present on emachines M6810 with kernel 2.6.20-9 x86_64 (Feisty herd 4+)
 AMD Athlon 64 3200+; ATI Radeon mobility 9600
  Just before it dimms, the graphical screen is replaced by a text screen, and I see the words 'Kernel is Active' briefly appear at the bottom.

it still happens on my m6805.

On 2/28/07, Richard Green <email address hidden> wrote:
>
> Bug confirmed still present on emachines M6810 with kernel 2.6.20-9 x86_64
> (Feisty herd 4+)
> AMD Athlon 64 3200+; ATI Radeon mobility 9600
> Just before it dimms, the graphical screen is replaced by a text screen,
> and I see the words 'Kernel is Active' briefly appear at the bottom.
>
> --
> LCD Brightness on Laptop Always Set Very Low at Boot
> https://launchpad.net/bugs/12637
>

Still happening on Feisty herd 5 Kubuntu live CD.

Confirmed again on Kubuntu Feisty daily build 20070401 amd_64

Can confirm on a Emachines M6805 using amd_64 on Feisty beta.

Can confirm on my vaio VGN-S1XP with Feisty up-to-date.
Cannot be fixed using Power manager because it has never supported my laptop's LCD. Brightness can be set only with FN keys and it has to be done at every boot, but at least in Edgy the system did not 'forget' the brightness level I set at previous boot.

Guido, did you switch from 32-bit to 64-bit for Feisty? On my m6805, any 32-bit distro I have tried has not had this bug, but any 64-bit version does. Currently using 32-bit Edgy, partly to avoid this issue.

No Aaron, I did not. I have always used 32-bit version (I have a Pentium M).

I'm running Xubuntu Feisty on my AMD Turion 64 laptop with an Nvidia 6150 graphics card. I cannot use the Fn key for any purpose, including adjusting the brightness. somewhere on the net I found that one could do this by "echo {reqd br. level} > /proc/acpi/video/*/LCD/brightness". however i cannot save the file even in sudo mode.... gives an error like "file has changed... still want to save?" It doesn't save even if i answer 'yes'. Attaching the contents of the brightness file......... pl help.

I don't know, so far the debugging hints in here haven't been too detailed/helpful to actually be able to analyze/resolve the problem as an enduser.

I think that since it happens immediately after bootloader and when loading kernel, this may point to vga mode configuration at kernel bootup
triggering the dimming issue (probably some vga BIOS interrupt call either mis-called by Linux or buggy implementation which happens to dim
the display, too).
Please add the vga=ask kernel boot parameter / LILO parameter and try to find out whether choosing some particular value does NOT dim
the display; vga=normal or vga=extended may also be helpful.

If this simple enduser testing doesn't find a way to avoid the dimming, then it might help to completely disable ANY vga card fiddling in kernel;
this might be achieved by trying to completely disable the linux/arch/i386/boot/video.c/set_video() function (place a return; statement near the
very top of this function).
Further places to investigate at would be all video card related files in linux/arch/i386/boot/ (e.g. video-bios.c, video-vesa.c, video-vga.c and video.c).
Even an enduser could add all sorts of disabling "return;" statements to various video functions there to find a way to prevent this from happening.
And yes, these things obviously mean compiling a kernel from source (take /boot/config... file from existing kernel and copy to linux-2.6.XX/.config, make oldconfig,
make-kpkg kernel_image and install it, tell bootloader to use it, that's one good way to do it).

HTH and good luck!

Oh, another important thing: does thorough experimentation with vbetool also happen to be able to trigger this problem, after bootup? Would be interesting to know...

I don't know if I'm up to the challenge of compiling my own kernels. I
haven't done that since about 1.2.x sometime... And that was just to
config in a driver. I'm an old PL/I & COBOL programmer, and quite 'C'
challenged.

  One item of note: this happens with amd_64 kernels only. Last week, I
did an installation of ubuntustudio on this machine, and was pleased to
discover that the LCD didn't go dim on me. But then disappointed to
discover that it installed a 32 bit kernel, and gnome. So I went back to
Kubuntu amd_64, then installed the ubuntustudio-audio packages (less one
that's broken on amd64) So it may be that some of that vga-init code
isn't 64-bit clean.
  There's another video bug open on this machine, but that has to do with
xorg properly detecting the widescreen 1280x800 mode, and is probably
unrelated to this lower-level vga bug.
  -- Rick Green

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
                                   -Benjamin Franklin

The same issue came back with Gutsy i386 up-to-date on my vaio s1xp after having been fixed in final Fiesty.

I've been ignoring the problem for a while because I don't reboot often, but I finally decided to check the bug again to see if any progress was happening.

I tried setting vga=ask, the kernel asks what vga mode you want and you're allowed to make your choice while the screen is bright.
after making the choice (doesn't matter which one, they all seem to work) you see the "Kernel is Active" message after a second and the screen dims again.

right after that you see a [PCI] cannot allocate region (not sure what it says after that, it flashes by real fast and it may or may not be related, might be something specific to my machine)

The question I have is this: what changes between the 32bit boot code and the 64bit boot code in regards to video at that stage.. it's very early in the boot process so nothing should be poking anything, but on the other hand it's possible they stored the brightness value in some memory location that the kernel blows away during boot and it's not video related at all.

If I get the chance, I'll start throwing "got here" kprintf's in the kernel in places before "Kernel is Active" to see what I find.

On Thu, 20 Sep 2007, Robert Drake wrote:

> If I get the chance, I'll start throwing "got here" kprintf's in the
> kernel in places before "Kernel is Active" to see what I find.
>
  On my emachines M6810, the 'Kernel alive' message comes on bright,
followed by a message beginning 'kernel mapping tables... ending with
something that might be an address. THEN, the screen dims. So you might
want to insert your debug flags after those messages, not before.

Try typing this command in a terminal

 xgamma -gamma 0.75

 I have posted my own solution here:

 http://ubuntuforums.org/showthread.php?p=4168042#post4168042

Just booted the Hardy alpha 4 live CD (Kubuntu amd_64), and the LiveCD session booted up normally, without dimming the LCD!
  Since this is a working laptop now, I don't want to do a complete reinstall with the hardy alpha. Is there a way I can install just the kernel package from the hardy CD, and have it be a grub option in my normal Gutsy system? (actually ubuntustudio 7.10 w/ kernel 2.6.22-14-rt)
  I tried opening the liveCD in synaptic, but the only linux-image packages it finds on the CD appear to be older than the kernel I have installed in Gutsy...
  I notice from the package descriptions in adept that Hardy is using a 'generic' kernel for both x86 and x86_64, as well as UP and SMP. The plain x86 kernel in 7.04 didn't exhibit this problem, so is the problem now fixed, or is this 'generic' kernel really an x86 32bit kernel under the covers?

Under Gutsy, the symptoms seem to be:

'Kernel is active' at bottom of screen
'kernel mapping tables...' at bottom of screen
then
[PCI].... appears at the top of the screen, and the screen dimms, almost simultaneously, I can't really tell which is first.

There is in fact a (little) difference. With 2.6.26 the screen is dim when I log in: but if I switch the lcd screen off and on by pressing twice the Fn-key F7, it immediately goes to full brightness and I need not increase brightness step by step, from minimum to full (as I had to do before). Moreover, on shutdown, the Ubuntu splash screen is displayed at high brightness. The pc screen is still bright when I power on (ASUS screen, grub, Ubuntu, all of these are at high brightness) -- and the system switches to dim just before the login screen appears.
((If I am feeding too much info (or maybe too irrelevant info) into this thread, please just tell me!))

Hi! I'm having similar anoying problem. Don't know if different enough to open a new ticket, but here it is.

When I switch on my laptop (a rebranded ECS laptop with Intel VGA) it's LCD brightness state change as:

1. Right after switching on: full bright (OK)
2. GRUB: full bright (OK)
3. Initng, but when the progress bar is waving from left to right and back: full bright (OK) -- I guess kernel does its initialization here
4. Initng, but when the progress bar resets and start growing as services are started: dims (NOT OK) -- I guess that some service, perhaps ACPI missconfiguration loading, dims the LCD
5. GDM: dimmed (NOT OK)
6. Desktop/GNOME Session: dimmed (NOT OK)

After log in I run a script (as root) with the following line to bring brightness back to a suitable state:

"echo 7 > /sys/class/backlight/acpi_video0/brightness"

Although another way to get the same result would be:

"echo 100 > /proc/acpi/video/GFX0/DD03/brightness"

These bring brightness back to normal. But, after running any SDL application, like 'dosbox', the LCD dims again, so I have to re-run the above commands. So, I ran some more tests, they are:

6.1. Desktop/GNOME Session, SDL 'dosbox': dims (NOT OK)
6.2. Desktop/GNOME Session, my own SDL application: dims (NOT OK)

Running the afore mentioned 'echoes' brings the brightness back to normal.

6.3. Desktop/GNOME Session, Screensaver: full bright (OK)
6.4. Desktop/GNOME Session, Suspend: full bright (OK)
6.5. Desktop/GNOME Session, Hibernate: full bright (OK)

Some more details about my system:
* Ubuntu Hardy 8.04
* PCI VGA Controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03)
* Function keys for LCD brightness: they don't work, but I'm not concerned about them by now
* Kernel 2.6.24-19-generic

MY POINTS OF INVESTIGATION:
* Why LCD dims at boot, apparently at services loading time?
* Why the start of a SDL based application dims LCD?
* Screensaver, suspending and hibernating cause no problem

REMAINING TESTS:
* ACPI boot parameter "acpi_apic_instance=2" (as pointed in boot messages)
* ACPI boot parameter "acpi_osi=Linux" (as pointed in boot messages)
As soon as I learn on how to use them with GRUB+initng.

I'm attaching some logging files which may be helpful for debugging. Take some time looking at the 'ACPI Error' messages at 'dmesg.txt' and 'kern.log'.

Output of /etc/lsb-release

Just in case.

About the remaining test, they gave no effect, not a change at all.

* ACPI boot parameter "acpi_apic_instance=2" (as pointed in boot messages)
* ACPI boot parameter "acpi_osi=Linux" (as pointed in boot messages)

I appended those parameters, each a time, at a /boot/grub/menu.lst special entry for ACPI tests (exactly the same as the latest kernel, but with the extra parameters).

By the way, while shuting down the laptop, the LCD dims too.

Additional comments:

- Another source of LCD dim: alternating between virtual terminals (Ctrl+Alt+F2; Alt+F3; Alt+F7...)
- Manual rebooting (typing 'sudo reboot', at a terminal) seems to not dim LCD

Ok, a few more tests as: https://wiki.ubuntu.com/DebuggingACPI

** Methodology: Every parameter was tested after the kernel was booted with 'acpi=off', inclusive **

Results:

1. 'acpi=off': no LCD dim at boot (OK!!!) and function keys for brightness started to work for the first time ever!!
   (*) Complain about 'pnpbios=off' necessary as a kernel paremeter;
2. 'acpi=ht': no LCD dim at boot (OK!!!) and function keys for brightness still working!!
   (*) Complain about 'pnpbios=off' necessary as a kernel paremeter;
3. 'pci=noacpi': LCD dim back at initng time; function keys for brightness don't work anymore (NOT OK); LCD dim at shutdown time again;
4. 'acpi=noirq': LCD dim back at initng time; function keys for brightness don't work too (NOT OK); LCD dim at shutdown time again;
5. 'pnpacpi=off': LCD dim back at initng time; function keys for brightness don't work (NOT OK); LCD dim at shutdown time again;
   (*) Complain about 'pnpbios=off' necessary as a kernel paremeter;
6. 'noapic': LCD dim back at initng time; function keys for brightness don't work (NOT OK); LCD dim at shutdown time again;
7. 'nolapic': boot hanged at 'Starting up ...\nLoading, please wait...'; initng waving the progress bar endlessly

Last comments:
- Font rendering at text virtual consoles degradated a little bit while changing ACPI parameters;
- Fan went to full speed without ACPI;
- System could not boot properly right after 'nolapic' test; hard reboot necessary to bring it back to work.

It seems that the problem lies within ACPI. I'll investigate more from there. More attachments below in the aim to help debugging, as indicated in the website above.

This is weird. I have a dual boot with Windows XP. I have not booted Win XP for almost one month. Today I used it, just to check compatibility between an Open Office file and MS Word. Power off, reboot to Ubuntu: the screen is bright since the beginning of the boot process (Asus splash, grub, Ubuntu splash, etc.). Shutdown and boot again: everything is still bright. I activate a virtual console and go back to gnome: bright screen. MPlayer: bright. This is very hard to understand. ("Yes! Bill Gates made the miracle!!!" -- gosh: could not be worse than that.) A new test: I run acpi_listen before loading mplayer and _no acpi codes_ are being sent any more when I run mplayer (when the screen went dim, acpi codes were sent every time mplayer started).
Windows has certainly not fixed a bug in the Linux kernel. If running mplayer resulted in some weird acpi codes being sent, and (2) these codes are not sent any more, and (3) the kernel is the same, the only thing I can think of is that some kind of bios flag has been switched on or off by WinXP. Some idiosyncratic feature of my laptop that is probably hidden to the Linux developers and probably open to Microsoft.
The conclusion I am inclined to draw is that it is high time for the Linux community to find effective ways for pressing on the manufacturers. Something like boycotting especially hostile manufacturers or explicitly and strongly recommending manufacturers that produce Linux drivers and Linux friendly machines.

Alberto,

I don't experience similar behaviour about alternating between Linux and Windows, Vista in my case.

I also ran acpi_listen before running SDL based dosbox and got not a single output from it. Weird at least.

On my pc (asus f9 series) I fixed it just removing an option on the bios regarding display dimm when powered from battery. That's all.

ubuntu 8.04

I just tested Kubuntu 8.10 RC 1. The bug is still there. I didn't install. I just tested a live CD session.

Actually the bug is worse now: My brightness controls only manage to switch between "dark as hell" and "pretty dark" (back and forth). "Pretty dark" is much too dark to do any work.

Maybe "echo blacklist video | sudo tee -a /etc/modprobe.d/local" will still work as a temporary solution (it's good enough for me), but I can't test that without actually installing (and I'm not sure I want to do that since KDE4 is not really usable yet).

Keeping this open against the actively developed kernel bug against 2.6.15 this will be closed as it does not qualify for a Stable Release Update - https://wiki.ubuntu.com/StableReleaseUpdates . Thanks.

Won't fix???? Why?

Well this one must be quite a bugger because it's taken this long to tackle.

On Thu, Oct 30, 2008 at 3:15 AM, Bertilo <email address hidden> wrote:

> Won't fix???? Why?
>
> --
> LCD Brightness on Laptop Always Set Very Low at Boot
> https://bugs.launchpad.net/bugs/12637
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Won't fix? You must be joking. Come on guys, nobody knows how to fix it for months/years, so you mean I should finally persuade myself that my screen is bright when it is dim?

does this have any relation with my dmesg's output:

"thinkpad_acpi: CMOS NVRAM (7) and EC (6) do not agree on display brightness level"

?

Upgraded to Intrepid Ibex, kernel 2.6.27-7. The bug is still there, dimming after boot. BUT, after login, it brightens again, it seems to be brightening to the same level that was left behind by the user.

If this is a kernel bug not solvable I think the Ubuntu team made a nice workaround. :)

When I tested Intrepid Ibex, the bug was still there, and I still needed to put "blacklist video" in "/etc/modprobe.d/local". That workaround is OK for me, but the bug should still be fixed. Others will want to use their brightness controls (the workaround disables them).

The bug is clearly in the kernel. I've recently seen it (or some incarnation of it) in Mandrake 2009 and also in the Gparted live CD.

The bug should probably be reported to the Linux kernel developers, but I don't know how.

I meant Mandriva Linux Free 2009 of course (not "Mandrake 2009"). Sorry...

Same issue on a Toshiba Portege M600 that has an intel video card (GMX 4600, but it does not seem to be the issue at all) on Intrepid with all updates as of today.

Here are the brightness files after a boot :

cat /proc/acpi/video/*/*/brightness
<not supported>
<not supported>
<not supported>
levels: 100 42 0 14 28 42 56 70 84 100
current: 100
<not supported>

But the level should actually be 0 (display is dimmed). I also attach the gnome bug report file.

I believe progress has been made. I no longer have the issue on my Asus A7F anymore.

Hello, I posted before when Ubuntu switched to 8.04. The brightness was dim on boot/media player start/Game and not as bright. .I then switch to Archlinux but the problem cotinued but was not as bad, i.e. only dim once then not the next time you start vlc or game. Then came Ubuntu 8.10 and the problem became strange. Dim on boot and screen saver Only. And the brightness controls started going bright-> dim-> then bright again instead of dim->bright. I fooled around fixing the errors in the DSDT but could not fix the problem. This do to the lack of documentation on ACPI and AML. Then came chrismulderza on the ubuntuforums.org. He found out that the DSDT in the Lenovo Idea Pad Y510 was not giving the info to the kernel in the order it needed it and spesified in the ACPI standerds. In fact it was just spiting the info about the audio to the kernel and not ordering it at all. So, he fixed it and now the brightness is fixed.

http://ubuntuforums.org/showthread.php?t=870681&page=21

Just to make it clear.

This is all the deliberate act of Microsoft to make all computers only run on windows. They were taken to the supreme court of the United States of America and Found Guilty.

ACPI standers were made by a group of compays. Intel and Microsoft were among them. In the end intel made a compiler and Microsoft made one. Microsoft one is not standers compliant and Microsoft makes windows be able to run on messed up DSDT's and such that come out of there compiler. So, when computer manufacturers are writing the DSDT's and such they use the Micosoft compyler. Why maybe they are installing windows on most of the computers so they don't care. OR they just don't relies that the Microsoft complier sucks. At the end of the day windows only computers are pumped into the market.

Confirmed at Model Haier H60S
Linux ihw-laptop 2.6.27-9-generic #1 SMP Thu Nov 20 21:57:00 UTC 2008 i686 GNU/Linux

But
Fedora is OK for this issue.
Dim when boot. But it will be OK after X window startup (automatic).

This problem exists on a Lenovo x200 running Kubuntu 8.10.

$ uname -r
2.6.27.11-generic
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 8.10
Release: 8.10
Codename: intrepid

This is a follow up.

I installed "ubuntu-8.10-desktop-amd64.iso".
I rebooted several times.
no problem

I then ran:
$ sudo apt-get update
$ sudo apt-get install linux-image-2.6.27-7-generic
I rebooted several times.
no problem

I then ran:
$ sudo apt-get install linux-image-2.6.27-11-generic
I rebooted and
the dimness appeared

I installed "ubuntu-8.10-desktop-amd64.iso" again.
I rebooted several times and each time no problem.

Then I ran:
$ sudo apt-get install linux-image-2.6.27-11-generic
I rebooted and the dimness again appeared.

I the "ONLY" other thing I did was connect to the internet through my router.
So as far as I am concerned the problem is created with the "linux-image-2.6.27-11-generic" install.

echo blacklist video | sudo tee -a /etc/modprobe.d/local

This above worked for me on an ASUS X71Q and Ubuntu Jaunty with 2.6.28-13-generic. After running the above and rebooting, then hitting F5 (brightness up) until it reached max, all of the problems went away. I can't use the gnome-panel brightness applet of course, but my Fn keys still work fine.

I've tested ubuntu 9.10 alpha 2 on my Thinkpad r50e and I couldn't reproduce
this bug. Can someone confirm this?

I had this problem on a Asus Z53Sseries notebook, too. Since a kernel update in ubuntu 8.10 this behaviour is gone. I currently use ubuntu 9.04 and everything is fine there.

I too no longer have this issue. It seems fixed for me. :)

@reh4c, since you are the original bug reporter. Can you comment if this is resolved for you as well with the latest Jaunty 9.04 release? Please let us know your results. Thanks.

Hey guys.

I'm not having this issue any more. Due to two main reasons. I switched to Fedora some time ago. To F10. And it did have the same issue in my laptop. In one of its kernel updates the issue was solved. Currently I'm running Fedora's kernel 2.6.27.25-170.2.72.fc10.i686.

Probably this was an driver/ACPI update. The kernel solution was so good that even LCD dim when lauching SDL applications was solved. Now SDL applications don't dim LCD brightness anymore.

What I can do is, before upgrading to F11, give a try to newest Ubuntu release and post my findings here. I'll do that.

Cheers.

I'm marking this Fix Release for now based on the multiple comments that this appears to be resolved. Thanks.

I just removed the "blacklist video" to check if the bug is still there. It is. There is absolutely no difference. The screen dims etc. (see my earlier comments). I use the latest Ubuntu 9.04. No fix in sight. Back to "blacklist video".

LinkedIn
------------

Bug,

I'd like to add you to my professional network on LinkedIn.

- Jason Brower

Jason Brower
Developer at Xemec Oy
Finland

Confirm that you know Jason Brower
https://www.linkedin.com/e/-y3wvuh-gdufa609-1x/isd/1648488186/lhrGviA6/

------
(c) 2010, LinkedIn Corporation