Summary: | Compose key creates garbage in QT5 applications, but works correctly in at least some GTK applications (e.g. Firefox) | ||
---|---|---|---|
Product: | [Unmaintained] kxkb | Reporter: | reescf |
Component: | general | Assignee: | Unassigned bugs mailing-list <unassigned-bugs> |
Status: | RESOLVED UPSTREAM | ||
Severity: | major | ||
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Arch Linux | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
reescf
2017-10-15 04:05:37 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. 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. 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. |