Red Hat Bugzilla – Bug 485845
Brightness issues with asus-laptop
Last modified: 2009-08-25 04:19:04 EDT
Description of problem:
The latest update of gnome-power-manager which was supposed to fix some brightness issues actually broke the brightness control on my Asus F3P.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. $ gconftool-2 --get /apps/gnome-power-manager/backlight/brightness_ac
$ cat /proc/acpi/ac_adapter/AC0/state
$ cat /proc/acpi/video/VGA/LCDD/brightness
levels: 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
IMO g-p-m should set the brightness to 15 once it's started, but that's another issue. Until now this is the "normal" behavior that I have already seen with previous versions of g-p-m.
2. Try to increase brightness with Fn keys or the brightness applet.
Brightness cannot be increased. Both the applet as well as the popup show brightness already at 100%, although it is not. I first have to _de_crease it a little and then can increase it to full brightness again. Nevertheless /proc/acpi/video/VGA/LCDD/brightness does not change at all.
Brightness applet and popup should reflect the current state correctly.
/proc/acpi/video/VGA/LCDD/brightness should change
Things have become worse with kernel kernel-188.8.131.52-170.2.35.fc10.i686: /proc/acpi/video/VGA/LCDD/brightness always is at 0 and the display is so dark that I hardly can see anything and have to login blindly.
Downgrading to gnome-power-manager-2.24.1-3.fc10.i386 fixes my problems. /proc/acpi/video/VGA/LCDD/brightness still does not change, but at least the display brightness is correct.
Please tell me what you need to debug this problem. TIA.
(In reply to comment #1)
> Downgrading to gnome-power-manager-2.24.1-3.fc10.i386 fixes my problems.
No, not really. But I realized that the problem only appears when I'm on AC. When booting on battery, the brightness is set to the correct value. Nevertheless still no changes in /proc/acpi/video/VGA/LCDD/brightness.
HAL doesn't use /proc/acpi/video/* anymore.
Does this work correctly with XRANDR? This is how g-p-m by default tries to change the brightness, and falls back to HAL and the backlight class if this is not available. If you grab me a gnome-power-manager --verbose log i can start debugging this, although the problem looks deeper than g-p-m.
(In reply to comment #3)
> HAL doesn't use /proc/acpi/video/* anymore.
But it can still be used, right?
> Does this work correctly with XRANDR?
How can I test this? man xrandr does not mention brightness.
> This is how g-p-m by default tries to
> change the brightness, and falls back to HAL and the backlight class if this is
> not available. If you grab me a gnome-power-manager --verbose log i can start
> debugging this, although the problem looks deeper than g-p-m.
Any idea how to get a log of the g-p-m that is started in gdm? I tried editing /usr/share/gdm/autostart/LoginWindow/gnome-power-manager.desktop to
"Exec=gnome-power-manager --verbose > /var/log/gdm/gnome-power-manager.log", but the log is never created, although gdm has the permissions to do so.
Created attachment 338320 [details]
3 x brightness up (no effect)
3 x brightness down (brightness increased in first key stroke)
3 x brightness up again (to full brightness)
I think I delivered the log you asked me for in comment # 3. Is there more you need to debug this problem?
Does this still happen with F11?
Nope, seems to be fixed. Closing.