Red Hat Bugzilla – Bug 788429
Backlight on Asus Eee PC 1005PEB does not work correctly (fixed)
Last modified: 2012-09-04 13:08:18 EDT
Description of problem:
This seems to be a common problem, the back-light brightness adjusts in a cyclically instead of linearly (i.e.. when brightness is adjusted it goes from no backlight, very dim, dim, a little less dim and then back to no backlight. Also, when the computer comes back from sleep mode or the user is switched the setting goes back to no backlight.
Version-Release number of selected component (if applicable):
How reproducible: Its pretty easy, press the on/off button and then let it boot.
Steps to Reproduce:
1. turn computer on
Actual results: screen is so dim I have to use a flash light to see the screen
Expected results: be able to see the screen.
Ok, so I did find a fix, its sort of an amalgamation of a bunch of different sites. If this can be cleaned up, I'll leave it to those who are more intelligent and more skilled than myself.
open a terminal and su
1. sudo gedit /etc/default/grub
2.find the line:
3. insert a new line
4. save and exit
5. in the terminal type the command:
grub2-mkconfig -o /boot/grub2/grub.cfg
This seemed to solve all my problems, it also seems to fix the brightness control to a linear progression as well.
Hope this helps
grub will not use the linux settings - and the only use of them is to hand them over to the linux kernel.
The only explanation I can see is thus that linux by default leaves the hardware in a state where the backlight is a bit strange and grub doesn't try to mess with the backlight at all.
Grub could perhaps try to restore that to some 'sane' values, but it would also be strange if grub used settings that was completely different from what the user intentionally has selected.
It could thus be considered a bug 'somewhere else' that it leaves the system with odd backlight settings.
Do you see this with the latest f16 updates?
GRUB doesn't touch the backlight at all.
(In reply to comment #2)
> GRUB doesn't touch the backlight at all.
Perhaps it should. Or should this issue be reassigned to the kernel because it is leaving the system in a 'bad' state?
Ok, reassigning to the kernel.
GRUB do not have a full ACPI implementation and do not touch backlight settings. If the kernel by default (and workaround-able with acpi settings) leave the system in a state where the boot loader would have to adjust the backlight then it seems like something that should be fixed in the kernel.
(IIRC there were some similar bugs a year ago, possibly related to upower.)
Gaius, I guess we would need to know if you see the issue with the latest kernel update ... and which kernel version that is.