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
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/266.
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.