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?

[jceaser]

I just don't get the testing part of this. I copied the TestIn directory to my branch, but I don't know what to do now. I figured out how to get came to do something (I'm an much older hack, I don't get you kids with your cmake). I can't run the python scripts because they complain about not having an "interface" which I found was one of the included files. How do I run the test script?

[kll]

I can't get any of the state scheduling stuff to work either. Am I being stupid or is it still not actually supposed to be working yet? I definitely see kll BETA 0.5c output during a build.

[haata]

Yeah, it's not implemented yet. I've been focusing on catching up on bugs.

…

On Thu, Nov 2, 2017 at 6:30 AM Kevin Lewis ***@***.***> wrote: I can't get any of the state scheduling stuff to work either. Am I being stupid or is it still not actually supposed to be working yet? I definitely see kll BETA 0.5c output during a build. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABbqYD7T3dVSJVPHmbQLkfdlnYTvopoks5sycPggaJpZM4DbLcw> .

[thor]

Are there any other firmwares currently out there that can accomplish this, or is there anything in terms of help that can be provided to get this to a goal?

[haata]

QMK does it I think.

The K-Type is partially supported I think, but I'm not sure how far along they are.

[leshow]

QMK does it, they also have limited support for the LCD. It doesn't look as nice, but it's a feature I couldn't live without (dual fn keys).

[simonwillcock]

I'd love this feature and would be a willing tester on the Ergodox infinity.

[TheOtherDave]

Ditto, if I had a 2nd one... don’t wanna risk messing up my main keyboard, and I need to get another for work anyway

…

Sent from my iPhone

On Jan 25, 2018, at 22:05, Simon Willcock ***@***.***> wrote: I'd love this feature and would be a willing tester on the Ergodox infinity. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[jwvanderbeck]

Wanted to ping in here as well to see if there is a way to do this yet, even if I have to get my hands dirty?

I see mention of this functionality in the 0.5 draft spec, and I set up a basic build change for compiling my own kll files into .bin, but I'm not sure if that is supported the 0.5 yet spec or not, or which branch I should be using if it is. Also would there be any other pieces aside from this repo I would need?

EDIT: I want to do this on a WhiteFox keyboard.

[jwvanderbeck]

So I tried compiling my own bin, but ran into a strange issue when flashing. When flashing that new bin the keyboard essentially got stuck in flash mode. After the bin was flashed it stayed in flash mode. Disconnecting the keyboard still left it in flash mode. Nothing would get it out except flashing a bin from the online configurator.

So I guess that was a dead end.

[p-callaghan]

I had the same issue when I tried to accidentally flash using the secure .bin file. Try flashing with the other .bin. Peter On Jan 29, 2018 8:28 PM, "jwvanderbeck" <notifications@github.com> wrote: So I tried compiling my own bin, but ran into a strange issue when flashing. When flashing that new bin the keyboard essentially got stuck in flash mode. After the bin was flashed it stayed in flash mode. Disconnecting the keyboard still left it in flash mode. Nothing would get it out except flashing a bin from the online configurator. So I guess that was a dead end. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AQRzYlsUdAQh_-tv94U_-8oESrnQk6fLks5tPoxogaJpZM4DbLcw> .

[jwvanderbeck]

Thanks for the tip, but that was with the normal bin, unless I was daft. I will try again just to be sure, but fairly certain.

[dmgm]

I've tried adding the Custom KLL
U"CAPSLOCK" : U"LCTRL";
U"CAPSLOCK"(UR) : U"Esc";
U"LShift" + U"RShift" : U"CAPSLOCK";

This results in CAPS remapped to CTRL, and holding both shift keys toggling CAPS.
The Unique Release (UR) state scheduling doesn't work as I'd expect under s 5.1.2.1 of the version 0.5c of the KLL spec. Perhaps s 5.1.3.1 is more relevant to USB codes, but it appears the same.

Could someone confirm my configuration is correct and the failing is the feature is not yet implemented?

[apazzolini]

@dmgm This isn't implemented yet. You can follow kiibohd/kll#23 to track the pre-requisite for this issue.