https://bugs.kde.org/show_bug.cgi?id=385765
Bug ID: 385765
Summary: Compose key creates garbage in QT5 applications, but
works correctly in at least some GTK applications
(e.g. Firefox)
Product: kxkb
Version: unspecified
Platform: Archlinux Packages
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: NOR
Component: general
Assignee: unassigned-b...@kde.org
Reporter: ree...@gmail.com
Target Milestone: ---
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 ....
--
You are receiving this mail because:
You are watching all bug changes.
