when capturing key in kanata, can it still be passed through as-is to OS?

[laur89]

Problem:

umlauts are tricky every which way, and the solutions with kanata as well are finicky and don't work in every program. I've gone back to xmodmap method to provide umlauts. E.g. following configuration generates ö/Ö on AltGr+;:

! Set Right Alt as a Mode Switcher
keycode 108 = Mode_switch

! Map Umlaut to <Key> + Mode_switch
keycode 47 = semicolon    colon      odiaeresis Odiaeresis

Now, for some other functionality I'd like kanata also to bind a few AltGr+<key> mappings, e.g with following config excerpt AltGr+u toggles media play status:

(defalias
  nav  (tap-hold-press 200 200 ralt (layer-toggle nav))
)

(deflayermap (main)
  ralt @nav
)

(deflayermap (nav)
  u MediaPlayPause
)

Problem is when kanata is started with this config, it takes over right alt, and xmodmap config no longer works.

Is there a way to have this cake and eat it too?

[jtroo]

I'm no xmodmap expert so unsure if possible but sounds like you need to add a configuration so that xmodmap reads kanata evdev events as well as the other keyboard events.

[laur89]

Looks like AltGr is swallowed. This is reported by xev with kanata:

KeyPress event, serial 36, synthetic NO, window 0x7600001,
    root 0x3e8, subw 0x0, time 222837953, (628,1096), root:(2550,1138),
    state 0x0, keycode 47 (keysym 0x3b, semicolon), same_screen YES,
    XLookupString gives 1 bytes: (3b) ";"
    XmbLookupString gives 1 bytes: (3b) ";"
    XFilterEvent returns: False

KeyRelease event, serial 36, synthetic NO, window 0x7600001,
    root 0x3e8, subw 0x0, time 222838009, (628,1096), root:(2550,1138),
    state 0x0, keycode 47 (keysym 0x3b, semicolon), same_screen YES,
    XLookupString gives 1 bytes: (3b) ";"
    XFilterEvent returns: False

No Mode_switch key event detected, can generate it only by single tapping AltGr.

Compared to when kanata is stopped:

KeyPress event, serial 37, synthetic NO, window 0x8200001,
    root 0x3e8, subw 0x0, time 223031066, (905,1115), root:(2827,1157),
    state 0x0, keycode 108 (keysym 0xff7e, Mode_switch), same_screen YES,
    XLookupString gives 0 bytes: 
    XmbLookupString gives 0 bytes: 
    XFilterEvent returns: False

KeyPress event, serial 38, synthetic NO, window 0x8200001,
    root 0x3e8, subw 0x0, time 223033714, (905,1115), root:(2827,1157),
    state 0x2000, keycode 47 (keysym 0xf6, odiaeresis), same_screen YES,
    XLookupString gives 2 bytes: (c3 b6) "ö"
    XmbLookupString gives 2 bytes: (c3 b6) "ö"
    XFilterEvent returns: False

KeyRelease event, serial 38, synthetic NO, window 0x8200001,
    root 0x3e8, subw 0x0, time 223033802, (905,1115), root:(2827,1157),
    state 0x2000, keycode 47 (keysym 0xf6, odiaeresis), same_screen YES,
    XLookupString gives 2 bytes: (c3 b6) "ö"
    XFilterEvent returns: False

KeyRelease event, serial 38, synthetic NO, window 0x8200001,
    root 0x3e8, subw 0x0, time 223034929, (905,1115), root:(2827,1157),
    state 0x2000, keycode 108 (keysym 0xff7e, Mode_switch), same_screen YES,
    XLookupString gives 0 bytes: 
    XFilterEvent returns: False

Note the distinct keycode 108 events for RAlt.

---

Now, my next reflex is to hack around this problem. What we can do here is make kanata produce unused keycodes, and map those in xmodmap.

E.g. xmodmap -pke lists keycodes that are not mapped to anything, say

$ xmodmap -pke
keycode 247 = XF86UWB NoSymbol XF86UWB
keycode 248 =
keycode 249 = XF86Next_VMode NoSymbol XF86Next_VMode

shows 248 is not bound/used. So add following mapping to kanata (note kanata needs a value keycode - 8 so 240 in this case, see this as to why):

(defalias
  nav  (tap-hold-press 200 200 ralt (layer-toggle nav))
  ab1 (arbitrary-code 240)
)

(deflayermap (main)
  ralt @nav
)

(deflayermap (nav)
  u MediaPlayPause
  ; @ab1
)

...and this to ~/.Xmodmap:

keycode 248 = odiaeresis Odiaeresis

It's hacky, but it works. Is that the way to go, or are there more elegant workarounds?

[jtroo]

That seems like a fine solution and seems like a convenient one compared to alternatives, see below.

---

The issue is that when you hold physical AltGr, it is a (layer-toggle nav) which of course doesn't activate AltGr downstream.

One thing you can do is make @ab1 be RA-; and repeat for all other AltGr combos that you need.

---

You could also use something like:

(multi ralt (tap-hold-press 200 200 _ (layer-toggle nav)))

This keeps AltGr held downstream while activating the nav layer but this active AltGr may interfere with other nav layer actions in a negative way. This could be worked around with a solution like: nav layer actions that don't want AltGr can use (multi (release-key ralt) @myaction) but that is also unwieldy.

[laur89]

Quick check shows (multi ralt (tap-hold-press 200 200 _ (layer-toggle nav))) works like a charm. I'm not nearly proficient enough in kanata syntax to quite understand the potential problems, but until I hit a roadblock I'll continue using this. Thanks!