Hide Forgot
Description of problem: The changes by xmodmap and setxkbmap are reset on my Bluetooth keyboard after reconnecting it. I am using the i3 window manager on Fedora 34. Version-Release number of selected component (if applicable): I am not sure which component causes this issue. So I list up the possible components with versions. Feel free to change the component to the proper one. ``` $ cat /etc/fedora-release Fedora release 34 (Thirty Four) $ uname -r 5.14.10-200.fc34.x86_64 $ rpm -qf /usr/libexec/gdm-x-session gdm-40.1-1.fc34.x86_64 $ rpm -qf /bin/bluetoothctl bluez-5.61-1.fc34.x86_64 $ rpm -qf /bin/xmodmap xmodmap-1.0.10-1.fc34.x86_64 $ rpm -qf /bin/setxkbmap setxkbmap-1.3.2-3.fc34.x86_64 $ rpm -q libinput libinput-1.18.1-1.fc34.x86_64 ``` How reproducible: Steps to Reproduce: The example is to change the Caps_Look key into "a". 1. There is a keyboard on the laptop: Lenovo X1 Carbon. Connect a bluetooth keyboard. Here is my bluetooth setting. Masking the MAC address for privacy. ``` $ sudo bluetoothctl Agent registered [CHG] Controller XX:XX:XX:XX:XX:C8 Pairable: yes [bluetooth]# devices Device XX:XX:XX:XX:XX:C8 Trust Bluetooth Keyboard ``` 2. See the current setting on Caps_Lock. ``` $ xmodmap -pke | grep Caps keycode 66 = Caps_Lock NoSymbol Caps_Lock ``` 3. Change the setting. ``` $ xmodmap -e "remove Lock = Caps_Lock" $ xmodmap -e "keycode 66 = a" ``` Now both the keyboard on the laptop and the bluetooth keyboard can type the "a" by clicking Caps Lock key. 4. Reconnect the bluetooth keyboard. ``` $ sudo bluetoothctl [Trust Bluetooth Keyboard]# devices Device XX:XX:XX:XX:XX:E2 Trust Bluetooth Keyboard [Trust Bluetooth Keyboard]# disconnect XX:XX:XX:XX:XX:E2 Attempting to disconnect from XX:XX:XX:XX:XX:E2 [CHG] Device XX:XX:XX:XX:XX:E2 ServicesResolved: no Successful disconnected [CHG] Device XX:XX:XX:XX:XX:E2 Connected: no [bluetooth]# connect XX:XX:XX:XX:XX:E2 Attempting to connect to XX:XX:XX:XX:XX:E2 [bluetooth]# quit ``` 5. Click the Caps Lock key again on the keyboard on the laptop again. The "a" is printed. The "CapsLock" key's light is not enabled, not entering CapsLock mode. 5. Click the Caps Lock key again on the bluetooth laptop again. Actual results: The "a" is printed. The laptop keyboard's "CapsLock" key's light is enabled entering CapsLock mode. Expected results: The "a" is printed. Additional info: This issue might be related to https://bugzilla.redhat.com/show_bug.cgi?id=1896177 . I also reported it to Ask Fedora https://ask.fedoraproject.org/t/bluetooth-keyboard-compose-key-stopped-working-after-few-minutes/10322/9?u=jaruga . Just note if you want to reset the xmodmap setting, restart the X or ``` $ xmodmap -e "keycode 66 = Caps_Lock" $ xmodmap -e "add Lock = Caps_Lock" ```
Sorry for my typo. The correct one is > Actual results: > > The "a" is printed. The laptop keyboard's "CapsLock" key's light is enabled entering CapsLock mode. The "a" is "not" printed on the Bluetooth keyboard. The laptop keyboard's "CapsLock" key's light is enabled entering CapsLock mode.
> [bluetooth]# devices > Device XX:XX:XX:XX:XX:C8 Trust Bluetooth Keyboard > [Trust Bluetooth Keyboard]# devices > Device XX:XX:XX:XX:XX:E2 Trust Bluetooth Keyboard Sorry. One more typo. There are 2 kind of masked MAC address. But it's actually on same MAC address. I mistook how to mask the MAC address.
I was able to keep changing the key mapping that I want by editing the following file for the bluetooth keyboard even after reconnecting it. ``` $ cat /etc/X11/xorg.conf.d/00-keyboard.conf Section "InputClass" Identifier "system-keyboard" MatchIsKeyboard "on" Option "XkbLayout" "us" Option "XkbVariant" "," Option "XkbOptions" "caps:escape,altwin:ctrl_rwin" EndSection ``` It seems we can change the key mapping by editing or adding the following files if it is needed. /usr/share/X11/xkb/rules/evdev /usr/share/X11/xkb/symbols/<file> However I am still not sure if the behavior of the xmodmap (and .Xmodemap) and setxkbmap commands is a bug or intentional.
When was the last time this actually worked? xmodmap/setxkbmap are once-off tools and aren't hotplug-capable (unless you manually run them after device plug), any new device just comes up with the static configuration. This has been the case since server 1.7 or so (Fedora 8, iirc). See e.g. my post from 2010: https://who-t.blogspot.com/2010/06/keyboard-configuration-its-complicated.html
> When was the last time this actually worked? xmodmap/setxkbmap are once-off tools and aren't hotplug-capable (unless you manually run them after device plug), any new device just comes up with the static configuration. This has been the case since server 1.7 or so (Fedora 8, iirc). See e.g. my post from 2010: https://who-t.blogspot.com/2010/06/keyboard-configuration-its-complicated.html Thanks for your reply. I have never seen the xmodmap/setxkbmap works with a bluetooth keyboard. This time I tried the bluetooth keyboard at first time. > The fix for all this is simple: make the session handle all keyboards, existing and hotplugged ones, and let it update the config accordingly. Whenever you're using a tool like xmodmap it is your responsibility to reapply the config after changing keyboards. Which brings me back to the article above - it curiously didn't mention that. So I strongly recommend that instead of configuring your keyboard with xmodmap you spend your time helping your favourite desktop environment to provide tools to cover your use-case. OK I did read your blog now. It's very informative with the context of this topic. So, I might find the tool that works on i3 window manager that I am using. > Exiro: no-one stops you from using xmodmap. you'll just have to re-run it all the time, since xmodmap does one thing, and one thing well. but only one thing... Or like someone's comment on the blog, running the xmodmap (e.g. `xmodmap ~/.Xmodemap`) manually again is one option. OK. So, I am fine to close this ticket. Thanks.
One more thing, could you tell me the upstream issue ticket URL on X org about this topic if you know it?
> Or like someone's comment on the blog, running the xmodmap (e.g. `xmodmap ~/.Xmodemap`) manually again is one option. fwiw, this is basically what gnome, kde and other desktop environments are doing. they listen to device notifications and then apply the configured keymaps accordingly. So automating this is possible, all the data you need is sent out and let's assume somewhen in the last 10 years someone has written a tool for that - you just have to find it :) > could you tell me the upstream issue ticket URL on X org about this topic if you know it? no idea tbh and if there was one we'd have closed it wontfix years ago. xmodmap still works exactly like it used to do before, it's just that everything else has moved around enough that it's no longer having the same effect.