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
Status: NEW
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
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-11-02 17:06 UTC by Vincent Lefevre
Modified: 2016-08-30 02:07 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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:

  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633849

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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.