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): gnome-power-manager-2.24.4-1.fc10 How reproducible: always Steps to Reproduce: 1. $ gconftool-2 --get /apps/gnome-power-manager/backlight/brightness_ac 100 $ cat /proc/acpi/ac_adapter/AC0/state state: on-line $ cat /proc/acpi/video/VGA/LCDD/brightness levels: 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 current: 13 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. Actual results: 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. Expected results: 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-2.6.27.19-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. Richard
(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] g-p-m log 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.