Bluetooth Keyboard: Compose Key stopped working after few minutes

Hi all,

i’m new to this one, registration process with oauth2 was frustrating, but i get finally there. as you may noted, English is not my native language.

But anyway, i have a little issue with my new fedora 33 Installation on my Lenovo T590 running Gnome 3.38.1 on X11: I’m using a MX Master 3 Keyboard by Logitech (german layout) I’ve enabled Compose key with the tweaking tool mapped to right control. After Login, the key works a few minutes, but after that time it behaves like Right CTRL again.

There is no issue at all, if i’m using the unify receiver.

Any help would be greatly appreciated.

Thanks in advance

2 Likes

This seems to be a likely bluetooth issue. I have a logitech bluetooth keyboard that I reverted back to using the unifying receiver because of certain instabilities in the way it worked. I can’t help with the fix, but you are not the only one to have problems with bluetooth keyboards.

2 Likes

I confirm similar behavior with my Logitech k810 bluetooth keyboard.

Specifically, my compose key binding gets lost in the following scenarios:

  • suspend and wake the computer
  • switch the keyboard power off and back on

My laptop’s builtin keyboard is not affected by this problem; only the bluetooth keyboard is affected.

Workaround #1 (X only, not Wayland):

Alt+F2 r

Workaround #2

#!/bin/bash
save=$(gsettings get org.gnome.desktop.input-sources xkb-options)
gsettings set org.gnome.desktop.input-sources xkb-options "[]"
gsettings set org.gnome.desktop.input-sources xkb-options "$save"

Put that in a file on your path and mark it executable. I named mine fbk for fix bluetooth keyboard. Then I do:

Alt+F2 fbk

I tried creating a udev rule to execute it automatically when my bluetooth keyboard gets connected, but that didn’t work because udev rules are executed by root not the user logged into the graphical session.

(If anyone knows how to fix this with a udev rule, please let me know.)

Bug filed: https://bugzilla.redhat.com/show_bug.cgi?id=1897877

hmmm, the keyboard itself gets into standby mode after one or two minutes of inactivity. If you use the unify receiver, the keyboard is virtually still connected, even if the keyboard isn’t turned on. That’s why the compose key is still working. But if you remove the USB Keyboard and plug it back in, it’s the same. So it seems that this has nothing to do with bluez, as you mentioned in your Bug report.

i think, it has something to do with gdm-x-session, as you can see in the logfile, it only sets the language, but no other options:

16 07:45:27 cprlpf26j8hg /usr/libexec/gdm-x-session[2033]: (II) libinput: Logitech MX Keys: is a virtual subdevice
Nov 16 07:45:27 cprlpf26j8hg /usr/libexec/gdm-x-session[2033]: (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:14.0/usb1/1-4/1-4:1.2/0003:046D:C52B.0025/0003:046D:408A.0027/input/input62/event21"
Nov 16 07:45:27 cprlpf26j8hg /usr/libexec/gdm-x-session[2033]: (II) XINPUT: Adding extended input device "Logitech MX Keys" (type: KEYBOARD, id 20)
Nov 16 07:45:27 cprlpf26j8hg /usr/libexec/gdm-x-session[2033]: (**) Option "xkb_layout" "de"

I fixed it for my case with:

❯ sudo localectl set-x11-keymap us "" "" lv3:ralt_switch,compose:ralt

which is reflected in:

❯ cat /etc/X11/xorg.conf.d/00-keyboard.conf
# Written by systemd-localed(8), read by systemd-localed and Xorg. It's
# probably wise not to edit this file manually. Use localectl(1) to
# instruct systemd-localed to update it.
Section "InputClass"
        Identifier "system-keyboard"
        MatchIsKeyboard "on"
        Option "XkbLayout" "us"
        Option "XkbOptions" "lv3:ralt_switch,compose:ralt"
EndSection

and

❯ localectl status
   System Locale: LANG=en_US.UTF-8
       VC Keymap: us
      X11 Layout: us
     X11 Options: lv3:ralt_switch,compose:ralt

After a reboot, the binding of Right Alt to my compose key is persistent if I power-cycle my bluetooth keyboard. Tested on Fedora 32 (both X and Wayland).

Does something similar to that work for your keyboard?

Similar reports:

Debian bug report 763609: gnome-shell: keyboard layout switching ignored after unplug/plug USB keyboard

Layout switch when bluetooth keyboard unsleeps | Arch Linux Forums

Hi @robin217, thaks for this one.

Today, it stopped working on all Keyboards including the internal one. So i’ll try your fix ASAP. It looks promising.

it doesn’t fix my issue at all. sometimes it works, sometimes not…

and an additional issue has received my Notebook. With the latest Kernel (5.9.8) i can’t reconnect any Bluetooth devices. But it looks like this is a well-known issue.

Edit:
It looks like it takes a couple of seconds after login. i Started chromium, and it doesn’t work here. A few moments later, i tried it in textedit and it works. Switching back to chromium: Doesn’t work. I’ve closed chromium and restart it: it works™. i’ll watch at this in the next days…

Edit2:
Today i’ve had no luck, Bluetooth keyboard compose isn’t working , but USB Mode seems to work.

I also confirmed my Bluetooth keyboard’s change by the setxkbmap and xmodmap is reset after disconnect and connect

I am using Fedora 34.

$ cat /etc/fedora-release 
Fedora release 34 (Thirty Four)

My kernel version is

$ uname -r
5.13.19-200.fc34.x86_64

And other tools versions are

$ rpm -qf /bin/bluetoothctl
bluez-5.61-1.fc34.x86_64

$ rpm -qf /bin/setxkbmap
setxkbmap-1.3.2-3.fc34.x86_64

$ rpm -qf /bin/xmodmap
xmodmap-1.0.10-1.fc34.x86_64

In the case of compose key, I did set like this connecting the bluetooth keyboard.

$ setxkbmap -layout us -option

$ setxkbmap -option compose:caps

$ setxkbmap -query
rules:      evdev
model:      pc105
layout:     us
options:    compose:caps

Then both my laptop’s keyboard and the bluetooth keyboard work with the compose setting.

That is that I could type ů by typing caps (switch) + o + u by both laptop’s keyboard and the buletooth keyboard.

$ ů

Then

(Masking the bluetooth’s MAC address for privacy)

$ 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

Then while the laptop’s keyboard works with the compose setting, the bluetooth keyboard doesn’t work for the compose setting.

I also tested with the xmodmap too. For example, here is the case to swap Escape key with Caps look key.

xmodmap -e "remove Lock = Caps_Lock"
xmodmap -e "add Lock = Escape"
xmodmap -e "keysym Caps_Lock = Escape"
xmodmap -e "keysym Escape = Caps_Lock"

~/.Xmodmap

remove Lock = Caps_Lock
add Lock = Escape
keysym Caps_Lock = Escape
keysym Escape = Caps_Lock

I haven’t tried @robin217 's way yet.

I found this article. So, I assume that the xmodmap (setxkbmap) issue happens on the Fedora 34 too. Do you know this is a bug of the software or specification?

Unfortunately, in Linux Mint (and Ubuntu derivates) xmodmap resets whenever a keyboard is plugged/unplugged or when a new keyboard is detected.

For my simple need of preserving my Compose key mapping, I’m currently finding that, on Fedora 34, setting my Compose key in Setting > Keyboard, does the trick. If I put my laptop into sleep mode and wake it, or power-cycle my bluetooth keyboard (Logitech k810), I find that my Compose key mapping is still set as expected. I tested on both Gnome on Wayland and Gnome on XOrg. I no longer execute localectl set-x11-keymap us "" "" lv3:ralt_switch,compose:ralt.

I just noticed that ibus-setup has an advanced tab with a “Use system keyboard layout” checkbox — it might be worth trying. There is some discussion about what it is for here: Use system keyboard layout explanation missing · Issue #1906 · ibus/ibus · GitHub

Thanks for the info. I am using i3 window manager. So, I would like to know the X level solution. I don’t understand what the ibus is. I reported this issue on Bugzilla. 2013987 – Key mapping reset on the Buletooth keyboard after reconnecting it now.