Bug 2013987

Summary:	Key mapping reset on the Buletooth keyboard after reconnecting it
Product:	[Fedora] Fedora	Reporter:	Jun Aruga <jaruga>
Component:	xmodmap	Assignee:	Peter Hutterer <peter.hutterer>
Status:	CLOSED NOTABUG	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	34	CC:	ajax, ofourdan, peter.hutterer
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-10-18 22:55:16 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jun Aruga 2021-10-14 08:30:20 UTC

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"
```

Comment 2 Jun Aruga 2021-10-14 08:43:26 UTC

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.

Comment 3 Jun Aruga 2021-10-14 08:51:20 UTC

> [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.

Comment 4 Jun Aruga 2021-10-14 19:22:20 UTC

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.

Comment 5 Peter Hutterer 2021-10-18 11:16:01 UTC

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

Comment 6 Jun Aruga 2021-10-18 12:56:42 UTC

> 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.

Comment 7 Jun Aruga 2021-10-18 13:09:42 UTC

One more thing, could you tell me the upstream issue ticket URL on X org about this topic if you know it?

Comment 8 Peter Hutterer 2021-10-18 22:55:16 UTC

> 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.