GNOME Bugzilla – Bug 469748
Brightness keys fail to set backlight brightness correctly
Last modified: 2009-06-13 17:25:28 UTC
Please describe the problem: On an Apple MacBook, the brightness is improperly set when using the keyboard. Brightness is correctly set using the brightness applet and when the computer idles or goes on or off AC power. Steps to reproduce: 1. Start gnome-power-manager. 2. Attempt to use brightness keys. Actual results: The first time one of the keys is pressed, nothing happens. Subsequently, the brightness is set very low. The keys will work, but there are only two separate levels of light, which seem to be the bottom level and one increment above. gnome-power-manager's output indicates that GetBrightness is returning 0. However, manually sending GetBrightness to dbus with `dbus-send --system --print-reply --dest=org.freedesktop.Hal /org/freedesktop/Hal/devices/macbook_backlight org.freedesktop.Hal.Device.LaptopPanel.GetBrightness' returns the correct value. Expected results: Brightness is adjusted properly. Does this happen every time? Yes. Other information:
Also reported at launchpad: https://bugs.launchpad.net/bugs/136693
The problem is in a function that gets the current brightness status. In fact when launching g-p-m the brightness starts from 0 and highers from the selected level. Also see this messages that happen when pressing the hotkeys [button_pressed_cb] gpm-backlight.c:512 (18:27:22): Button press event type=brightness-up (gnome-power-manager:6278): GLib-GObject-CRITICAL **: g_value_set_uint: assertion `G_VALUE_HOLDS_UINT (value)' failed [gpm_brightness_lcd_get_hw] gpm-brightness-lcd.c:116 (18:27:22): GetBrightness returned level: 0 [gpm_brightness_lcd_set_hw] gpm-brightness-lcd.c:155 (18:27:22): Setting 1 of 15
It should be stated that we're getting this because of the patch applied in the ubuntu gnome-power-manager package version 2.19.6-0ubuntu3, so the fix should be expected from ubuntu, not upstream.
This is most certainly a problem upstream. I'm a Gentoo user and this problem is present in an unmodified build from both 2.19.6 and 2.19.92 sources. If the problem on Ubuntu can be traced to a specific patch then perhaps the changes made in that patch are a good place to start looking.
In ubuntu the problem has been fixed in hal, and now g-p-m works!
This doesn't appear to be a HAL problem on my end. Not only does the brightness applet work perfectly, I did not have the problem with the same version of HAL using g-p-m 2.18. As such, it still appears as though this is a g-p-m bug.
Digging a little bit deeper and providing a bit more information: I'm using HAL 0.5.9.1, Gentoo revision 2. 0.5.9 has somewhat broken support for MacBook backlight and the problem isn't solved by downgrading. For what it's worth, I get much the same error message as Nicolò did. I get the following: [button_pressed_cb] gpm-backlight.c:512 (18:25:27): Button press event type =brightness-down (gnome-power-manager:19382): GLib-GObject-CRITICAL **: g_value_set_int: assertio n `G_VALUE_HOLDS_INT (value)' failed [gpm_brightness_lcd_get_hw] gpm-brightness-lcd.c:116 (18:25:27): GetBrig htness returned level: 0 (gnome-power-manager:19382): GLib-GObject-CRITICAL **: g_value_set_int: assertion `G_VALUE_HOLDS_INT (value)' failed [gpm_brightness_lcd_get_hw] gpm-brightness-lcd.c:116 (18:25:27): GetBrightness returned level: 0 [gpm_brightness_lcd_down] gpm-brightness-lcd.c:392 (18:25:27): emitting brightness-changed (0) Looking closely at the code and throwing in a debug statement shows that the command I used in my first post should be equivalent to what g-p-m is doing but somehow GPM gets a value of 0 and dbus-send gets a value of 115.
Created attachment 95829 [details] [review] Fix expected variable type Some more digging and I've got it working. Apparently gnome-power-manager is expecting the wrong sort of value from DBus. The attached patch fixes it for me. I have no other testing environments, so please double-check it on other systems.
I'm seeing the same problem on 2.19.92 with a thinkpad t60p. Haven't had time to test the patch.
I'm seeing the same problem with gnome-power-manager 2.20.0 on Debian sid with a Thinkpad X60. Another way of confirming that the problem is in gnome-power-manager: if I kill gnome-power-manager, the brightness keys start working normally, if I restart it then brightness gets shoved hard back down to the minimum again. Also haven't had time to test the patch.
I see this problem with g-p-m 2.20 on openSUSE also and the patch does fix it.
Created attachment 96353 [details] [review] proposed patch I was getting some other "GLib-GObject-CRITICAL **: g_value_set_int:assertion `G_VALUE_HOLDS_INT (value)' failed" errors as well. Added similar fixes for those to this patch.
I tried #12 proposed patch, but it does not fix this strange behaivor. I'm using Debian unstable on Thinkpad T40.
Debian Sid 2.20.0: problem exists as well (Dell Latitude).
It's still broken in 2.20's branch, but seems to be partially fixed in trunk. @Scott Reeves:BTW shouldn't it be 'gint' rather than simply 'int' in brightness-applet.c's 'policy_brightness'?
The attached patch does *not* fix the problem for me (Debian sid on Thinkpad X60); I don't notice any effect at all from using it. (I applied it on top of the debian patches to gnome-power-manager in debian version 2.20.0-1, which were partially redundant, apparently someone in debian/ubuntu has been trying to fix this as well.)
Okay, I think I understand what's going on here. The problem is that the Hal folks have gone back and forth on whether GetBrightness should return a signed or unsigned integer. The history, as far as I can tell: For a long time, they returned a uint Then someone noticed that this was a spec violation, and made it return an int: http://gitweb.freedesktop.org/?p=hal.git;a=commit;h=8873d79ec94d921e2950d1b860c79be39df30c4f Then after discussion on the mailing list, they decided the spec was wrong and reverted that, so it returned a uint again: http://gitweb.freedesktop.org/?p=hal.git;a=commit;h=7b159b55d6398d2d240817276ae27ed68f11deda And *then* ~3 months later, someone decided that was a bad idea, and reverted the reversion, which made it actually return an int: http://gitweb.freedesktop.org/?p=hal.git;a=commit;h=c7f2d8ce617970c3636a61061b8954bdeffe716a So as far as I can tell, hal version 0.5.10 returns an int, while 0.5.9.1 and earlier return a uint. Distro versions may have further screwed around with this to make things more interesting, of course. Then the problem is that the way gnome-power-manager uses dbus needs to be compatible with whatever the installed version of hal is doing. It works if gnome-power-manager expects a uint and hal provides a uint, or if gpm expects an int and hal provides an int, but not if they disagree. The gpm 2.20 as shipped upstream expects a uint; the patch on this bug changes it to expect an int. AFAICT, the reason the patch doesn't fix the bug for me is that debian's hal *does* return a uint (so upstream gpm should work correctly, and patched gpm should not), but debian's gpm *is already* patched to expect an int (!). Apparently the debian patch in question was imported from ubuntu -- maybe ubuntu is shipping a similarly hacked-up version of hal, but debian isn't, and the debian gpm maintainer wasn't paying enough attention when (s)he imported the patch.
I've confirmed that removing debian's patch fixes the bug for me, and updated the debian report, so hopefully they'll fix it: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=19;bug=443796 In the longer term, I'm not sure what the proper approach for gpm to take is -- for 2.20 assume that people are using hal < 0.5.10, and for 2.22 assume that people are using hal >= 0.5.10? That would be simplest, but even then, I suspect this bug report only scratches the surface of the changes needed to achieve compatibility with this hal change, because it effects the API of many many different hal requests, not just GetBrightness.
The return values patch incorporated in Ubuntu covers everything this patch does and fixes the issue as reported. Closing.
To clarify, the patch came from Ubuntu and was incorporated in 2.20.2.
Ubuntu 9.04 32-bit 2.6.28-11-generic The issue still persists. The display is flashing and power-manager doesn't work correctly - it changes brightness into darkness sometimes. Also "func" + "F10/F11" doesn't work. Lenovo 3000 C200