I have an .Xmodmap file with several years of unicode shortcuts and remappings that I've gotten used to over the years. Gnome used to load this — it would pop up a one-time dialog box asking what to do if the file was found. In Gnome 3.6, it is ignored. And, if I run xmodmap by hand, the settings are forgotten after every suspend/resume.
I can confirm that .Xmodmap is no longer loaded.
i'm using fedora 17 and i3 wm and /etc/X11/Xmodmap is not loaded
/etc/X11/Xmodmap isn't being loaded under fedora-18 either.
There is another problem is that if you type xmodmap .Xmodmap manually,It loaded.But it become invalid when you switch to next input method.I'm using the ibus.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
This also happens on Fedora 18.
This seems to be an intended upstream change: don't read .xmodmap files by default: https://bugzilla.gnome.org/show_bug.cgi?id=674874 Comment_2 in the above bug, states that we can now execute a "hotplug" script for keyboards. Here's the upstream commit https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=a90f42b0cd0d235f72f24ef4a59ff422351ecdda I cobbled a script based on http://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/common/input-device-example.sh to do that: ============================================= #!/bin/sh args=`getopt "t:i:" $*` set -- $args while [ $# -gt 0 ] do case $1 in -t) shift; type="$1" ;; -i) shift; id="$1" ;; --) shift; device="$@" break; ;; *) echo "Unknown option $1"; exit 1 ;; esac shift done if [ "$device" = "Microsoft Microsoft® 2.4GHz Transceiver v7.0" ]; then if [ "$type" = "present" -o "$type" = "added" ]; then /usr/bin/xmodmap ~/.xmodmap-local fi fi ============================================= then I set org.gnome.settings-daemon.peripherals.input-devices hotplug-command to /path/to/executable-script.sh, and here are the results: - This does get executed at login, but the changes aren't there after login completes, sticking a 'setxkbmap -print' in the script I get: xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+us+gb:2+inet(evdev)" }; xkb_geometry { include "pc(pc104)" }; }; executing 'setxkmap -print' manually a bit later I get: xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+us+inet(evdev)+capslock(none)+compose(menu)+terminate(ctrl_alt_bksp)" }; xkb_geometry { include "pc(pc104)" }; }; so it looks like at the time the script is executed gnome-settings-daemon(?) hasn't applied the setxkmap options from the user's settings yet. AFAIK, if I run xmodmap, then change something via setxkmap all the xmodmap changes are reset. Adding an entry in gnome-session-properties to run xmodmap seems to work fine. - This script does work after resuming from suspend, so xmodmap changes are reapplied. - Changing the keyboard layout resets the xmodmap changes (in contradiction to what https://bugzilla.gnome.org/show_bug.cgi?id=688906 says). I think the component should be changed to gnome-settings-daemon.
Forgot to add that I used this blog post http://who-t.blogspot.com/2011/03/custom-input-device-configuration-in.html to get that hotplug script working at all.
This bug also occurs when I use gnome-session-properties to add a startup program 'xmodmap .xmodmaprc'. My .xmodmaprc is pretty simple: remove Lock = Caps_Lock keysym Caps_Lock = Control_L add Control = Control_L because all I want to do is to have Caps Lock be an alias for Ctrl. This used to be easy in Gnome, now it's impossible, and this is frustrating.
(In reply to Paul Eggert from comment #9) > This bug also occurs when I use gnome-session-properties to add a startup > program 'xmodmap .xmodmaprc'. My .xmodmaprc is pretty simple: > > remove Lock = Caps_Lock > keysym Caps_Lock = Control_L > add Control = Control_L > > because all I want to do is to have Caps Lock be an alias for Ctrl. This > used to be easy in Gnome, now it's impossible, and this is frustrating. Off-topic: open gnome-tweak-tool -> Typing, you can change the Caps Lock key behaviour from there.
(As per comment #7)
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
This bug is even worse with Fedora 23 as the xmodmap settings seem to be lost each time the screen locks.
I think this is probably a lost cause with Wayland. What's really needed is a dead-simply Xmodmap to XKB translator.
Okay, here's a test input: keycode 22 = BackSpace keycode 66 = Control_L keycode 64 = Meta_L keycode 37 = Alt_L keycode 133 = Hyper_L keycode 134 = Super_L keycode 135 = Caps_Lock keycode 105 = Super_R keycode 108 = Hyper_R clear Lock clear Control clear Mod1 clear Mod3 clear Mod4 clear Mod5 add Lock = Caps_Lock add Control = Control_L Control_R add Mod1 = Meta_L add Mod3 = Alt_L add Mod4 = Hyper_L Hyper_R add Mod5 = Super_R Super_L Those keycodes are for a daskeyboard ultimate, but what I need would be a method to get something working for any keyboard. As far as I can tell, I can't achieve the same result in XKB without defining my own layout, the documentation for which (http://www.x.org/releases/current/doc/xorg-docs/input/XKB-Enhancing.html, as far as I can tell) starts with: "The developer of a new layout should read the xkb protocol specification".
I see the same problem in Centos 7. I am able to add a script to the startup applications to run xmodmap. I found it necessary to add a delay, otherwise the settings somehow get lost. So this script works for me: #!/bin/sh sh -c "sleep 10; xmodmap .Xmodmap" </dev/null >/dev/null 2>&1 & Unfortunately, if I close the lid to suspend the laptop, the xmodmap settings are gone when I resume. Very frustrating. I am forced to use Xfce because of this issue.
would it be possible to have a gnome-tweak-tool option to enable .Xmodmap if the user requests it? That way whoever really wants to use .Xmodmap would be able to do so. Everybody else doesn't care and does not get bothered.
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
Try this: Go to your keyboard settings (in my case xfce4-keyboard-settings), click on "Layout" tab, uncheck "Use system defaults", close and restart your X. This worked for me in f23 with: 1. "~/.Xmodmap" file with my settings. 2. "~/.xinitrc" file with: "/usr/bin/xmodmap ~/.Xmodmap" in it.
As requested in comment 17.
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
This is still a problem for me in Fedora 25. I tried the suggestions in comment #19, and they do not solve the issue for me.
Bringing this forward to rawhide. I am pretty sure this is never going to be addressed, unfortunately, and it's probably time to migrate configurations to xkb.
Sigh. As you said above in comment #14, this would be fine if there were a simple way to translate Xmodmap configurations to xkb. Is there a HOWTO for this?
What I've been doing for a couple of years now is remapping the buttons using udev/hwdb; have a look at /usr/lib/udev/hwdb.d/60-keyboard.hwdb. Using a file like this: $ cat /etc/udev/hwdb.d/70-keyboards.hwdb evdev:input:b*v045Ep0745* KEYBOARD_KEY_70049=sysrq KEYBOARD_KEY_70062=0 KEYBOARD_KEY_70059=1 KEYBOARD_KEY_7005a=2 KEYBOARD_KEY_7005b=3 KEYBOARD_KEY_7005c=4 KEYBOARD_KEY_7005d=5 KEYBOARD_KEY_7005e=6 KEYBOARD_KEY_7005f=7 KEYBOARD_KEY_70060=8 KEYBOARD_KEY_70061=9 KEYBOARD_KEY_70063=dot KEYBOARD_KEY_70039=f15 KEYBOARD_KEY_70047=f14 this works always works, in X, in console and across reboots/suspend cycles. Note that this is suitable for me because I am the only user on this machine.
The hwdb approach works if your goal is to move keys around or to make a key act as a different one. It's not so great if you want to make AltGR-h give you 🌭 or something like that.
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle. Changing version to '27'.
(In reply to Andrew J. Schorr from comment #25) > Sigh. As you said above in comment #14, this would be fine if there were a > simple way to translate Xmodmap configurations to xkb. Is there a HOWTO for > this? Starting with the attachment to this message: https://lists.debian.org/debian-x/2012/09/msg00274.html I figured out a fairly simple way: 1) Generate the "xkb_result_pristine" file as prescribed. 2) Apply your .Xmodmap file 3) Generate another "xkb_result_modified" file. 4) Diff them to figure out what to put in ".xkb/symbols/xmodmap_replace"
(In reply to John Lindal from comment #29) > I figured out a fairly simple way: This would make a good Fedora Magazine article — interested in writing it?
Sure, sounds like fun. How do I submit it?
See https://fedoramagazine.org/write-for-the-fedora-magazine/ for instructions. Let me know if you need anything further.
This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.