Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Caps Lock is always a Caps Lock (even when also something else) #1979

Jehan opened this issue Jan 29, 2018 · 2 comments

Caps Lock is always a Caps Lock (even when also something else) #1979

Jehan opened this issue Jan 29, 2018 · 2 comments


Copy link

@Jehan Jehan commented Jan 29, 2018

The title is a bit weird, so let me explain. This is a followup of #1976 which is mostly fixed, but I realized something is still not perfectly right. So basically my Caps lock key is remapped to the Compose key with the 'compose:caps' option.
But in most input engines (well I haven't tested them all), I realized it still also works as a Caps Lock as well (i.e. the light switches on and uppercase is locked).


  • Set 'compose:caps' (for instance if you use GNOME, you can just use GNOME Tweaks Tool, in the "Keyboard & Mouse" tab, there is a "Compose Key" option which does the work for you).
  • Have Ibus-Anthy or Ibus-Hangul on. They must be the first in the list of inputs.
  • Be in the LATIN mode.
  • Hold CapsLock + o + e.

Expected result: the light on the CapsLock key must not switch on, Capitalization of letter must not be locked for subsequent letters, and "œ" must be outputted.

Actual result: the light on the CapsLock key goes on, Capitalization of letter is locked for subsequent letters, and "Œ" is outputted.
So "compose:caps" did not just override the CapsLock behavior but instead added the compose behavior (and the key does both at once, which is weird).

Why I didn't realize it before was because the first input in my list was "Japanese" (not "Ibus-Anthy" but the Japanese qwerty layout). And apparently this layout overrides the CapsLock key. Moreover since it turns out that the order of layouts/inputs matter, having Japanese first, then "Ibus-Hangul" or "Ibus-Anthy" after make them behave as expected (only Compose, no CapsLock), which is great since there is at least a workaround to my problem (always leave Japanese layout first of the list)!

Now it's less a big issue to me as long as the workaround works. But this is obviously not long term solution. One should be able to set Ibus-Anthy or Ibus-Hangul (or other ibus engines which I have not tested) first in their input list and have the "caps:compose" option work as expected (as an override to CapsLock).

I would like to understand how to fix this, and where is the problem in the input stack. Is it in Ibus? In Ibus-Hangul/Anthy? Other?
Hopefully once again, you can help.

Copy link

@fujiwarat fujiwarat commented Jan 30, 2018

Probably I think your issue is GNOME.
I cannot reproduce your problem in XFCE4.

  1. Run setxkbmap -layout us -option compose:caps
  2. Run ibus-daemon

Because ibus-ui-gtk3 just runs setxkbmap internally.
But gnome-shell(mutter) uses combined layouts e.g. us,jp and switches layouts by the index.

Copy link

@Jehan Jehan commented Jan 31, 2018

Also I realize the issue even happens with non-Ibus layouts, like "English (US)".

Thanks, I opened a bug report in GNOME:
Closing this one.

@Jehan Jehan closed this Jan 31, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.