Bug 71168 - XKB settings lost after suspend/resume / not taken into account for new keyboard
Summary: XKB settings lost after suspend/resume / not taken into account for new keyboard
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/Input/XKB (show other bugs)
Version: git
Hardware: Other All
: medium major
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
Depends on:
Reported: 2013-11-02 17:06 UTC by Vincent Lefevre
Modified: 2018-12-13 18:37 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Description Vincent Lefevre 2013-11-02 17:06:25 UTC
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:


where you can find additional details.
Comment 1 Eugen Dedu 2015-08-04 10:28:34 UTC
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.
Comment 2 Tore Anderson 2015-12-08 17:50:23 UTC
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.
Comment 3 marmarek 2018-06-26 12:43:15 UTC
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
Comment 4 GitLab Migration User 2018-12-13 18:37:09 UTC
-- 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.