Bug 385765 - Compose key creates garbage in QT5 applications, but works correctly in at least some GTK applications (e.g. Firefox)
Summary: Compose key creates garbage in QT5 applications, but works correctly in at le...
Status: RESOLVED UPSTREAM
Alias: None
Product: kxkb
Classification: Miscellaneous
Component: general (show other bugs)
Version: unspecified
Platform: Arch Linux Linux
: NOR major
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-10-15 04:05 UTC by reescf
Modified: 2017-10-25 20:00 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description reescf 2017-10-15 04:05:37 UTC
Please note that I am not at all confident I'm reporting against the correct product. If I am, I have no idea which version.

I'm using a new installation of Arch Linux (new hardware) with KDE. All packages are drawn from the stable repositories. Plasma is 5.11.0. 

I'm trying to replicate treatment of the compose key by Plasma on my old hardware. Both machines have a US keyboard with Euro.

I want AltGr for compose and caps lock for the third level chooser. However, I would setting for ANY key working as compose, provided I can manage without it for other purposes. I've tried using Caps Lock for compose, the win/menu key and, I think, alt, one of the ctrls and probably some keys I don't even have. 

Whatever I configure, the keys work perfectly in Firefox and produce garbage in Kile, Konsole and the test area of KDE settings itself.

~/.config/kxkbrc:

[Layout]
DisplayNames=
LayoutList=us(euro)
LayoutLoopCount=-1
Model=pc105
Options=compose:ralt+shift:breaks_caps+terminate:ctl_alt_bksp+shift:both_capslock+lv3:caps_switch+eurosign:5,lv3:caps_switch,compose:ralt,terminate:ctrl_alt_bksp,shift:both_capslock,shift:breaks_caps
ResetOldOptions=true
ShowFlag=false
ShowLabel=true
ShowLayoutIndicator=true
ShowSingle=false
SwitchMode=Global
Use=true

.local/share/kded5/keyboard/session/ is empty. However, it doesn't help even when it has an .xml file in it.

/etc/environment:

#
# This file is parsed by pam_env module
#
# Syntax: simple "KEY=VAL" pairs on separate lines
#
LANG=cy_GB.UTF-8
LANGUAGE=cy_GB:cy:en_GB:en
LC_COLLATE=C

/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 "XkbModel" "pc105+inet"
        Option "XkbVariant" "euro"
        Option "XkbOptions" "terminate:ctrl_alt_bksp+compose:ralt+shift:breaks_caps+shift:both_capslock+lv3:caps_switch"
EndSection

I've also tried with:
 * no configuration file for the keyboard in /etc/X11/xorg.conf.d and without evdev installed (so libinput handled the keyboard);
 * with evdev installed and a file specifying the evdev driver (to override /usr/share/X11/xorg.conf.d/40-libinput.conf and /usr/share/X11/xorg.conf.d/10-evdev.conf) with various options and layouts.

localectl output:

   System Locale: LANG=cy_GB.UTF-8
                  LANGUAGE=cy_GB:cy:en_GB:en
                  LC_COLLATE=C
       VC Keymap: us
      X11 Layout: us
       X11 Model: pc105+inet
     X11 Variant: euro
     X11 Options: terminate:ctrl_alt_bksp+compose:ralt+shift:breaks_caps+shift:both_capslock+lv3:caps_switch

locale output:

locale
LANG=cy_GB.UTF-8
LC_CTYPE="cy_GB.UTF-8"
LC_NUMERIC="cy_GB.UTF-8"
LC_TIME="cy_GB.UTF-8"
LC_COLLATE=C
LC_MONETARY="cy_GB.UTF-8"
LC_MESSAGES="cy_GB.UTF-8"
LC_PAPER="cy_GB.UTF-8"
LC_NAME="cy_GB.UTF-8"
LC_ADDRESS="cy_GB.UTF-8"
LC_TELEPHONE="cy_GB.UTF-8"
LC_MEASUREMENT="cy_GB.UTF-8"
LC_IDENTIFICATION="cy_GB.UTF-8"
LC_ALL=

printenv output:

KDE_MULTIHEAD=false
GS_LIB=/home/username/.fonts
KDE_FULL_SESSION=true
LS_COLORS=no=0:fi=34:di=35:ln=30:pi=33:so=36:bd=36:cd=36:ex=31:mi=05;34:or=05;30
SIMPLE_BACKUP_SUFFIX=.bkup
LINGUAS=cy en
UNISONLOCALHOSTNAME=MyComputer
ALL_LINGUAS=cy en
LANG=cy_GB.UTF-8
HISTCONTROL=erasedups
LESS=-X
PROFILEHOME=
DISPLAY=:0
SHELL_SESSION_ID=XXX
EDITOR=/usr/bin/vim
GPG_TTY=/dev/pts/7
MOZ_PLUGIN_PATH=/usr/lib/mozilla/plugins
XDG_VTNR=7
PAM_KWALLET5_LOGIN=/run/user/1000/kwallet5.socket
SSH_AUTH_SOCK=/run/user/1000/gnupg/S.gpg-agent.ssh
XDG_SESSION_ID=c3
USER=username
ENV=/home/username/.init/.shinit
PAGER=/usr/bin/less
DESKTOP_SESSION=/usr/share/xsessions/plasma
LC_COLLATE=C
GTK2_RC_FILES=/etc/gtk-2.0/gtkrc:/home/username/.gtkrc-2.0:/home/username/.config/gtkrc-2.0
PWD=/home/username
HOME=/home/username
BROWSER=/usr/bin/xdg-open
XCURSOR_SIZE=0
XDG_SESSION_TYPE=x11
XDG_DATA_DIRS=/usr/share:/usr/share:/usr/local/share
KONSOLE_DBUS_SESSION=/Sessions/8
XDG_SESSION_DESKTOP=KDE
SVN_BASH_COMPL_EXT=urls svnstatus recurse
SYSTEMD_PAGER=/usr/bin/less -FRX
GTK_MODULES=canberra-gtk-module
TERM=konsole-256color
SHELL=/bin/bash
KONSOLE_DBUS_SERVICE=:1.27
XDG_SESSION_CLASS=user
FRACTDIR=/home/username/.xfractint
XDG_SEAT_PATH=/org/freedesktop/DisplayManager/Seat0
FREETYPE_PROPERTIES=truetype:interpreter-version=38
XCURSOR_THEME=Oxygen_Blue
XDG_CURRENT_DESKTOP=KDE
KONSOLE_PROFILE_NAME=Shell
XDG_SEAT=seat0
SHLVL=3
COLORFGBG=15;0
LANGUAGE=en_GB
GTK_RC_FILES=/etc/gtk/gtkrc:/home/username/.gtkrc:/home/username/.config/gtkrc
WINDOWID=XXX
RECORDCOLORS=comment
LOGNAME=username
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
XDG_RUNTIME_DIR=/run/user/1000
XAUTHORITY=/tmp/xauth-1000-_0
XDG_SESSION_PATH=/org/freedesktop/DisplayManager/Session1
QT_AUTO_SCREEN_SCALE_FACTOR=0
PATH=/usr/local/texlive/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/home/username/bin
KDE_SESSION_UID=1000
PS1=\[$fymhrompt\]$SHLVL \w \u\$ \[$fynghonsole\]
KDE_SESSION_VERSION=5
SESSION_MANAGER=local/MyComputer:@/tmp/.ICE-unix/4351,unix/MyComputer:/tmp/.ICE-unix/4351
_=/usr/bin/printenv

Sample output from Konsole when I type ïŷ and some spaces:

 ��     

This is not a display or font issue. If I copy-paste the 'ïŷ' from the line above into Konsole, the characters display correctly. The same is true in Kile. Attempting to compile the source predictably results in the complaint that the unicode character is not recognised.

I have confirmed that whichever key is set for compose does produce Multi_key - even in the KDE applications where it fails so miserably to behave as expected. So the issue seems to be with something which happens in the translation of that key code into characters.

As far as I can tell, compose fails with all attempted combinations. In particular, é fails (which I've seen reported to work in some 'partial problem' bug reports). Nor is this the same problem as the bugs reported as causing the compose key to be ignored. With no compose key, I get regular characters - not garbage. 

I am more than willing to provide additional information as I am really quite desperate. Although I can copy-paste characters from Firefox, that is a very cumbersome and extremely distracting method and, if I don't look at the screen, I'm liable to forget that the key does not work as I think it does when I'm writing.

I do find this in the journal:

kdeinit5[4321]: kf5.kded: No X-KDE-DBus-ServiceName found in "/usr/lib/qt/plugins/kf5/kded/keyboard.so"

However, kdeinit5 makes the same complaint about a long list of libraries, so if this is the problem, I'm weirdly lucky anything else is working.

I also *sometimes* see

kdeinit5[4321]: org.kde.kcm_keyboard: Failed to open layout memory xml file for reading "/home/username/.local/share/kded5/keyboard/session/layout_memory.xml" error: 5

However, sometimes, this file is written and compose doesn't work any better in that case.

Is it possible to tell Plasma/KDE just to not touch the keyboard configuration? I tried deleting all the files I could find in my home configuration directories, but that just caused the key for third-level chooser to be ignored, as well. Right now, I'd like KDE to stay the heck away and not touch it as the systemd configuration seems to do just fine. Whatever KDE is doing, I would like to make it please to stop! However, there does not, unfortunately, appear to be an option for this anywhere ....
Comment 1 reescf 2017-10-16 01:59:06 UTC
So I think there are different problems involved, not all of which are related to KDE. However, I can only get a compose key working (not AltGr, but Caps) by manually ensuring that KDE's configuration matches that of the system-wide configuration in /etc/X11/xorg.conf.d/00-keyboard.conf. If I don't do this, then the settings are either overridden with no options by KDE or added to those options, so that setxkbmap tries to set the keyboard options to a long string of options, some from the system-wide config and some from KDE's user config. I don't know what the expected behaviour is when inconsistent options are combined (e.g. setting a key as both compose and third-level shift or setting different keys as compose or whatever), but the results are a mess.

If the user config is empty, then KDE simply wipes out the system-wide options altogether.

Here is the output of setxkbmap -print -verbose 10 when NO options are configured in KDE settings on login (I deleted everything I could find in my home directory of any possible relevance and restarted sddm.service - the settings for the keyboard were all default):

Setting verbose level to 10
locale is C
Trying to load rules file ./rules/evdev...
Trying to load rules file /usr/share/X11/xkb/rules/evdev...
Success.
Applied rules from evdev:
rules:      evdev
model:      pc105+inet
layout:     us
variant:    euro
options:    terminate:ctrl_alt_bksp+eurosign:5+compose:caps
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwerty)
types:      complete
compat:     complete
symbols:    pc+us(euro)+inet(evdev)
geometry:   pc(pc104)
xkb_keymap {
        xkb_keycodes  { include "evdev+aliases(qwerty)" };
        xkb_types     { include "complete"      };
        xkb_compat    { include "complete"      };
        xkb_symbols   { include "pc+us(euro)+inet(evdev)"       };
        xkb_geometry  { include "pc(pc104)"     };
};

This is not really what I'd expect. If the user has nothing configured, why doesn't KDE retain the system-wide settings? Why does it wipe them instead? This must be very inconvenient on multi-head systems.

If I then very carefully ensure that the GUI settings produce the output expected from the system-wide file, I can get

Setting verbose level to 10
locale is C
Trying to load rules file ./rules/evdev...
Trying to load rules file /usr/share/X11/xkb/rules/evdev...
Success.
Applied rules from evdev:
rules:      evdev
model:      pc104
layout:     us
variant:    euro
options:    terminate:ctrl_alt_bksp+eurosign:5+compose:caps,lv3:ralt_switch,eurosign:5,terminate:ctrl_alt_bksp,compose:caps
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwerty)
types:      complete
compat:     complete
symbols:    pc+us(euro)+inet(evdev)+level3(ralt_switch)+compose(caps)+eurosign(5)+terminate(ctrl_alt_bksp)
geometry:   pc(pc104)
xkb_keymap {
        xkb_keycodes  { include "evdev+aliases(qwerty)" };
        xkb_types     { include "complete"      };
        xkb_compat    { include "complete"      };
        xkb_symbols   { include "pc+us(euro)+inet(evdev)+level3(ralt_switch)+compose(caps)+eurosign(5)+terminate(ctrl_alt_bksp)"        };
        xkb_geometry  { include "pc(pc104)"     };
};

at which point I can type both ŷ and € even in Konsole. (Third-level shift does nothing else, so far as I can tell, so a bit of a waste of a key, but it wouldn't work as compose anyway.)

This requires a /etc/X11/xorg.conf.d/00-keyboard.conf with the following content:

Section "InputClass"
        Identifier "evdev keyboard"
        MatchIsKeyboard "on"
        MatchDevicePath "/dev/input/event*"
        MatchProduct "<some string to match the actual keyboard>"
        Option "XkbLayout" "us"
        Option "XkbModel" "pc105+inet"
        Option "XkbVariant" "euro"
        Option "XkbOptions" "terminate:ctrl_alt_bksp+eurosign:5+compose:caps"
        Driver "evdev"
EndSection

This won't work with libinput, which is otherwise used as default. And it won't work (or I couldn't get it to work) with compose set as AltGr. 

So there is some complex entanglement of issues here involving KDE, probably QT, libinput and I don't know what else. But, at the very least, KDE's settings panel should not produce an inconsistent keyboard configuration and KDE should not override system-wide settings unless the user has requested that.

As it is, the GUI panel is just a complication - it only seems to work if carefully configured to match system-wide settings - and the configuration set/displayed is otherwise just plain wrong. Worse, it either overrides system-wide settings with an empty set of options or corrupts those settings, if the user tries to configure settings through it. That is, it creates an unholy and deeply mysterious mess.
Comment 2 reescf 2017-10-16 02:02:14 UTC
Also, if I change the settings after login (rather than simply setting them from the default state), the original settings are still in the list of options KDE gives setxkbmap. That is, they seem to accumulate in this case, with predictably unsatisfactory results.

That is, the user better get the settings right first time else it is necessary to restart sddm and clean everything out. Fiddling around to see what works or what you like is, therefore, a recipe for nothing working at all.
Comment 3 Christoph Feck 2017-10-25 20:00:59 UTC
Keyboard input in KDE applications is handled by the Qt libraries. Please report this issue directly to Qt developers via https://bugreports.qt.io/

I suggest to test a pure Qt application, like Qt Assistant or Qt Designer, otherwise Qt developers could reject it as a issue caused by KDE software.