X.Org bug on (X)Ubuntu Linux: no AltGr accented vowels

I came across what seems to be a surprising bug on Xubuntu 22.04 GNU/Linux with all my keyboards.

After booting, whatever keyboard does not produce acute accented vowels when the (right) AltGr is held with the following configuration.

  • keyboard layout: English (US) (intl., with AltGr dead keys)
  • operating system: Xubuntu 22.04

Physically disconnecting and reconnecting the keyboard temporarily resolved the issue until the next reboot.

Output from the xev command when pressing AltGr+u:

Actual (after a reboot)

KeyPress event, serial 28, synthetic NO, window 0x7200001,
    root 0x1cd, subw 0x0, time 13963646, (394,394), root:(1265,839),
    state 0x10, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
    XKeysymToKeycode returns keycode: 92
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 28, synthetic NO, window 0x7200001,
    root 0x1cd, subw 0x0, time 13964408, (394,394), root:(1265,839),
    state 0x90, keycode 30 (keysym 0x0, NoSymbol), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

Expected (or after reconnecting the keyboard)

KeyPress event, serial 28, synthetic NO, window 0x7200001,
    root 0x1cd, subw 0x0, time 13959370, (394,394), root:(1265,839),
    state 0x10, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
    XKeysymToKeycode returns keycode: 92
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 28, synthetic NO, window 0x7200001,
    root 0x1cd, subw 0x0, time 13959610, (394,394), root:(1265,839),
    state 0x90, keycode 30 (keysym 0xfa, uacute), same_screen YES,
    XLookupString gives 2 bytes: (c3 ba) "ú"
    XmbLookupString gives 2 bytes: (c3 ba) "ú"
    XFilterEvent returns: False
2 Likes

After debugging, this turned out to be a bug with the X.Org windows system on Linux (Spanish); not with any keyboard.

2 Likes

Digging a little further, I found the pertaining X.Org issue on GitLab with an effective workaround that survives rebooting.

It suffices to automatically run the command setxkbmap without any arguments at startup (login), as shown below:

I also reported this workaround over at Ask Ubuntu; my “external extended memory” for such things. :brain:

Case closed (and a Saturday evening wasted on debugging :tired_face:)

2 Likes

Interesting thread. Scanning your xev output the only difference I could find was the serial parameter, but I have no idea what it is. To count switch activations in my own keyboard I had made a little program to parse /dev/input keyboard files (specifically this struct linux/input.h at master · torvalds/linux · GitHub is written to the keyboard input files) and there is no data part called serial there, as far as I know.

The keyboard layout you are using is very interesting. Do you use it for typing in other languages?

With the many tests, I made a little mistake in cutting and pasting the xev output. I retested and can confirm that the serial number actually stays the same. Hence, I corrected my previous post.

Yes, I do write in five languages, often on a daily basis, namely: English, Spanish, German, French and Dutch thanks to the US International keyboard layout, pictured below. This also allows me to use nice ANSI (SA) keycaps on all my keyboards.

However, it did take me many years to figure this out. I grew up in an AZERTY-only country with shifted digits and periods, tiny shift keys and the odd-located M key (yep). I happily switched to the Swiss QWERTZ layout after having lived a couple of years in Switzerland where they write in German, French, Italian and Reto-Roman. When I started building my custom mechanical keyboards, I finally settled for this international ANSI layout without any compromises. It is a pity, too few people know about this.

US International keyboard layout