Map keyboard keys to the "Compose" key for Umlaute, accents and other special characeters


In older versions of openSUSE (at least up until 13.2), I was able to type Umlaute or accents, such as ä, ü, è, on a US keyboard by pressing the right SHIFT key and then pressing the right CTRL key, which corresponded to “Compose”. Then I could for example press " followed by u to get ü. In openSUSE 15.2, this does not seem to be activated by default. I can actually achieve something similar by entering in a terminal:

setxkbmap -option compose:rctrl

I could also add this to a login script so I don’t have to type it every time I start a new session. However, it is still not quite the same
as in older versions of openSUSE where I had to press rshift and then while keeping it pressed I had to press rctrl to enter compose mode (with setxkbmap as above it’s enough to just press rctrl).

In older versions of openSUSE it looks like the compose key was set at bootup even before the X server would start. I’m not sure whether this is related, but file /etc/sysconfig/keyboard contained in older versions the section:

# Compose tables to be loaded.
# Compose tables are good for producing characters, which can not
#  be directly input from your keyboard, such as characters with
#  accents, currency signs, ...
# Please read /usr/share/doc/packages/kbd/README.SuSE for an
#  explanation.
# You may leave this variable empty (default compose table from kernel
#  or KEYTABLE will be used then -- most keyboard maps don't have a
#  compose table, though)
# More than one compose table can be given. For a selection of possible
#  tables see /usr/share/kbd/keymaps/include/compose.*
# You can give more than one compose table, but only the last one will
#  determine the compose combinations.
#  The word "clear" has a special meaning:
#  Your compose table will be cleared, before more compose symbols are
#  added.
# The files compose.winkeys and shiftctrl may be used to map the
#  <compose> key to the W*n menu key and Shift-Ctrl, respectively,
#  on a PC keyboard.
# A typical setting for Latin1 users (with a PC keyboard) may be
#  COMPOSETABLE="clear winkeys shiftctrl latin1.add"
# For latin2, this would be
#  COMPOSETABLE="clear winkeys shiftctrl latin2"
# A typical setting for sb. with a character set, where a matching
#  compose table is missing (but with a PC keyboard), would be
#  COMPOSETABLE="winkeys shiftctrl"
COMPOSETABLE="clear latin1.add"

and there was a folder /usr/share/kbd/keymaps/include, which contained compose.* files such as compose.shiftctrl:

cat /usr/share/kbd/keymaps/include/compose.shiftctrl
# Map the compose key to Shift-Ctrl and Ctrl-Shift
shift   keycode  29 = Compose
control keycode  42 = Compose
control keycode  54 = Compose
shift   keycode  97 = Compose
#keycode  58 = Caps_Lock

In openSUSE 15.2, the section about “COMPOSETABLE” is not present in /etc/sysconfig/keyboard and there is no folder named /usr/share/kbd/keymaps/include. I added the section manually to /etc/sysconfig/keyboard and I also copied /usr/share/kbd/keymaps/include from an older installation, rebooted the system, but rshift-rctrl would still not act as Compose (unless of course I use setxkbmap). I also tried using in /etc/sysconfig/keyboard:

COMPOSETABLE="clear shiftctrl latin1.add"

but it still has no effect. So, my question is whether there is something that I can change at bootup to map rshift+rctrl to Compose like it used to be in older versions or whether my only option is the use of setxkbmap (with not quite the same behavior). I also note that this is independent of the desktop environment as I have tried it out in LXDE and TDE.

To provide some background: Sun workstation keyboards used to have an actual Compose key, which was located on the right side of the keyboard (next to where rctrl is now). By pressing it a small LED would lit up indicating that you could now type special characters by combining for example " + u to get ü. Since Linux is used on regular PCs with regular keyboards, rshift+rctrl became the new “Compose” key.


Left-Shift together with Right-Ctrl works for me. ü
Right-Shift together with Right -Ctrl works also for me. ü
Right shift followed by Right-Ctrl works also for me. ü

I have a strong idea that it works like that out of the box, but I am not 100% sure. Well the section below shows that I probably changed something

When I look in KDE’s System Settings > Hardware > Input Devices and then Keyboard and at right Advanced, I see Configure keyboard options, which is checked. In the lists is Position of Compose key, which is checked, so it seems that I changed something there. When I open that it has checked: Right Ctrl.

You do not inform us about your desktop, so I have no idea if it is worthwhile checking this. Else maybe you find something similar in your DE.

I mentioned it somewhere in my post. I use TDE, but the problem also occurs in LXDE, although TDE is the desktop that I normally use. What happens if you press just rctrl? Does that also put your keyboard into Compose mode?

Henk, do you mind please also posting the output of

setxkbmap -print

henk@boven:~> setxkbmap -print 
xkb_keymap {
        xkb_keycodes  { include "evdev+aliases(qwerty)" };
        xkb_types     { include "complete"      };
        xkb_compat    { include "complete"      };
        xkb_symbols   { include "pc+us+inet(evdev)+terminate(ctrl_alt_bksp)+capslock(escape)+compose(rctrl)"    };
        xkb_geometry  { include "pc(pc101)"     };

And yes, just using Right-Ctrl also gives me ü and á
Suprise, surprise. Much easier then I do for yearslol!. Now try to get the old habit one out of my fingers.

BTW this all in my KDE session (like here in FF, and in Konsole).
It does not work when I log in in the logical console.

Hi there,

I have been trying around with this. Don’t know if it helps, but here’s my findings, nevertheless:
Leap 15.2 / KDE, just as Henk.

Changing the System setting must be set in ~, right? I searched and it will add the changes to my /home/kasi/.config/kxkbrc. It subsequently also changes the result of

kasi@pluto:~> setxkbmap -print  
xkb_keymap { 
        xkb_keycodes  { include "evdev+aliases(qwertz)" }; 
        xkb_types     { include "complete"      }; 
        xkb_compat    { include "complete"      }; 
        xkb_symbols   { include "pc+de+inet(evdev)+terminate(ctrl_alt_bksp)+**compose(rctrl-altgr)**+terminate(ctrl_alt_bksp)"      }; 
        xkb_geometry  { include "pc(pc101)"     }; 
kasi@pluto:~> setxkbmap -print  
xkb_keymap { 
        xkb_keycodes  { include "evdev+aliases(qwertz)" }; 
        xkb_types     { include "complete"      }; 
        xkb_compat    { include "complete"      }; 
        xkb_symbols   { include "pc+de+inet(evdev)+terminate(ctrl_alt_bksp)+**compose(rctrl)**+terminate(ctrl_alt_bksp)"    }; 
        xkb_geometry  { include "pc(pc101)"     }; 

man setxkbmap

The source for all of the components can be found in /usr/share/X11/xkb

But that didn’t really enlighten me. Then I have been looking around in /usr/share/kbd/keymaps/ and hey, there is a “legacy” folder. And there is your compose.shiftctrl in: /usr/share/kbd/keymaps/legacy/include/

But sorry, I have no idea how you can activate that “legacy”. I’d guess it must be possible if it’s being kept around?

This is what I was pointing out in my original post. In the “old” behavior, i.e., up to openSUSE 13.2, pressing just rctrl did not set the keyboard into Compose mode. It may be something that most people may not even notice. The only disadvantage is that if you for example press rctrl + l (“l” is low case for “L”) to clear the terminal, this will not work as rctrl has now been re-purposed as Compose. In the “old” behavior you had to press rshift+rctrl or lshift+rctrl (shift followed by rtrl would not work) in order to get into Compose so that rctrl + l would still clear the terminal.

It seems that I will end up solving it as in your case either through the DE or by putting

setxkbmap -option compose:rctrl

into a login script /etc/csh.login.local, /etc/profile.local.

I just thought that maybe there is a system file (kernel or Xorg) that I can tweak to get the “old” behavior.

Interestingly, the output of setxkbmap -print in older versions was

xkb_keymap {
        xkb_keycodes  { include "evdev+aliases(qwerty)" };
        xkb_types     { include "complete"      };
        xkb_compat    { include "complete"      };
        xkb_symbols   { include "pc+us+inet(evdev)+terminate(ctrl_alt_bksp)"    };
        xkb_geometry  { include "pc(pc104)"     };

And yet shift+rctrl worked as Compose. This means that in older versions of openSUSE this keyboard mapping was probably not set at the X level, it was set somewhere else, kernel?

I decided to resolve it with the following two scripts:

/home/gianluca> cat /etc/csh.login.local
    setxkbmap -option compose:rctrl


/home/gianluca> cat /etc/profile.local
if test -n "$XSESSION_IS_UP" && test -z "$SSH_CONNECTION" ; then
    setxkbmap -option compose:rctrl

In this way, the feature will be available to any user in any desktop environment unless a user is using a different shell other than (t)csh or bash. The script tests 1) that the X session is up and 2) that the user is not logged in remotely to avoid messing around with the client in case of a remote connection. If anyone thinks this could lead to problems, I would like to hear it.

I only ever have set this using KDE System settings (as indicated above). Already from KDE 3.n (n < 5).
Always used the, still working, LeftShift-RightCtrl.

This is interesting. Until now, I have never had to set anything for it to work. Somehow it was set at the boot level, I never had to do anything with KDE System settings. Maybe this is because I have always used a US keyboard and the system would recognize that and set shift+rctrl as compose? In any case, something has changed in this regard after openSUSE 13.2 (at least from my experience).

I am afraid my memory does not go back that far very well. Assaid above somewhere, I am not sure I configured it originally, thus it maybe very well it was the default for KDE in those times. And it maybe that I only checked it when installing a new openSUSE. OTOH, it is a check and thus deviates from the stndard. Thus again I am nt sure about how my hostory has gone.

I do make another change there (using Caps-Lock as an Esc), thus I am sure I always visit there on a new install.

I can however add that I always used a US keyboard.

All my remarks are BTW about KDE. not about openSUSE as a system. The compose key does nit function in the (virtual) console.

Same for me on older openSUSE installations, i.e., the compose key does not work in the virtual console. So it is probably something that used to be activated in the X system (contrary to what I wrote earlier) but it should be independent from the desktop environment. Something must have changed in the X system configuration after openSUSE 13.2.