Bug 104049

Summary:	CapsLock remapped to Compose key broken
Product:	xkeyboard-config	Reporter:	Jehan <jehan>
Component:	General	Assignee:	xkb
Status:	RESOLVED NOTOURBUG	QA Contact:
Severity:	normal
Priority:	medium
Version:	unspecified
Hardware:	Other
OS:	All
Whiteboard:
i915 platform:		i915 features:

Description Jehan 2017-12-03 14:36:25 UTC

My system is Fedora 27/GNOME 3.26.

I remap the CapsLock into the compose key using the tweak tool, which apparently set /org/gnome/desktop/input-sources/xkb-options dconf settings as: ['compose:caps'].

This used to work, but stopped working from Fedora 26/GNOME 3.24. Also it is never working, but inconsistently, i.e. differently depending on the order of my layouts.

- If I set "Korean (Hangul)" first and "Japanese" second, CapsLock will still work as a normal CapsLock in both layouts: the key will lights on and off and the letters will be uppercase on light-on, and lowercase on light-off.

- If I set "Japanese" first and "Korean (Hangul)" second, CapsLock will work as a Compose key for "Japanese" layout (yeah!), but it will still not work as a Compose for the "Korean (Hangul)" layout. Nevertheless it will stop working as a CapsLock either, meaning the key will be simply rendered useless in "Korean (Hangul)".

I first opened this bug to libxkbcommon (cf. bug 104040) where I was told to reopen it for xkeyboard-config.
Apparently I was informed that the order does indeed matters and that the "Japanese" layout overrides explicitly the CapsLock: https://cgit.freedesktop.org/xkeyboard-config/tree/symbols/jp?h=xkeyboard-config-2.22#n47

Nevertheless this is not good, first because we should still be able to re-override ourselves the CapsLock to Compose ourselves, over any layout. And by the way, it works over "Japanese"! So we did re-overrided the override there! Unfortunately my main layout is "Korean (Hangul)", I want my Compose there and it used to work just a few versions before. So that's a regression! :-)

Expected result: a layout override such as ['compose:caps'] should work over every layout of one's list whatever their order and their own overrides. Therefore it should be applied last, I guess.

Comment 1 Jehan 2018-01-18 04:28:14 UTC

Hello!

I have been playing with xkeyboard-config today, and I am not sure this is the actual culprit in the issue. Could you tell me if you think I am barking at the wrong tree?
Do you think that maybe the issue is in ibus? Or maybe ibus-hangul? Or even another component?

The topic involves so many software that I am a bit lost to where I should look for a fix.

Comment 2 Sergey V. Udaltsov 2018-01-18 19:22:26 UTC

to me it looks like ibus issue, dealing with Korean and Japanese in GNOME

Comment 3 Jehan 2018-01-19 01:14:45 UTC

Just for the record, after going through many components in the chain of text input, I could finally find the issue as being a side effect in ibus-hangul behavior because of a recent change in ibus (the bug was not in ibus, but triggered by it).

So I made a fix in ibus-hangul: https://github.com/choehwanjin/ibus-hangul/pull/54

This whole mapping difference when changing the order of inputs was weird but unrelated (and apparently an expected behavior, even though I find this a bit bad because it makes for non-consistent input behaviors).

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.