Version: (using KDE 4.3.5) OS: Linux Installed from: Gentoo Packages I have a USB KVM, and switching between computers hooked up to it is basically the same as unplugging the keyboard and plugging it back in. Whenever I switch away from and then back to the system running KDE the keyboard autorepeat settings are set back to the defaults. Based on this equivilent gnome bug: https://bugzilla.redhat.com/show_bug.cgi?id=499958 it sounds like the kde system settings applet should restore my configured keyboard repeat settings whenever a keyboard is plugged in?
Related: bug 182677
Unfortunately I can't reproduce the problem, but I have a laptop so when I reconnect the USB keyboard there's still built-in keyboard connected. When I reconnect USB keyboard it picks up the set repeat rate. Could you please try to have some keyboard permanently connected to the machine why you switch the other with KVM? If that works that means we only have to re-set the repeat rate to new keyboard if none was connected before. I can take a look at that for KDE 4.5
With a different keyboard connected, that keyboard retains all settings when I unplug/plug in the other one. The unplugged one reverts to default X settings, not my personalized KDE settings, regardless of whether or not any other keyboard is plugged into the system. Are you running X with hal and evdev? This problem only occurs when X is doing input hotplugging and seeing the device come and go. As referenced in the redhat bug, if you're using X with the standard keyboard device the kernel deals with hotplugging that, X never knows it came and went. But with X device hotplugging, when the USB keyboard is unplugged: (II) config/hal: removing device HID 05f3:0007 (II) HID 05f3:0007: Close (II) UnloadModule: "evdev" X sees it go away, and when it's plugged back in: (II) config/hal: Adding input device HID 05f3:0007 (**) HID 05f3:0007: always reports core events (**) HID 05f3:0007: Device: "/dev/input/event11" (II) HID 05f3:0007: Found keys (II) HID 05f3:0007: Configuring as keyboard (II) XINPUT: Adding extended input device "HID 05f3:0007" (type: KEYBOARD) (**) Option "xkb_rules" "evdev" (**) Option "xkb_model" "evdev" (**) Option "xkb_layout" "us" (II) config/hal: Adding input device HID 05f3:0007 X configures it with defaults. Per the redhat bug, the desktop environment needs to notice a new keyboard has shown up and configure it with the user's preferences rather than the defaults. Let me know if you need any more information, thanks for looking into this. Actually, with the evdev driver each device can have its own settings. It's beyond the scope of this bug, but it would be nice if KDE allowed you to specify different preferences for each keyboard and pointing device installed.
Hmm, it seems to be more complicated that I wanted it to be :) I am using an X.Org X Server 1.7.7 with HAL and evdev driver 2.4.0. So when new keyboard is plugged in keyboard daemon gets XInput notification. More than that when new keyboard is plugged in the keyboard layouts get reset so keyboard daemon restores configured layouts. I was thinking to add restoring repeat rate etc as well, but I can't see it being lost so I didn't implement restoring anything except layouts. And even if I do I won't be able to test it on my machine... Possibly restoring the rate was fixed in evdev driver? Could you try later evdev? As to configuring separate keyboards, there's "wish" bug 177889, though I am not sure when I have time for this.
I'm currently running xorg server 1.7.6 with evdev 2.3.2 on my desktop. I replicated this problem with those versions on my laptop, and then upgraded my laptop to xorg server 1.7.7 and evdev 2.4.0 with no change in behavior. The built in keyboard kept the repeat rate settings I configured, but the external usb keyboard was reset to X defaults after being unplugged and plugged back in. It's disappointing you can't replicate it :(, there must be something else different between our systems. On the Gnome side they fixed it in their keyboard preferences system so I assumed the same would hold true for KDE. At this point I've implemented a workaround by adding a udev rule that fires when the keyboard is plugged in and runs a script to set the repeat rate to my preference. Bit of a kludge ;), but it helps keep me from going nuts. On the multiple input devices front, from my perspective supporting different pointer devices would provide more utility than multiple keyboards. I've got both a touchpad and a mouse on my desktop, and on the mouse I need to remap the pointer buttons. I'm using xinput to do that, I'm not even sure if KDE supports that. The mouse gets reset to defaults on hotplug too <sigh>, so I added it in to my udev kludge for now. Thanks, let me know if you want me to try anything else.
SVN commit 1129790 by rysin: Do full keyboard initialization in the kded daemon - this allows us to reconfigure when new keyboard is plugged in BUG: 230287 FIXED-IN: 4.5 M +7 -1 CMakeLists.txt M +33 -33 kcm_keyboard.cpp M +1 -1 kcm_keyboard.desktop M +8 -18 kcmmisc.cpp M +0 -4 kcmmisc.h M +2 -2 keyboard.desktop M +4 -0 keyboard_daemon.cpp AM keyboard_hardware.h [License: GPL (v2+)] WebSVN link: http://websvn.kde.org/?view=rev&revision=1129790
I've pushed the code to do the full keyboard initialization in kded daemon (instead of doing hardware in kcm_init and layouts in daemon) - now on each keyboard plug-in event the whole set of keyboard configuration will be reapplied. If you could try if the code from the trunk works for you that would be fantastic.
I tested trunk, and it now works for me, thanks! Could the keyboard daemon also detect replug of USB mouse to fix bug 182677 or is that entirely out of its scope?
Well, I am already getting new device notifications from XInput and filtering it for keyboard. I guess I could check for mouse as well and run "kcminit mouse". Does not look like this hack belongs to "Keyboard Daemon" but then creating separate daemon for mouse just for this might be an overkill. I'll take a look if I can squeeze a fix for mouse in.
Maybe you could rechristen this module the "Input Device Daemon" :)? It seems trunk has diverged enough that this patch won't apply to 4.4.3, the version I'm currently running. As someone else has already confirmed this resolves the issue of maintaining state on keyboard hotplugs I'll anxiously await the release of 4.5. Thanks much for fixing this. Btw, if you're going to start adding mouse functionality it would be sweet to be able to remap pointer buttons per pointer device and have them reapplied on hotplug :). I'll be able to pull the keyboard piece out of my udev kludge when 4.5 comes out but will still need it for my mouse buttons. Thanks again...
I've got a fix for mouse hot-plug (182677) for a trunk in my playpen (reusing hotplug engine of keyboard daemon) but I'd like to test it a bit more. Hopefully will push tomorrow.