After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 576283 - When changing brightness, grabs keyboard and loops forever
When changing brightness, grabs keyboard and loops forever
Status: RESOLVED NOTGNOME
Product: gnome-power-manager
Classification: Deprecated
Component: gnome-power-manager
2.24.x
Other All
: Normal blocker
: ---
Assigned To: GNOME Power Manager Maintainer(s)
GNOME Power Manager Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2009-03-22 13:18 UTC by Sam Morris
Modified: 2009-03-27 10:24 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
verbose output (108.02 KB, application/octet-stream)
2009-03-23 16:19 UTC, Sam Morris
Details
xev output (21.58 KB, text/plain)
2009-03-25 10:48 UTC, Sam Morris
Details

Description Sam Morris 2009-03-22 13:18:54 UTC
Please describe the problem:
When I press the key that changes the screen brightness of my laptop, gnome-power-manager grabs the keyboard, and then changes the brightness (up or down) about once per second, forever.

Pressing the opposite brightness key will cause g-p-m to change the brightness in the other direction. Because the keyboard has been grabbed, there is no way to escape from this state save the reset switch!



Steps to reproduce:



Actual results:


Expected results:


Does this happen every time?


Other information:
May be related to bug 566095. When the power state changes, g-p-m does not trigger this bug; it only happens when manually adjusting the brightness.
Comment 1 Richard Hughes 2009-03-23 14:30:19 UTC
Can you grab the debug output of:

killall gnome-power-manager
gnome-power-manager --no-daemon --verbose

I bet you've got about a thousand brightness states, and that 2.26 works better.
Comment 2 Sam Morris 2009-03-23 16:19:10 UTC
Created attachment 131193 [details]
verbose output
Comment 3 Richard Hughes 2009-03-23 16:31:28 UTC
>hard value=6195, min=0, max=24765

Your hardware is reporting 24765 brightness states. gpm only does sensible things with this number of states.

2009-02-12  Richard Hughes  <richard@hughsie.com>

	* src/gpm-brightness-xrandr.c: (gpm_brightness_xrandr_output_set):
	Don't step through each brightness state when we fade modes, some
	devices using XRandR have an insane number of steps. Use the step
	value we calculated for the _up and _down logic.
	Fixes #566095

This should be fixed in 2.24.4 -- what exact version are you using?
Comment 4 Sam Morris 2009-03-23 17:16:44 UTC
That's odd, I am using 2.24.4. I don't see any Debian-specific patches that would affect the backlight--list at <http://patch-tracking.debian.net/package/gnome-power-manager/2.24.4-1>.
Comment 5 Richard Hughes 2009-03-25 10:36:43 UTC
Reading your debug trace, there looks something wacky with your buttons. Can you try doing:

killall gnome-power-manager
lshal -m

and then pressing the button once. Also try in xev. Do you get multiple button presses?
Comment 6 Sam Morris 2009-03-25 10:47:30 UTC
I think you're right! In with lshal I get:

10:43:16.106: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-down
10:43:16.844: platform_i8042_i8042_KBD_port_logicaldev_input condition ButtonPressed = brightness-up

but with xev, key events occur once, then there is a brief pause, then they repeat rapidly until I press another key. :(
Comment 7 Sam Morris 2009-03-25 10:48:03 UTC
Created attachment 131335 [details]
xev output
Comment 8 Sam Morris 2009-03-25 10:51:19 UTC
If I disable key autorepeat (xset r off) then pressing the brightness keys does not generate _any_ X events! HAL events are still generated though. Enabling autorepeat (xset r on) restores the original behaviour. Weird!
Comment 9 Richard Hughes 2009-03-25 14:56:47 UTC
Thanks for doing this so fast. I don't think that g-p-m is at fault here -- could you please open another bug against Xorg (and possibly the kernel) -- cc me if you need a hand. Thanks.