I have a Samsung Q45 laptop. When I press Fn + UP/Down to change the laptop's brightness, there is one brightness key event, followed by a pause, and then further events repeat very rapidly. If I disable key autorepeat (xset r off) then there are no brightness events at all! Monitoring the events via 'lshal -m' reveal a single event, regardless of the xserver's autorepeat setting. This is a problem because gnome-power-manager gets its brightness key events from the X server, and when I press a key to change the brightness, it grabs the keyboard and does not ungrab it until the brightness stops changing, which means I need to switch to a text mode console and log in and kill it in order to get control of the X server back... This was originally reported at <http://bugzilla.gnome.org/show_bug.cgi?id=576283>. Further details and logs can be found there.
> I have a Samsung Q45 laptop. When I press Fn + UP/Down to change the laptop's > brightness, there is one brightness key event, followed by a pause, and then > further events repeat very rapidly. > > If I disable key autorepeat (xset r off) then there are no brightness events at > all! > > Monitoring the events via 'lshal -m' reveal a single event, regardless of the > xserver's autorepeat setting. Can you run evtest on the corresponding input device? When you press and release that key, you should see something like: Event: time 1237998837.702709, type 1 (Key), code 224 (Brightness down), value 1 Event: time 1237998837.702722, type 1 (Key), code 224 (Brightness down), value 0 (your symptoms might be due to the kernel not sending a keyrelease event)
Here's the output of evtest when pressing the 'Brightness up' key once: Testing ... (interrupt to exit) Event: time 1238003574.986627, type 4 (Misc), code 4 (ScanCode), value 88 Event: time 1238003574.986648, type 1 (Key), code 225 (Brightness up), value 2 Event: time 1238003574.986653, -------------- Report Sync ------------ ^C Compare this to the output when pressing, and holding, the 'A' key: Testing ... (interrupt to exit) Event: time 1238003651.359355, type 4 (Misc), code 4 (ScanCode), value 1e Event: time 1238003651.359376, type 1 (Key), code 30 (A), value 1 Event: time 1238003651.359381, -------------- Report Sync ------------ Event: time 1238003651.610226, type 4 (Misc), code 4 (ScanCode), value 1e Event: time 1238003651.610248, type 1 (Key), code 30 (A), value 2 Event: time 1238003651.610253, -------------- Report Sync ------------ Event: time 1238003651.640940, type 4 (Misc), code 4 (ScanCode), value 1e Event: time 1238003651.640962, type 1 (Key), code 30 (A), value 2 Event: time 1238003651.640969, -------------- Report Sync ------------ Event: time 1238003651.671659, type 4 (Misc), code 4 (ScanCode), value 1e Event: time 1238003651.671679, type 1 (Key), code 30 (A), value 2 Event: time 1238003651.825276, -------------- Report Sync ------------ Event: time 1238003651.881575, type 4 (Misc), code 4 (ScanCode), value 1e Event: time 1238003651.881596, type 1 (Key), code 30 (A), value 0 Event: time 1238003651.881601, -------------- Report Sync ------------ ^C It appears that 'value 1' is key down, 'value 0' is key up, and 'value 2' is key repeated. So is this the kernel's fault, for sending a 'key repeated' message instead of a 'key down' followed by 'key up'?
I just rebooted and noticed that the first time I press the key, it is a 'value 1' event (key down). Subsequent presses are 'value 2' (key repeat). 'value 0' (key up) never happens.
Same cause as Bug 18590, this is a kernel bug. *** This bug has been marked as a duplicate of bug 18590 ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.