Feature request: The unicode keyword assumes an us keyboard

[mklcp]

Is your feature request related to a problem? Please describe. On Linux, when an input device is registered, it's assume by default to have a US qwerty keyboard. This holds even when you just plug an external hardware keyboard. For non-US users, you have to then change the keyboard, often via running setxkbmap.

Which can cause, for foreign keyboards, to have another letter than u on the key of keycode U. On Linux, the Ctrl+Shift+U mechanism used by kanata to input unicode supposes that you have the char u on key of keycode U. This problem is general to Linux. For example, just use a russian keyboard (setxkbmap ru): Ctrl+Shift+U will not work.

If you jumble the qwerty keyboard on your base layer, the symbol u will still be on the key of keycode U. So Unicode will work correctly. But if you just use kanata for adding, for example, home-row modifiers, on your russian keyboard; don't expect the unicode keyword to work.

There is no real solution to this problem, because Kanata works solely on keycodes. What is needed here is a key that is without doubt mapped to the symbol u, which is out of the scope of working with keycodes.

Most european keyboard has symbol u on keycode U, so this problem concerns very few people.

I would suggest adding a disclaimer to the use of unicode keyword, that it might not work if you change your software keyboard layout (e.g. via setxkbmap) after having launch kanata.

[jtroo]

A warning would be useful to add, and also it could be possible to change the u key for unicode output in Linux via a configuration. E.g. (defcfg linux-unicode-u-substitute x).

[jtroo]

Would you be able to test the PR to see if it helps this issue? Documentation here: https://github.com/jtroo/kanata/blob/linux-unicode-improvements/docs/config.adoc#linux-only-linux-unicode-u-code

[mklcp]

Thanks, it works.

I would just precise the wording in the config.adoc, changing it to:

<<table-of-contents,Back to ToC>>

Unicode on Linux works by pressing Ctrl+Shift+U, typing the unicode hex value,
then pressing Enter. However, if you do remapping in userspace, e.g. via
xmodmap/xkb, the keycode "U" that kanata outputs may not become a (X)keysym "u" 
after the userspace remapping. This is especially true if you use a non-european
keyboard on top of kanata.
For unicode to work, kanata needs a keycode that outputs the keysym "u", but
this keycode is not forced to be keycode "U".

You can use `evtest` or `kanata --debug` then set your userspace
remapping, then press the key that outputs keysym "u", to
see which underlying key code is sent.
You can use this configuration to change the behaviour.

Example:

to be extra-clear on the difference between keycodes and keysyms (the characters output defined via xkb/xmodmap).

 

More generally, it's not even guaranteed that keysym Control is on keycode Control. To be really general, the user could be pass an alias that outputs the sequence ctrl+shift+u compatible with their xkb remapping.

But that seems really overkill for now. Moreover, if the lisp language is more full-fledged on day, users will be able to define their own unicode macro that uses the keycodes they want.

It's indeed possible to use fake-keys to outputs unicode, e.g. with this code:

(deffakekeys
  ctl lctl
  sft lsft
  u   u
)

(defalias
 0 0
 1 1
 2 2
 3 3

 ģ (macro
        (on-press-fakekey ctl press) 1
        (on-press-fakekey sft press) 1
        u 1
        (on-press-fakekey ctl release) 1
        (on-press-fakekey sft release) 1

        @0 1 @1 1 @2 1 @3 1 spc 1
      )
)

;; so @ģ outputs ģ on Linux

[mklcp]

Another minor issue, Unicode doesn't work when capslock is on.

This can be seen by launching kanata with a config as simple as

(defcfg

)

(defsrc
   a
)

(deflayer base
    (unicode ꜳ)
)

Num Lock and Scroll Lock don't trigger any issue.

[jtroo]

I'll make the update to the terminology 👍

I can't reproduce the caps lock issue, at least on the minimal applications I've tried on ubuntu 22.04. Works in the default terminal and firefox, with or without caps lock. Perhaps this is another application-specific issue.

[jtroo]

If you have any ideas with regards to the caps lock issue, feel add more comments here or open a new issue 🙂

[mklcp]

Ok thanks

I'm using firefox too, and a quite default terminal (xfce4's) and with caps lock on it's not working