Make it possible to send different keycodes for short- and longpresses of keys

[bl1nk]

A feature I'd like to see in KLL would be to send different keycodes depending if a key is being pressed or being hold.

For example: remap the capslock key to send control if held down, but if just pressed send esc.
I set this up in software already using Karabiner on OS X, but having this in hardware would be better.

[smasher816]

I have talked with Haata about this and he stated that there is enough request that he wants to add the feature. Unfortunately the kll spec needs to be updated to support this feature, and code needs to be written to handle the various cases.

Personally I am very used to this with Ctrl/Escape dual role on my HHKB and would love to have it added to my Infinity.

[app]

Hi!
I think it is must have feature for any custom keyboard.
I'll not buy Infinity keyboard without this feature.
I remapped as Ctrl not only CapsLock but Enter as well in my teensy based keyboard.
Smart dual role behavior allows to use such mappings without any pine.
I mean double click on Enter (click and tap actually) will result as press and hold Enter on regular keyboard.
So you will not lose any functionality when remap key as dual role key.
One good use case is SpaceFn layout as well.

[LeonB]

I wouldn't care to much for short or long keypresses but more keypresses in combination with other keys. I've mapped escape to my "capslock" key. What would be great: escape (even when pressed long) and release = escape. Escape + S = Ctrl + S

[unphased]

I think you guys are describing a lot more than just "alternate behavior on long hold", but I like it a lot (especially practical sounding is the ctrl key that functions as escape if pressed by itself. That would be epic)

Hopefully rewriting the spec can accommodate and allow us to program all such behaviors with full control. Can't wait to get my infinity board.

[friday]

Dealbreaker for me as well, but there's a TMK fork for the first Ergodox massdrop, so I might have an alternative. https://github.com/squarefrog/tmk_keyboard (active fork of abandoned fork)

[ec1oud]

Yes please... I'm eagerly awaiting the combined ctrl/esc key too. Already have it on my Ergodox EZ with qmk firmware.

[audibleblink]

I've been reviewing the 0.5b spec while trying to duplicate an existing mapping from my Atreus where you can switch layers when holding an alpha key and just typing the alpha key when it's tapped. Ex: when I hold 's', Layer 4 pops up and hjkl become left, down , up, right.

It seems that something like the following would duplicate that behaviour in KLL but I can't test since I'm still waiting for my Dox to show.

Is this right?

    U"S"(UR) : U"S";               // U-nique R-elease of "S", sends "S"
    U"S"(H) + U"H" : U"LEFT";      // H-olding "S" plus tapping "H", send "LEFT"
    U"S"(H) + U"J" : U"DOWN";
    U"S"(H) + U"K" : U"UP";
    U"S"(H) + U"L" : U"RIGHT";

Longer explanation here

[haata]

This looks about right. Also take a look at the Isolation Section (5.0.1 as of right now). It may also be able to do what you want to do, though I'd recommend your example usage in general.

[eltang]

I'm curious to see what the implementation will look like. Any progress on this?

[haata]

I'm deep into a KLL compiler rewrite atm. Hopefully should have something to show in the next couple of weeks. Still finalizing what the datastructures are going to look like on the firmware side though...

[basepi]

Any updates here? With Karabiner broken on macOS Sierra, I can't upgrade. Would love to move this to hardware.

[audibleblink]

Willing to help test any WIP branches. Using a mac for work again and Sierra won't let me dual role Caps to be Ctrl/Esc so was hoping to have this definable in hardware for the upcoming Whitefox.

[haata]

I'm finally feeling like I'm making progress again on KLL. The KLL compiler portion of this feature is done, now it's a question of integrating the keypress scheduler inside the firmware (amusingly, this is probably less code than the compiler, lol).

For those that may know a bit of Python (nothing complicated), I've designed unit test infrastructure primarily to test this feature (one of the reasons it's taking me so long). It would be really nice if I could get some real world use cases.

Right now, the tests are written in two parts.

1. KLL file describing mappings
2. Python script initiating event and then validating the result.

It doesn't require a physical keyboard, so they can easily be automated.

Example test.py https://github.com/kiibohd/controller/blob/ktype/Scan/TestIn/Tests/test.py
Example KLL file https://github.com/kiibohd/controller/blob/ktype/Scan/TestIn/scancode_map.kll
Script to run test https://github.com/kiibohd/controller/blob/ktype/Keyboards/Testing/macrotest.bash

Right now it only works on Linux (working on Mac/Windows compatibility).

Find me on IRC #input.club @ irc.freenode.net if you're interested in helping out.

[leshow]

Has there been any progress on this feature?

[haata]

Yes, there's been a bit. The new KLL compiler has been hooked into the ktype branch.

I still need to add interconnect support into the new compiler (it has to do with how the scancode offsets are calculated from the daisy-chain at compile time). But I think I'm starting to see the finish line...

[basepi]

That's awesome! If I can do this in the keyboard firmware I can finally upgrade to macos sierra without reservation!

[jceaser]

the commit above does not look like it has anything to do with this ticket, is there a branch or some other commit where this work is taking place?

A follow up question, is the ktype branch where the all 0.5 work is being done, should I try to build that and play around with it to learn more about what has been done?

[audibleblink]

Trying the ktype branch with the following kll entry.

U"CAPSLOCK"(UR) : U"ESC";
U"CAPSLOCK" : U"LCTRL";

Should that be working?