[kxkb] [Bug 385765] Compose key creates garbage in QT5 applications, but works correctly in at least some GTK applications (e.g. Firefox)

[bugzilla_noreply at kde.org]

https://bugs.kde.org/show_bug.cgi?id=385765

--- Comment #1 from reescf at gmail.com ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.