I'm on Kubuntu 15.04, with kwin and other kde packages version 4:5.2.2a-0ubuntu1. That didn't seem to be an option in the "Version" box. In System Settings -> Input Devices -> Keyboard -> Advanced, I have "Caps Lock -> Make Caps Lock an additional Ctrl" enabled (like any sane person that uses emacslike keybindinds in anything). This worked fine, exactly like setxkbmap -option ctrl:nocaps, except that it occasionally goes back to the default layout on its own, while I'm using the system. I didn't log out, suspend, plug in any USB devices, or do anything that would explain this. The settings GUI still has the box checked. Unchecking/rechecking and clicking "apply" enables it again. repeat delay/rate customization is also lost, so I have to xset r rate 250 35 again. I even unset the keybind for "switch keyboard layout", but it still happens maybe once per 2 hours. I haven't detected a pattern yet in what I'm doing. Old cruft in /etc or my home directory is not a possibility: I did a fresh install of Kubuntu, and moved aside all my dotfiles in my home directory before logging in to KDE for the first time. (And then cherry-picked a few, like .bash*, .less*, but not .kde, .config, .local, or .cache). Reproducible: Always
I just noticed my keyboard lights blink while this happened again. Turns out my keyboard was disconnecting/reconnecting after all, as I can see in dmesg output.
I editted the title, but I don't think I can edit the report body. KDE should be able to detect the input device hotplug events and re-apply settings, right? This is a desktop system, and the keyboard that was disconnect/reconnecting is the only real keyboard present in the system. (My Logitech g602 mouse is also a USB keyboard, so it can send keypresses for some of its mouse buttons, if you program them that way.)
KDE actually has a code to detect keyboard hotplug event and it reapplies the settings. Could you please turn on debug for kded in kdebugdialog and when this happens again attach your .xsession-errors file?
Ok, I need sleep, so I'll get to this tomorrow. But I reproduced the problem right away unplugging my USB keyboard, and plugging it back in after a few seconds (rather than milliseconds), so it seems to just be completely broken in Kubuntu 15.04. Unless it's fooled by the "keyboard" device presented by my mouse into thinking that all the keyboards haven't been unplugged, or that my real keyboard isn't the "main" keyboard? Anyway, will post proper debug output soon.
I'm on Kubuntu 15.04 with 5.2.2. I have a Logitech K810 bluetooth keyboard and I'm experiencing the same problems wrt. keyboard settings having to be reset every time the keyboard reconnects (after reboots, etc.). The settings seem to still be in place in the Keyboard System Settings, but they do not have any effect. My only customized setting is the repeat delay, which I've set down to 180 ms. After every reconnect of the keyboard, I have to modify some setting and then setting it back to my preferred value (e.g. clicking repeat delay up to 230 ms and then down to 180 ms again) to enable the Apply button and thus force the setting to take effect. It seems that the KDE input config file (kinputrc) is not updated for the keyboard settings. My custom mouse settings are there, but the keyboard settings never seem to be added. I've currently worked around this issue by using kwriteconfig to manually update the config file (kwriteconfig --file kinputrc --group Keyboard --key RepeatDelay 180). My custom keyboard settings now persists between reconnects of the keyboard.
kdebugdialog had entries for: 601 phonon (kded module) 70720 kded4 On replugging my kbd, I got: Solid::Backends::UDev::input_str_to_bitmask can't handle some bits ("42bc", "0", "0", "f00", "80001000", "1", "400", "2040000", "401878", "d800d408", "1e0000", "0", "0", "0") Solid::Backends::UDev::input_str_to_bitmask can't handle some bits ("42bc", "0", "0", "f00", "80001000", "1", "400", "2040000", "401878", "d800d408", "1e0000", "0", "0", "0") Solid::Backends::UDev::input_str_to_bitmask can't handle some bits ("42bc", "0", "0", "f00", "80001000", "1", "400", "2040000", "401878", "d800d408", "1e0000", "0", "0", "0") kcm_keyboard: configuring layouts false configuring options true kcm_keyboard: Fetched layout groups from X server: layouts: ("us") variants: ("") Which I assume is expected given Tore's finding that the problem was the config GUI not putting the settings where the other part of KDE was looking for them.
I also found that the advanced keyboard settings are not reapplied after wake up from suspend (I have caps lock mapped as an extra Esc for vim, and both shits pressed together turn on caps lock), which is a nuisance on a laptop. From Tore's feedback, I tried to adapt (with no success): kwriteconfig --file kxkbrc --group Layout --key Options 'caps:escape,shift:both_capslock_cancel' It looks like this affects the file: ~/.kde/share/config/kxkbrc While using the GUI reflects the advance keyboard settings in the file: ~/.config/kxkbrc Even if both files have the same content, the configuration is not picked up on wake up form suspend. I am running a fully updated Kubuntu 15.04, migrated recently from 14.10.
(In reply to Ricardo from comment #7) > I also found that the advanced keyboard settings are not reapplied after > wake up from suspend (I have caps lock mapped as an extra Esc for vim, and > both shits pressed together turn on caps lock), which is a nuisance on a > laptop. I can confirm this observation: On Kubuntu 15.04, keyboard settings from Systemsettings are not reapplied if the keyboard is un- and replugged, and not reapplied after a suspend/resume cycle. Quite annoying, maybe another Kubuntu-specific problem, I'll search for a downstream bug...
Might be Kubuntu-specific, let's see, what happens in Launchpad: https://bugs.launchpad.net/ubuntu/+source/systemsettings/+bug/1474807
Created attachment 93816 [details] Screenshot of keyboard layout applet menu before/after replugging
Doesn't seem Kubuntu specific. I can reproduce it on openSUSE (at least for unplug/replug). I'm running Plasma 5, with these package versions: plasma-framework 5.12.0 plasma5-workspace 5.3.2 Actually, when replugging, the settings seem to change differently for the USB keyboard and for the laptop keyboard. - Before unplugging, I had dual layout setup (br, de) via kcm_keyboard. - When unplugging USB, laptop keyboard settings are kept. - When replugging USB: * layout switching stops working for both keyboards * laptop keyboard keeps whichever layout was selected ('br' or 'de') * USB keyboard falls back to 'us' layout which wasn't configured anywhere * X Server thinks layout is br(basic), which was configured via x.org * 'br - Basic' layout shows up in the keyboard layout applet menu (see attachment); other layouts can't be selected via the menu My error message story follows (I've cleaned up repea: === At the beginning, USB keyboard is plugged and keyboard settings are as intended kcm_keyboard: configuring layouts true configuring options true kcm_keyboard: Fetched layout groups from X server: layouts: ("br", "de") variants: ("", "") kcm_keyboard: Fetched layout groups from X server: layouts: ("br", "de") variants: ("", "") kcm_keyboard: Fetched layout groups from X server: layouts: ("br", "de") variants: ("", "") kcm_keyboard: Fetched layout groups from X server: layouts: ("br", "de") variants: ("", "") === When USB keyboard is unplugged: Found removable storage volume for Baloo undocking: "/org/kde/solid/udev/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.1/0003:045E:0745.003E/input/input76/mouse0" Found removable storage volume for Baloo undocking: "/org/kde/solid/udev/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.1/0003:045E:0745.003E/input/input76/event2" Solid::Backends::UDev::input_str_to_bitmask can't handle some bits ("3f", "3007f", "0", "0", "0", "0", "483ffff", "17aff32d", "bf544446", "0", "0", "1f0001", "130f93", "8b17c000", "677bfa", "d9415fed", "9ed680", "4400", "0", "10000002") Solid::Backends::UDev::input_str_to_bitmask can't handle some bits ("3f", "3007f", "0", "0", "0", "0", "483ffff", "17aff32d", "bf544446", "0", "0", "1f0001", "130f93", "8b17c000", "677bfa", "d9415fed", "9ed680", "4400", "0", "10000002") Found removable storage volume for Baloo undocking: "/org/kde/solid/udev/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.1/0003:045E:0745.003E/input/input76" Solid::Backends::UDev::input_str_to_bitmask can't handle some bits ("3f", "3007f", "0", "0", "0", "0", "4c3ffff", "17aff32d", "bf544456", "0", "c000000", "1", "130f93", "8b17c007", "ffff7bfa", "d951dfff", "febeffdf", "ffefffff", "ffffffff", "fffffffe") Solid::Backends::UDev::input_str_to_bitmask can't handle some bits ("3f", "3007f", "0", "0", "0", "0", "4c3ffff", "17aff32d", "bf544456", "0", "c000000", "1", "130f93", "8b17c007", "ffff7bfa", "d951dfff", "febeffdf", "ffefffff", "ffffffff", "fffffffe") === After replugging (seems to be related to mouse only; actually my USB keyboard is a Microsoft wireless keyboard and mouse dongle) "/org/kde/solid/udev/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.1/0003:045E:0745.0041/input/input79" QObject::connect: Cannot connect (null)::accessibilityChanged(bool,QString) to Baloo::StorageDevices::slotAccessibilityChanged(bool,QString) QObject::connect: invalid null parameter "/org/kde/solid/udev/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.1/0003:045E:0745.0041/input/input79/mouse0" QObject::connect: Cannot connect (null)::accessibilityChanged(bool,QString) to Baloo::StorageDevices::slotAccessibilityChanged(bool,QString) QObject::connect: invalid null parameter "/org/kde/solid/udev/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.1/0003:045E:0745.0041/input/input79/event2" QObject::connect: invalid null parameter QObject::connect: Cannot connect (null)::accessibilityChanged(bool,QString) to Baloo::StorageDevices::slotAccessibilityChanged(bool,QString) === After replugging, upon a keypress on whichever keyboard was least recently used: kcm_keyboard: configuring layouts true configuring options true kcm_keyboard: Fetched layout groups from X server: layouts: ("br") variants: ("basic") kcm_keyboard: Layout map change: "br,de," --> "br(basic)," kcm_keyboard: Layout map change from external source: clearing layout memory kcm_keyboard: Fetched layout groups from X server: layouts: ("br") variants: ("basic") kcm_keyboard: Fetched layout groups from X server: layouts: ("br") variants: ("basic") kcm_keyboard: Fetched layout groups from X server: layouts: ("br") variants: ("basic") == After replugging, when trying to change layout via the applet menu: switchToLayout with unknown layout "de" kcm_keyboard: Fetched layout groups from X server: layouts: ("br") variants: ("basic") switchToLayout with unknown layout "br" kcm_keyboard: Fetched layout groups from X server: layouts: ("br") variants: ("basic") (I also have the symptoms of a related mouse settings bug, https://bugs.kde.org/show_bug.cgi?id=350240)
A (not so convenient) "workaround" for me is to run the following command after resume from suspend, or when connecting a new keyboard: dbus-send --session /Layouts org.kde.keyboard.reloadConfig Found this by checking what I got from dbus-monitor when I click the "Apply" button" of the "Keyboard Hardware and Layout" kde menu, after making a change. Currently trying to find ways to trigger it automatically... I imagine there will be a similar dbus signal to reload mouse config too.
The issue here is that the code that listens to device added events is using xcb-xinput which is disabled by default when building libxcb and so is not available on some distros (eg. Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733227). For 5.4.2, I have pushed a fix https://quickgit.kde.org/?p=plasma-desktop.git&a=commitdiff&h=415c962dea42fba31f9486f55e90630e60bb2bc2 that should help with the issue for systems without xcb-xinput.
I am still experiencing this issue with Plama 5.4.2, in Kubuntu 15.10.
Also seeing it in 5.4.2 Debian Sid.
Correct fix is here: https://git.reviewboard.kde.org/r/125465/
Git commit daa54f5f9ec969edca3943fd7efe662c6e25bb38 by David Rosca. Committed on 18/11/2015 at 21:46. Pushed by drosca into branch 'master'. kcm_keyboard: Use udev device notifier when xcb-xinput is not available XCB-XInput is not available on some distributions, use udev device discovery there instead to reapply settings when adding new keyboard / mouse. FIXED-IN: 5.5.0 REVIEW: 125465 M +7 -0 CMakeLists.txt A +50 -0 cmake/modules/FindUDev.cmake M +16 -17 kcms/keyboard/CMakeLists.txt A +9 -0 kcms/keyboard/config-keyboard.h.cmake M +2 -0 kcms/keyboard/kcm_add_layout_dialog.cpp M +2 -0 kcms/keyboard/kcm_add_layout_dialog.h M +1 -0 kcms/keyboard/kcm_keyboard_widget.h M +6 -4 kcms/keyboard/tests/CMakeLists.txt A +130 -0 kcms/keyboard/udev_helper.cpp [License: GPL (v2+)] C +16 -31 kcms/keyboard/udev_helper.h [from: kcms/keyboard/xinput_helper.h - 053% similarity] M +28 -14 kcms/keyboard/xinput_helper.cpp M +2 -0 kcms/keyboard/xinput_helper.h M +6 -4 kcms/keyboard/xkb_rules.h http://commits.kde.org/plasma-desktop/daa54f5f9ec969edca3943fd7efe662c6e25bb38
*** Bug 353160 has been marked as a duplicate of this bug. ***
*** Bug 356105 has been marked as a duplicate of this bug. ***
I am using Kubuntu 15.10 with Plasma 5.5.3 from backports PPA. This bug is still occurring for me when resuming from sleep intermittently. Replugging is fine. Something must have changed that makes it happen intermittently instead of constantly, but it's still a pain. Shall I submit a different bug? Thanks
(In reply to ayqazi from comment #20) > Shall I submit a different bug? So can you confirm it is fixed with (un)plugging? This is what this bug (and my fix) is about. Please open new bug for reapplying settings after suspend.
As I said, unplugging/plugging works. OK, I shall open another bug. Regards, Asfand Yar Qazi On 9 February 2016 at 12:39, David Rosca via KDE Bugzilla <bugzilla_noreply@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=346336 > > --- Comment #21 from David Rosca <nowrep@gmail.com> --- > (In reply to ayqazi from comment #20) >> Shall I submit a different bug? > > So can you confirm it is fixed with (un)plugging? This is what this bug (and my > fix) is about. > > Please open new bug for reapplying settings after suspend. > > -- > You are receiving this mail because: > You are on the CC list for the bug.