I have personal XKB settings. From my .initrc file: xkbcomp -w0 -I$HOME/.xkb -R$HOME/.xkb keymap/custom $DISPLAY Most often they are lost after suspend/resume on my DELL Latitude E6400 laptop. Moreover when I plug-in a USB keyboard, these settings are not taken into account for this keyboard (the laptop keyboard remains unaffected). After resume, I can run xkbcomp -w0 -I$HOME/.xkb -R$HOME/.xkb keymap/custom $DISPLAY again without quitting the X session, but some running X clients do not take all new settings into account (problem with modifier keys?). I originally reported the bug on: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633849 where you can find additional details.
With my Dell laptop this bug occurred after resume in more than 90% of cases, I have not found a rule for when it occurs and when not. With my new Lenovo laptop, after a few hundred suspend/resume, this bug has never occurred to me. So I suppose this bug is caused by a race condition on some computers only.
I see exactly the same problem. Starting out with a laptop with a built-in keyboard and set the "ctrl:nocaps" option in order to make my Caps Lock key an additional Control, like so: $ setxkbmap -option ctrl:nocaps $ setxkbmap -query rules: evdev model: pc105 layout: no options: ctrl:nocaps $ At this point, the Caps Lock key on the built-in keyboard does indeed act as an additional Control key. All is well. However, the moment I plug in an USB keyboard, the options line vanish: $ setxkbmap -query rules: evdev model: pc105 layout: no $ The Caps Lock key on the built-in keyboard continues to function as an additional Control, but the Caps Lock key on the USB keyboard is not. It is just acting as a regular Caps Lock key. I have to re-issue the "setxkbmap -option ctrl:nocaps" in order for the Caps Lock key on the USB keyboard to become an additional Control. However, if I disconnect and reconnect the USB keyboard, the ctrl:nocaps option is again lost, even though the USB keyboard keeps its old device id (as shown by "xinput list"). The same effect can be seen with a regular layout. If I do, e.g., "setxkbmap us" to get an American layout, it will only apply to keyboard(s) that are connected at that time - future keyboards being plugged in (or disconnected and then reconnected) will default to Norwegian layout. Version information: X.Org X Server 1.18.0 Release Date: 2015-11-09 X Protocol Version 11, Revision 0 Build Operating System: 4.2.5-300.fc23.x86_64 Current Operating System: Linux envy 4.2.6-301.fc23.x86_64 #1 SMP Fri Nov 20 22:22:41 UTC 2015 x86_64 Kernel command line: BOOT_IMAGE=/vmlinuz-4.2.6-301.fc23.x86_64 root=UUID=8cdf3553-0726-4db5-848a-99660d76290b ro rootflags=subvol=root rd.debug vconsole.font=latarcyrheb-sun16 LANG=nb_NO.UTF-8 Build Date: 16 November 2015 10:08:25AM Build ID: xorg-x11-server 1.18.0-2.fc23 Current version of pixman: 0.33.4 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version.
I have similar problem, but related to keyboard layout, not a custom XKB settings. I found the only way to set defaults for a new input device at runtime (without restarting Xorg to pick up modified xorg.conf) is to set xkb* udev properties on a device (for example by adding new rule and reloading udev). More details: https://github.com/QubesOS/qubes-issues/issues/3352#issuecomment-400292279
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.