Closed zenny closed 2 months ago
On Linux the input handling model from physical input to application goes something like this (order is relevant)
physical keyboard -> kernel -> desktop env -> application
Kanata and ultikeys are at kernel and userspace respectively
physical keyboard -> kernel -> desktop env -> application
kanata ultikeys
At the kernel layer Kanata captures+re-sends device events. Kanata always operates on US-layout input codes. xkb, xmodmap and other tools read Kanata's outputs to transform the US-layout kernel outputs to the ultikeys layout, or whichever desktop environment layout is active.
With this context, it's not clear to me what this is supposed to mean:
keep the ultikeys layout the default layout to read from in kanata?
If you run Kanata while remapping nothing and use ultikeys, your input should already behave as if Kanata wasn't running at all, and you should be typing in the ultikeys layout.
(defcfg process-unmapped-keys yes)
(defsrc)
(deflayer base)
On Linux the input handling model from physical input to application goes something like this (order is relevant)
physical keyboard -> kernel -> desktop env -> application
Kanata and ultikeys are at kernel and userspace respectively
physical keyboard -> kernel -> desktop env -> application kanata ultikeys
At the kernel layer Kanata captures+re-sends device events. Kanata always operates on US-layout input codes. xkb, xmodmap and other tools read Kanata's outputs to transform the US-layout kernel outputs to the ultikeys layout, or whichever desktop environment layout is active.
@jtroo Thanks for taking time to elaborate. After running kanata, the remaining kernelspace layouts other than ultikeys were cycled and loaded after pressing right_ctrl+right_shift as expected:
setxkbmap -layout ultkeys,gr,pi,ar -option grp:rctrl_rshift_toggle,caps:ctrl_modifier
With this context, it's not clear to me what this is supposed to mean:
keep the ultikeys layout the default layout to read from in kanata?
If you run Kanata while remapping nothing and use ultikeys, your input should already behave as if Kanata wasn't running at all, and you should be typing in the ultikeys layout.
Thanks.
(defcfg process-unmapped-keys yes) (defsrc) (deflayer base)
Is your feature request related to a problem? Please describe.
The standard US keyboard cannot print different glyphs used in the European languages. Specific European keyboards have extra keys, good for linguistic purpose, but not convenient to work with general text and coding simultaneously as the distances are too far and in unusual locations. But ultikeys (https://github.com/pieter-degroote/UltimateKEYS) layout supports all latin-based languages without disarranging the us-layout.
Describe the solution you'd like.
So how wonderful it be wonderful to keep the
ultikeys
layout the default layout to read from inkanata
?Describe alternatives you've considered.
Currently, I switch between
ultkeys
(that supports all latin-based European languages with different glyphs, see https://github.com/pieter-degroote/UltimateKEYS), Greek (gr
) layout for mathematical notations, Pali-Sanskrit (pi
) for oriental inscription ( https://github.com/bdhrs/pali-sanksrit-keyboard-for-linux) and Arabic (ar
) for Arabic layout (sometimes 12 different scripts, not languages), and toggle between them by pressing Ctrl_R and Shift_R in a 104-key US keyboard by running:Additional context
Advantages
~
on has to press AltGr+two times an extra key that lies next to the]
which is not found in us-layout.Please refer to the discussion in https://github.com/jtroo/kanata/discussions/1245. Thanks.