xmodmap settings not getting honored when keyboard devices are hotplugged

Bug #287215 reported by Steve Beattie
200
This bug affects 33 people
Affects Status Importance Assigned to Milestone
xorg-server (Ubuntu)
Confirmed
Medium
Unassigned

Bug Description

Binary package hint: xserver-xorg-input-evdev

I use xmodmap to map the caps lock key to the meta key with the following in my ~/.Xmodmap:

  !
  ! - map capslock to meta key
  !
  remove Lock = Caps_Lock
  add Mod3 = Caps_Lock

This works correctly on Intrepid on my lenovo T61's built-in keyboard. When I plug in a USB keyboard, caps lock is not mapped to meta, though it still is mapped that way on the built-in keyboard. If I then re-run xmodmap on my .Xmodmap, caps lock on the USB keyboard gets mapped correctly; however, unplugging and re plugging in the USB keyboard results in its caps lock key being reset to the unmapped state.

This worked correctly on hardy.

Revision history for this message
Steve Beattie (sbeattie) wrote :
Revision history for this message
Steve Beattie (sbeattie) wrote :
Download full text (3.4 KiB)

lspci -nn and lsusb output:

[kryten ~ ]$ lspci -nn
00:00.0 Host bridge [0600]: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub [8086:2a00] (rev 0c)
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a02] (rev 0c)
00:02.1 Display controller [0380]: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller [8086:2a03] (rev 0c)
00:19.0 Ethernet controller [0200]: Intel Corporation 82566MM Gigabit Network Connection [8086:1049] (rev 03)
00:1a.0 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 [8086:2834] (rev 03)
00:1a.1 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 [8086:2835] (rev 03)
00:1a.7 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 [8086:283a] (rev 03)
00:1b.0 Audio device [0403]: Intel Corporation 82801H (ICH8 Family) HD Audio Controller [8086:284b] (rev 03)
00:1c.0 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 [8086:283f] (rev 03)
00:1c.1 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 [8086:2841] (rev 03)
00:1c.2 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 [8086:2843] (rev 03)
00:1c.3 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 [8086:2845] (rev 03)
00:1c.4 PCI bridge [0604]: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 [8086:2847] (rev 03)
00:1d.0 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 [8086:2830] (rev 03)
00:1d.1 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 [8086:2831] (rev 03)
00:1d.2 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 [8086:2832] (rev 03)
00:1d.7 USB Controller [0c03]: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 [8086:2836] (rev 03)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev f3)
00:1f.0 ISA bridge [0601]: Intel Corporation 82801HBM (ICH8M-E) LPC Interface Controller [8086:2811] (rev 03)
00:1f.1 IDE interface [0101]: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller [8086:2850] (rev 03)
00:1f.2 SATA controller [0106]: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller [8086:2829] (rev 03)
00:1f.3 SMBus [0c05]: Intel Corporation 82801H (ICH8 Family) SMBus Controller [8086:283e] (rev 03)
03:00.0 Network controller [0280]: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection [8086:4227] (rev 02)
15:00.0 CardBus bridge [0607]: Ricoh Co Ltd RL5c476 II [1180:0476] (rev b6)
[kryten ~ ]$ lsusb
Bus 007 Device 013: ID 045e:008c Microsoft Corp. Wireless Intellimouse Explorer 2.0
Bus 007 Device 012: ID 045e:00db Microsoft Corp. Natural Ergonomic Keyboard 4000 V1.0
Bus 007 Device 011: ID 05e3:0606 Genesys Logic, Inc. USB 2.0 Hub / D-Link DUB-H4 USB 2.0 Hub
Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 003: ID 1058:0701 Western Digital Technologies, Inc.
Bus 003 Device 001: ID ...

Read more...

Revision history for this message
Steve Beattie (sbeattie) wrote :

Changing likely package affected to xkeyboard-config based on discussion with Bryce.

Revision history for this message
MasterZ (arnaud-delcroix) wrote :

I have the same problem on my laptop ACER 1705 trying to map the unrecognized media keys.

I tried to map 2 keys to 'F21' and 'F22' using xmodmap.
This works ok and 'xev' confirm that.

Then I am able to map those keys in 'Preferences/Keyoard_Shortcuts' or in compiz 'ccsm'.
Everything works until I restart X or reboot.
(I tried running the xmodmap association script in the session startup; in gdm/Init; in gdm/Postlogin; in gdm/Presession)

After X_restart or reboot, the keys are still correctly recognised by 'xev' but the shortcut associations do not work anymore.

Looking in 'Preferences/Keyoard_Shortcuts' the mapping is still there, but it seems to be ignored.
I have to disable the mapping,then set it back to 'F21' manually. After that, the shortcut works again.

This bug might be related to Bug #289781.

Revision history for this message
Tomas 'tt' Krag (tt) wrote :

I can confirm this behaviour on a thinkpad x40. the .Xmodmap is applied on boot, but plugging in a USB keyboard (in this case an IBM W20-06) the settings don't get applied to the hotplugged keyboard (but remain applied on the built-in keyboard).

Running xmodmap ~/.Xmodmap solves that issue, but only until suspend/resume or replugging the keyboard at which point i need to run the command again.

Revision history for this message
psanford (pms-mail) wrote :

I've seen the same behavior. The interesting thing is that If I have keyboard A attached, and then connect keyboard B, A keeps its xmodmap, while B doesn't get the xmodmap.

Does this mean it would be possible for two keyboards to be using different xmodmaps?

Revision history for this message
Trochee (trochee) wrote :

I have the same experience (that System|Preferences|Keyboard -> Layouts ->Other Options... configurations do not apply to hotplugged keyboards).

I am not 100% sure that this is the same as .xmodmap files not applying, but it has been one of the virtues of Ubuntu for me that I can configure my desktop experience with the pointy-clicky rather than learning YADF (yet another dot file).

I agree, from reading the descriptions, that this bug might be related to Bug #289781.

Revision history for this message
Matthias Himber (nomar) wrote :

Confirming this bug on a Thinkpad T500. The internal keyboard keeps its settings, but external ones loose them whenever plugged in or after suspend.

Revision history for this message
Steve Beattie (sbeattie) wrote :

This bug was reported in the Intrepid development cycle; removing regression-potential and marking as regression-release.

Revision history for this message
Bryce Harrington (bryce) wrote :

Hmm, I'm suspecting this may rather be an xserver-xorg-input-evdev issue since it seems to involve hotplugging. Refiling.

Revision history for this message
Bryce Harrington (bryce) wrote :

Hi sbeattie,

Please attach the output of `lspci -vvnn` too.

[This is an automated message. If this script has reached you erroneously, please accept our apologies; any reply to this message will be sufficient to prevent it from doing further automated processing.]

Changed in xserver-xorg-input-evdev:
status: New → Incomplete
Revision history for this message
dukat (dukat) wrote :

I've come across the same problem with a Logitech diNovo Desktop running in HID proxy mode. My cable keyboard keeps all xmodmap settings, while the wireless keyboards don't after they get online again.

I'm attaching the missing output to have some progress here.

Revision history for this message
dukat (dukat) wrote :
Revision history for this message
dukat (dukat) wrote :
Changed in xserver-xorg-input-evdev:
status: Incomplete → Confirmed
Bryce Harrington (bryce)
Changed in xserver-xorg-input-evdev:
importance: Undecided → Medium
status: Confirmed → Triaged
Revision history for this message
Thomas Albright (thomas-albright) wrote :

I have a similar problem with Intrepid, on my Lenovo Y410. Initially, when I plug in a USB keyboard, the xmodmap settings continue to work. But after a few minutes, they stop working on the USB keyboard, while continuing to work on the main laptop keyboard. If I run xmodmap again, it works on my USB keyboard for another few minutes, and then stops working again.

Revision history for this message
Thomas Albright (thomas-albright) wrote :

After further investigation, my problem is definitely related to this bug. I was mistaken that xmodmap works with the USB keyboard initially, it does not work. Xorg.0.log is indicating that every few minutes, the USB keyboard is reloaded, because of a Read Error. That is why I lose my xmodmap settings every few minutes.

Revision history for this message
Thomas Albright (thomas-albright) wrote :

With a Logitech Classic Keyboard 200, I do not experience this bug. Xmodmap settings immediately work when I connect the keyboard. However, with an Ativa 611460 Keyboard, I do experience the bug.

Revision history for this message
John Stultz (jstultz) wrote :

Seeing this as well, but with my desktop. If I unplug and replug the keyboard my caps-as-a-ctrl setting seems to be lost, despite it being set when I look at keyboard preferences. Unsetting and re-setting the preference returns the functionality.

Revision history for this message
Nikolaus Rath (nikratio) wrote :

JFTR: It seems to me that this bug is related to bug #295990. It's not a duplicate though, one deals with XKB and the other with xmodmap. But maybe a similar fix can be used in both cases.

Revision history for this message
Trochee (trochee) wrote :

This behavior is still here for me after upgrading to Jaunty.

Revision history for this message
Brian Thomas (bjtaccount) wrote :

I can confirm this behavior is present in Jaunty on a Macbook Pro 1,2. The internal keyboard remembers its state, but external ones will lose any mappings upon unplugging and replugging.

Revision history for this message
mishoo (mihai-bazon) wrote :

Confirming behavior in Jaunty on a ThinkPad T60p. I'm using a bluetooth keyboard that periodically forgets my .xmodmap settings, as well as keyboard delay and repeat rate (which are configured from the Gnome menus). Very annoying.

Revision history for this message
Nelson Elhage (nelhage) wrote :

Confirm with Jaunty on a ThinkPad T60. Happens with every different USB keyboard I've tried.

Revision history for this message
Ulrich (ulrich-leopold-gmail) wrote :

So does anyone have a current workaround for this problem. Bug still here Jaunty x86_64. every few minutes USB keyboard layout chnages to default. It makes it completely unuseable. Am not able anymore to do my daily work properly due to this. Keyboard has to be disconnected from Laptop quite frequently during the day. Hence, a work around would be appriciated.

Bryce Harrington (bryce)
tags: added: intrepid
Revision history for this message
Thomas Perl (thp) wrote :

Still an issue for me in Karmic with a USB keyboard.

Revision history for this message
John Leach (johnleach) wrote :

Same for me on Karmic with my TopSeed Tech Corp. USB IR Combo Device. Fine if the IR receiver is plugged in when I log in, but if I plug in and out it loses my modifications.

Revision history for this message
Thomas Albright (thomas-albright) wrote :

After many hours, I found a workaround for this problem.

The first workaround I tried was adding a rule to /etc/udev/rules.d/ to run xmodmap automatically when the keyboard is plugged in. This works, but not on a consistent basis. It seems to depend on the timing of when the keyboard is actually registered by the system. Sometimes, xmodmap is run before the keyboard is actually registered, so the changes are not effective.

Here is the workaround: Instead of using xmodmap, use xkb. I believe xkb is being run when the USB keyboard is plugged in, and running xkb erases the xmodmap settings. So rather than fight it trying to use xmodmap, just use xkb. It was a little tricky to figure it out, but it only took an hour. My key settings now stay consistent when I plug in a USB keyboard.

Revision history for this message
Bryce Harrington (bryce) wrote :

[This is an automatic notification.]

Hi Steve,

This bug was reported against an earlier version of Ubuntu, can you
test if it still occurs on Lucid?

Please note we also provide technical support for older versions of
Ubuntu, but not in the bug tracker. Instead, to raise the issue through
normal support channels, please see:

    http://www.ubuntu.com/support

If you are the original reporter and can still reproduce the issue on
Lucid, please run the following command to refresh the report:

  apport-collect 287215

If you are not the original reporter, please file a new bug report, so
we can work with you as the original reporter instead (you can reference
bug 287215 in your report if you think it may be related):

  ubuntu-bug xorg

If by chance you can no longer reproduce the issue on Lucid or if you
feel it is no longer relevant, please mark the bug report 'Fix Released'
or 'Invalid' as appropriate, at the following URL:

  https://bugs.launchpad.net/ubuntu/+bug/287215

Changed in xserver-xorg-input-evdev (Ubuntu):
status: Triaged → Incomplete
tags: added: needs-retested-on-lucid-by-june
Revision history for this message
Steve Beattie (sbeattie) wrote :

I can confirm that indeed the problem still exists on lucid. If you *really* want all of the apport-collect spam, I can generate it for you, but I don't believe it's relevant for this bug.

Changed in xserver-xorg-input-evdev (Ubuntu):
status: Incomplete → Confirmed
tags: added: lucid
removed: needs-retested-on-lucid-by-june
tags: added: jaunty karmic
Revision history for this message
Timo Aaltonen (tjaalton) wrote :

moving to the server, since the hotplug logic is there, and it probably should apply/inherit these settings from the first device.

affects: xserver-xorg-input-evdev (Ubuntu) → xorg-server (Ubuntu)
Revision history for this message
John Stultz (jstultz) wrote :

The issue is resolved for me in Lucid. My caps-as-ctrl config persists over a USB keyboard hotplug.

Bryce Harrington (bryce)
tags: added: hardy
Revision history for this message
Cay Horstmann (cay) wrote :

I am running into this issue with Lucid as well. External logitech keyboard. When the laptop wakes up, the Xmodmap settings are lost.

Revision history for this message
Tomas 'tt' Krag (tt) wrote :

I can confirm that this problem still exists for me using a Logitech DiNovo Keyboard on a Thinkpad T410s running 32bit Ubuntu Maverick

Revision history for this message
Jacobo de Vera (jdevera) wrote :

This problem persists in 12.04

Revision history for this message
Evan Driscoll (evaned) wrote :

Broken here with x64 12.04 too. It's *extremely* annoying as I have a cheap KVM switch between two computers and every time I switch, I have a broken xmodmap.

Thomas Albright, if you're still reading this, I don't suppose you can post more information on your workaround so that everyone else who runs into this doesn't have to go through an hour of figuring out what to do.

Revision history for this message
Andreas van Cranenburgh (andreas) wrote :

@evaned this command makes capslock a super modifier (aka windows key):

setxkbmap -option caps:super

See the file /usr/share/X11/xkb/symbols/capslock for other possible options.

Revision history for this message
Micah Cowan (micahcowan) wrote :

Continues to be a problem under 13.04. Running Xubuntu.

(Looked into using xkb, but oddly while it offers the option I desire, to set "capslock as an extra escape", it does not appear that it offers the option to set "escape as an extra capslock"; at least, not that I found documented in xkeyboard-config(7).)

Revision history for this message
Trey Hunner (treyhunner) wrote :

I am also experiencing this problem on Ubuntu 13.04. My workaround was to modify the keycodes in /usr/share/X11/xkb/keycodes/evdev directly.

Revision history for this message
Florian Klien (flowolf) wrote :

I can confirm this bug is still existing in 13.10 Ubuntu.

Used Xmodmap to remap alt and super keys on an Apple Keyboard. This is connected to my computer through the USB hub on my display. Whenever the display is turned off Ubuntu forgets about the Xmodmap settings.

Revision history for this message
Martin Pohlack (mp26+launch) wrote :

Still a problem with trusty 14.04. I use a usb switch to multiplex input devices between different machines and each time that I switch, I use all my custom settings are lost:

    setxkbmap -layout de -model pc105 -variant "nodeadkeys" -option "ctrl:nocaps,compose:menu"
    xkbset sticky -twokey latchlock

Revision history for this message
jzacsh (jzacsh) wrote :

Can someone suggest how to fix this properly? I'm happy spend the time understanding some code and sending a patch.

My reproduction:
- my ~/.xprofile has the following line which turns caps into a Control_L key: `xmodmap ~/.Xmodmap`[1]
- I have a bluetooth keyboard for my 14.04LTS ubuntu machine
- when I walk away from the machine, I turn off my keyboard (to preserve battery/charge)
- when I come back and unlock my screen, my config is reset (ignoring my previous `xmodmap` calls)

Also, wow(!), the 7th anniversary of this bug is coming up :)

[1]: https://github.com/jzacsh/dotfiles/blob/411572a68ead36ab240bad9e6a550188f19023d1/.config/xmodmaprc#L15-L17

Revision history for this message
Julian Andrews (jandrews271) wrote :

I'm not running Ubuntu anymore, but I can confirm that this is a problem in Debian Stretch (and was an issue in Debian Jessie). I see similar behavior for keyboard rates set via `xset r rate`. Plugging in the USB keyboard resets the keyboard settings. Suspending while a USB keyboard is plugged in also resets the keyboard settings, though suspending without a USB keyboard attached doesn't. I suspect that whatever logic executes on plugging in the keyboard is also run on resume.

For anyone looking for a workaround for mapping caps lock to escape, setting `XKBOPTIONS="caps:escape"` in `/etc/default/keyboard` (and rebooting) will do that reliably. That should work for anything that can be configured via `XKBOPTIONS`. As for the rate issue, I don't yet have a good workaround. I suspect a udev rule might do what I need, but that's also clearly a hack, so it would be nice to have a fix for this.

Revision history for this message
Julian Andrews (jandrews271) wrote :

I've been doing a little more investigating. I'm pretty sure this issue is this:

https://bugs.freedesktop.org/show_bug.cgi?id=25262

So, if I understand this correctly, this won't/can't be fixed in X and has to be handled by your desktop environment.

It does seem to me that there probably is a way to set the default rates/keymaps. If anyone knows what the canonical way to do that is, I'd love to know!

Revision history for this message
Julian Andrews (jandrews271) wrote :

One last comment. For those not using a standard DE, most solutions don't work well, but running `X` with the `-arinterval` and `-ardelay` flags will solve the repeat issue.

Revision history for this message
mgsloan (mgsloan) wrote :

If your xmodmap settings are idempotent, then an awful yet effective solution to this is to use inotifywait to detect additions to /dev/input, and rerun xmodmap when this occurs.

Here's a script: https://github.com/mgsloan/mgsloan-dotfiles/blob/5efd7becaa173f2b6500aad0cc3f3724ebe22783/env/scripts/xmodmap-on-input-change.sh

Revision history for this message
Thomas Habets (p-thomas-8) wrote :

mgsloan: That's pretty awful indeed, because applying these keyboard settings locks up all keyboard input for multiple seconds. (depending on how many settings you need to apply)

Do I read https://bugs.freedesktop.org/show_bug.cgi?id=25262 right when I say that this is saying that Xorg does not support ANY settings OF ANY KIND done by the user, and that it's somehow working as intended that the user's preferences are wiped whenever Xorg feels like it?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.