Version: 4.5 (using KDE 4.5.2) OS: Linux When using evdev driver + and khotkeys enabled up arrow does not work on my keyboards (I've tested three of them both PS2 and USB). Disabling khotkeys makes the problem disappear. Up arrow works in console and in X+GL games even when khotkeys are disabled. The problem exists from at least KDE 4.4 (maybe even 4.3.x, too) and in KDE 4.5.3, too. But before now I haven't known how to grab any useful logs for it. When I press up arrow I get: kglobalaccel(2497) KGlobalAccelImpl::x11Event: Got XKeyPress event kglobalaccel(2497) GlobalShortcutsRegistry::keyPressed: Got unknown key "Up" in ~/.xsession-errors. And with 'xev' tool: KeymapNotify event, serial 31, synthetic NO, window 0x0, keys: 1 0 0 0 0 0 0 0 0 0 0 0 0 4294967168 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 FocusOut event, serial 31, synthetic NO, window 0x5000001, mode NotifyUngrab, detail NotifyPointer If I try to bind up arrow as shortcut in System Settings it does properly recognize "Up" as up arrow. And one more thing - when KDE starts up arrow works fine for some time (a couple of seconds, maybe minute or so). Reproducible: Always Steps to Reproduce: 1. Enable evdev driver for keyboard in xorg.conf 2. Enable khotkeys in KDE 3. Try to use up arrow in X11 apps (KDE, Gnome,...) Actual Results: Keyboard up arrow stopped working Expected Results: Up arrow should work I use multiseat configuration with two KDE sessions with two X-servers (two graphic cards) started by KDM. The problem occurs on both PS2 and USB keyboard.
I meant: Up arrow works in console and in X+GL games even when khotkeys are _enabled_.
1) Turn off the PrintScreen key that launches KSnapShot when pressed 2) Log off & log in The problem should dissapear. It is a very dissapointing bug...
Thanks Terrible Monster! Indeed it was a problem with PrintScreen shortcut to KSnapShot. After changing shortcut to for example Scroll Lock, up arrow started to work (I haven't even need to logout and login). Yes, it is a dissapointing bug which is here for long time. I wonder if noone else than us was affected by it as there was no bug report for it before I've post it.
Exact problem occured to me for about 2 days now. I am on Kubuntu 10.10 and KDE4.6RC though had never problems before.
That's a weird bug. Textshells on other VTs are naturally not affected (no evdev etc.) and the "GL games" will likely juts grab the keyboard (and mouse) ie. receive all input exclusively. So that's not significant. It sounds like the keyboard map changes at some point and the key that was originally grabbed as "print" is now the up arrow - but then disabling the hotkeys daemon would make kglobalaccel unselect the key that is *now* "print", so "up" would remain selected and not be usable.... I could assume that the multiseat conditon is relevant - the recognition of one keyboard pollutes the configuration of the other (but that would likely be an evdev bug, to begin with) => Is this still a bug? (It's been quite a while, sorry that nobody looked at it)
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.