Version: (using KDE KDE 3.5.2) Installed from: Ubuntu Packages OS: Linux I have a system which uses x11-evdev. My "UP"-Key has the keycode 111. Whenever I press it, ksnapshot starts. When ksnapshot is not installed Konqueror opens up with locate:ksnapshot. Keycode 111 is the "Print Screen" button on regular keyboard. It might be a configuration error, but it also might be hardcoded somewhere. I have set this report to "Crash" because my system once crashed when I pressed "Up" several times while editing a text. Essentially it tried to start ksnapshot a hundred times which crashes the system. I believe that but should be simple to fix if one knows where to search for it. Thank you verry much.
In some cases kded seems to crash. After that, all the button events seem to get sent to the application having the focus, then the button works again.
It is not hardcoded in KDE. Maybe it is in your distro. File a bug report with them. Key 111 is PrintScreen. I suggest you fix your keyboard layout instead.
Thiago, this is definately a KDE bug, although it seems to happen only when you use the evdev driver instead of kbd. I'm experiencing the same problem here, and my keyboard layout is all right. When i run just X, an xterm and xev, the up arrow works all right. Xev says the following when i press it: KeyPress event, serial 30, synthetic NO, window 0xa00001, root 0x106, subw 0xa00002, time 2015542060, (53,32), root:(540,55), state 0x0, keycode 111 (keysym 0xff52, Up), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 30, synthetic NO, window 0xa00001, root 0x106, subw 0xa00002, time 2015542124, (53,32), root:(540,55), state 0x0, keycode 111 (keysym 0xff52, Up), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False
btw, my PrintScreen key works fine within KDE (xev says the following: KeyPress event, serial 31, synthetic NO, window 0x3400001, root 0x106, subw 0x3400002, time 2016295874, (23,41), root:(1050,64), state 0x0, keycode 107 (keysym 0xff61, Print), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 31, synthetic NO, window 0x3400001, root 0x106, subw 0x3400002, time 2016295938, (23,41), root:(1050,64), state 0x0, keycode 107 (keysym 0xff61, Print), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False ) As you can see, my PrintScreen key has the keycode 107 but X still recognizes it as being the PrintScreen key. KSnapShot doesn't seem to be triggered by the PrintScreen key itself but by keycode 111, which works as long as the kbd driver is used, but not with evdev :(
Created attachment 18556 [details] patch to fix this Here's a patch to skip the "fix PrtScn/SysRq confusion" hacks when the keycode mappings are obviously different. It fixes the problem here, but someone with a system that needs the hack should probably make sure I haven't broken things there. (To test this with an evdev system, you will also need to run "setxkbmap -keycodes evdev -model evdev" to work around bug 128822.)
Thank your for the patch, Benjamin! I can confirm, that it fixed the problem for me on Debian Unstable. It applies cleanly to the current source-deb "kdelibs" in Debian Unstable, and rebuilding the deb with Benjamins patch applied fixed the problem for me. Claus Hindsgaul
Ok, I've applied the patch to KDE SVN... it should be in the next release (KDE 3.5.6).
*** Bug 133338 has been marked as a duplicate of this bug. ***
Hello, I am using Gentoo, today I tried Multiseat X. Therefore I needed the evdev driver for my keyboard. Now I have the same problem. But I think it was solved? I am using KDE 3.5.9. Thank you! Tobi
Sorry. My mistake. All is working fine! Thanks Tobi
I ran into this abnormality and discovered it was caused by an error in my /etc/X11/xorg.conf file. When using x11-evdev deriver the "XkbModel" must be "evdev", not one of the names that works with the old keyboard driver. In my case "pc104" was specified and that caused the arrow keys to work as reported in this bug. If you must specify "XkbModel" use: Option "XkbModel" "evdev" In the current stable gentoo release it is the default and need not be specified at all. For Example: Section "InputDevice" Identifier "Xkeyboard" Driver "evdev" Option "evBits" "+1" Option "keyBits" "~1-255 ~352-511" Option "Pass" "3" EndSection The above options will automatically detect the keyboard base on configuration data in the Hardware Abstraction Layer (HAL). See the man page: man evdev
And it WAS hardcoded. http://websvn.kde.org/?view=rev&revision=969214