kareltucek / firmware Goto Github PK

Two consecutive keystrokes which overlap in time currently produce a report which contains two scancodes - such report is currently not compressed and therefore takes 9-bytes (plus another 2 bytes for the previous report). This should be optimized down by creating a new special-case in the serialization algorithm.

When using postponed secondary roles, such role can postpone release of previous key until release of the following key, which may be enough to trigger host OS key repetition.

This can be resolved by making postponer remember modifier states along with the event log...

The number of layers could be easily increased to lets say 8. The upper four layers could be filled by importing another keymap as into these four slots via a command.

Furthermore, a command could be written that would selectively import a specified layer from a specified keymap to a specified layer on the currently active keymap (in RAM only). This could easily work on one half only.

Usecases:

• increasing number of available layers without having to workaround via keymap switches
• allowing locking just one half of a layer
• this way, setting up complex keymaps would be much more comfortable

I could be overlooking the feature, but if not I think it would be good to have macros able to play macros created in UHK Agent. I'm making a Starcraft II configuration and need many macros to do some of the same actions.

Is it possible to let the keyboard output (modifier keys = output char):

WIN + ; = ö
WIN + SHIFT + ; = Ö
WIN + , = ä
WIN + SHIFT + , = Ä
WIN + - = ß
etc.

with this firmware?

If yes, could you show me how, please?

US ANSI UHK keyboard, US keymap loaded (on Windows)

Fix parse int function...

Is this possible?
Since macros are executed asynchronously is there any way to stop them?
My use case is following:
I want to repeat some keystrokes indefinitely or until I interrupt it manually.
So far I've managed to repeat keystrokes indefinitely by reseting register's state.
Actually I can interrupt it by powering off the keyboard but that's only way I've found.

• should replace the need for resolveNextKeyEq/ifPendingId by something more ergonomic

I would like to have a "record_keys" and a "playback_keys" command in the macros that would allow capture and use of "custom live strings" to enable such usecase :

1 start the macro
2 record_keys (user types "hello" followed by a termination command eg. Mod+Enter)
3 other macro commands
...
...
n playback_keys (would type "hello" where the cursor stands)
n+1 other macro commands
end of macro

The system described here is a single "custom live string" buffer but with labels "record_keys [StringName]" "playback_keys [StringName]" it could be extended to more than one "custom live string" buffer. I don't expect the "custom live strings" to be persistant between macro runs or different macros.

Sorry if the format of this "idea" is not the usual one, I try to contribute an idea that is a bit more ambitious than I am ready to implement myself in this codebase....

I am trying to solve my issue with a german keyboard layout on Windows 10 using your modified firmware.

On a german keyboard layout in Windows, the {[]} characters can be entered by pressing

"RAlt"+"7","8","9" and "0" (on the number row).

I now have created an openKlammer macro that reads in Agent:

$ifNotShift suppressMods tabKey RA-7
$ifShift suppressMods tabKey RA-8
$displayStatus

and similar for closeKlammer but with RA-9 and RA-0. These are now assigned to the keys "[" and "]" (as given by the American keycaps). When I now press the key I get error messages, which are displayed like this:

openKlammerÖ 0Ö unrecogniyed commandÖ tabKey RAß8
for pressing "["

and

OPENKLAMMERÖ !Ö UNRECOGNIYED COMMANDÖ TABKEY RA?/
for pressing Shift+[.

Note that on a German keyboard "y" and "z" keycaps are swapped and ";" is ö, "-" is ß.

Entering tabKez instead does not work.

What would be your expectations? And what should I enter?

Thanks in advance, Jens

Is it possible to keep delays between key presses when recording runtime macro?

The simple resolver implementation I use is still, for example:

$postponeKeys ifNotReleased ifNotPending 1 goTo @0
$postponeKeys ifPending 1 delayUntil 100
$ifNotReleased ifPending 1 final holdLayer mod
$holdKey a

Unfortunately, I have to report a regression: Today, I flashed 8.6.0.kt1 and all my virtual mods immediately caused high typing interference. I already tried to debug it. By using delayUntil 1000 instead of delayUntil 100 above, I found out that the ifNotReleased logic no longer works: Even if the key has been released long before delayUntil 1000 expires, it still goes to the mod layer, instead of playing back the key press as usual typing. I have now gone back to 8.5.4.kt25 and all my virtual mods immediately started working again robustly. So it must have something to do with 8.6.0.kt1...any idea?

Originally posted by @orthoceros in #24 (comment)

Currently the macro recorder doesn't allow adding delays (e.g., to wait for window manager to react to a command). A solution might be to add a key (via command) which would "manually" add a delay into the currently recorded macro.

I have encountered a time logic problem with postponed macro execution that I cannot solve. It occurs with both resolveSecondary and the 1-key virtual mod idea from the other thread. I use the latter below, as it makes the problem more clear in macro code:

I use the following macro on the ; key and the sequence ;->j maps to QWY.mod.j:=leftArrow, which works fine if this macro is executed in real-time:

$postponeKeys ifNotReleased ifNotPending 1 goTo @0
$postponeKeys ifPending 1 delayUntil 100
$ifNotReleased ifPending 1 final holdKeymapLayer QWY mod
$holdKey ;

I use another macro on the ' key to eleminate the default dead key behavior of the US international keyboard layout, as I do not need it on this key:

$postponeKeys tapKey '
$postponeKeys delayUntil 250 //necessary against lost quotes in Ubuntu HyperV-VM.
$postponeKeys tapKey space

In coding, I often enter '' or "" first, followed by leftArrow, before I write the actual string contents. If I now enter the sequence '->'->;->j fast enough, I do not end up with the intended '|', where | indicates cursor position, but I get '';j| instead. More precisely, this happens if I release the ; key before the line $ifNotReleased ifPending 1 final holdKeymapLayer QWY mod is executed. This problem can be made easily reproducible by using delayUntil 1000 instead of delayUntil 250.

The cause is that the execution of the macro on ; is postponed and when finally playing it back, ; has already been released. From a time logic point of view, what I really want to test for secondary resolution is that ; was released at least 100ms after the press event of j (independent of for how long these events were postponed). How could this be achieved if the macro is not executed in real-time, but postponed?

Hi, I tested some macro ideas towards fast&reliable secondaries for alphabetic keys without having to move my fingers far away from the base row. I tried implementing a 2-finger gesture for a mod key, but I failed to make it reliable, even when using low level commands like $postponeKeys ifPending.... I narrowed the problem down and found that with fast/simultaneous key presses, sometimes the second key press is not postponed, although this is the first command of the macro for the first key press. Instead, the second key press triggers a concurrently running macro (broken mutex). (In hindsight, this might also explain a certain type of unreliable behavior I had with rocker gestures discussed in an older issue.)

These are two minimal macros to reproduce the problem:

• on the c key:

$postponeKeys setReg 20 1
$postponeKeys ifNotRegEq 21 1 goTo @3
$write Mutex 21 broken despite postponeKeys
$goTo @2
$tapKey c
$setReg 20 0

• on the v key:

$postponeKeys setReg 21 1
$postponeKeys ifNotRegEq 20 1 goTo @3
$write Mutex 20 broken despite postponeKeys
$goTo @2
$tapKey v
$setReg 21 0

When pressing c+v with two fingers simultaneously, I sometimes get:
MMuutteex 2210 brrookkeenn ddesspiitte ppoossttppoonneKKeeyyss. I think that this should not happen, i.e. when the first command of the macro for the first key press enables postponing, then the second key press should never have a chance to still trigger its macro, even if both keys are hit near-simultaneously with two fingers.

"hold last layer" implemented via "switch last keymap" misbehaves when combined with "toggle/hold keymap layer"

Refactoring postponer has changed semantics of "suppress" to "postpone". Fix it.

Allow press/tap/hold/release commands to trigger non-alphanumeric keys.

I have got the UHK in ISO layout, that means left-shift keycap is split and there is an additional key. The keycap displays "\ |", in agent, the scancode is "| ISO".

In the grammar you list almost all keys in KEYABBREV, but the ISO key seems missing. Through trial and error I have discovered that nonUsHashmarkAndTilde seems to be the right thing to use.

I expected that KEYABBREV mirrors what's available in Agent, if only for consistency reasons.
Please add "pipeIso" (or some such) as a synonym for nonUsHashmarkAndTilde, if that is the right key.

Hi, I can't make suppressMods work on macOS 10.14.5

1. If you're using Karabiner Elements on your Mac, close it!

   Done.

2. Install the latest Agent:
   https://github.com/UltimateHackingKeyboard/agent/releases/latest

   Done.

3. Use Agent to update to the latest firmware:
   https://github.com/UltimateHackingKeyboard/firmware/releases/latest

   Done.

4. Try to reproduce the issue, and only report it if it still persists.

• Create a macro:

  $ifAlt suppressMods tapKey a
  

  $ifNotAlt tapKey b
  

• Assign the macro to the key a

• Press a
  Expected output: b
  Actual ouput: b

• Press rightAlt + a
  Expected output: a
  Actual output: å

Am I missing something?

delayUntilReleaseOr <time in ms> command would wait until either the activation key is released or the timeout is reached.

This would be useful in assigning keys to secondary roles without disallowing to hold the primary role. E.g.:

$switchLayer fn
$delayUntilReleaseOr 250
$switchLayer previous
$ifInterrupted break
<press Enter>
$delayUntilRelease
<release Enter>

The idea is that mouse position is reset to (0,0), then activation times of mouse are recorded and later replayed, so the mouse movement happens in "real time" and is not affected by device driver's acceleration/deceleration rules.

• How should simultaneous activations of different mouse movements be handled?

To allow toggling and untoggling layer via same key, e.g., if layer is to be toggled via secondary role...

Followup of UltimateHackingKeyboard#299 .

Writing goTo adresses is tedious once more complicated gesture maps are being implemented.

$<identifier>: at the start of a line would identify the line

Argument of goTo could then be either a number or a label.

I've been trying for hours to figure out how come I can't get the example Double Tap to Caps Lock example to work! I've tried both the new version and the old version. Oh, I'm also on a Mac.

I'm fairly certain I'm doing everything correctly because I created another macro that works fine (Mod+C to close tab, Mod+Shift-C to reopen tab).

I thought it might be a conflict with my Better Touch Tool, but I disabled the software and it's still not working.

The Shift part works. But the Double tap does not.
I've even tried on a different key other than Shift, and Double tap still doesn't work.

Is it possible to write value of register?
Something like
$setReg 0 10
$write #0 -> should result in 10 being output

Simplest use case:
Output sequence of numbers like 1,2,3,4,5..
Why not just create macro containing write commands for each number in a sequence?

1. There are a lot of numbers in this sequence so it would be nice to reduce number of commands in the macro
2. My use case is not simplest one, it actually includes 60+ commands that would have to be repeated with only one of them being write command with variable number

What I made so far:
I've copied the macro 40 times (because of sequence of 40 numbers) and hardcoded values inside of that write command but 2400+ commands are making agent less responsive and if I have to change one thing in that 60 actions requence I'll have to reapply it 40 times

How I could improve it:
Enclose part that has to be repeated within a loop.
Then for that 1 write command with variable part I should create 40 different write commands and use condition (check register equality) to trigger one of them in each iteration of a loop
In this way, I could prevent copying of rest of the macro

Writing down keyids is tedious, and keyids are not guaranteed to remain without change - actually, due to memory concerns, they will almost surely have to change.

So backward transformation from EN_US ascii chars to KEYIDs could be written and employed to parse KEYIDs.

UltimateHackingKeyboard#256

Here is an (untested) idea for a virtual mod key composed of two physical keys, triggered by a 2-finger gesture. The rationale is to get an easy, reliable and quick activation gesture for secondary actions on alphabetic keys. It should almost never interfere with normal typing and gives us arbitrary mod keys without having to move fingers far from the base row.

• trigger: press the 2-finger-mod (e.g. c+v) simultaneously and support an arbitrary press order. I.e., we either receive pressC->pressV or pressV->pressC, without any other interrupting key event.
• then, resolve as secondary if:
  • at least one trigger key is not yet released AND
    • either a third keyPress is received
    • OR at least one trigger key is pressed longer than 500ms. This delay is important to cancel a secondary action without receiving unwanted typing actions; in this case, the user just must not release the two-key-mod too early.
• if resolved to a secondary action: First, consume the two postponed trigger keys. Then, either implement the action directly in the macro (faster) or hold a keymap layer until both trigger keys are released (more flexible, as it allows implementing all actions for possible third keys like copy/paste actions or other macros on GUI level in Agent).
• normal typing in all other cases, i.e. goTo $postponeKeys holdKey thisKey (postponeKeys should be used everywhere to assert the correct processing order in concurrent smashing cases)

Example gestures:

• An easy time line example would be to hold(c+v), tap(j), release(c+v) => play action on MAK.mod.j. But I would also like to enable one of the trigger keys as third keyPress, i.e. allow a dual role as actionKey, e.g.:
• Hit c+v in arbitrary order (semantics of one logical mod key composed of two physical keys), releaseV, pressV, release both in arbitrary order => map to an action, e.g. LCtrl+V. So, between releaseC at the end and pressC at the beginning (assuming it came after pressV), we have at least two events (a release and a press). This should be enough to disambiguate it from normal typing of cvv in almost all cases.

[Ideally the following additional failsave logic is not necessary at all, but it will require testing:] On top of this base idea, it might be possible to rescue all cv. and vc. tripletts for normal typing, if the . means a third key that is not mapped to any defined action (and if both trigger keys are released faster than 500ms). This does not have to be an inefficient lookahead (changing the keymap for if branching), but instead possibly could be realized with a generic return macro on the target layer, for all keys that were previously assigned the none action. But this would not be trivial (undoing the consumePending of the two trigger keys in the correct order...) and hopefully totally unnecessary, thanks to the more elaborate trigger logic.

Version 8.5.4 of the official firmware fixed an issue where:

• Make the modifiers of shortcut keys stick only as long as the layer switcher key of a shortcut key is being held.

However this version of the firmware still exhibits the issue. To reproduce, remap a Base layer key to control anything, it most annoys me in a browser, so try control-w for close tab. Close a tab with the remapped key, then click on any link. It will control-click the link. The held state can be cleared up by tapping Mod.

Note that remapping on the Mod layer doesn't cause the problem, as releasing Mod clears up the held state before you have a chance to click anything. If you remap Mod-W to Control-W, then holding Mod down, tapping W then clicking a button after releasing W but before releasing Mod will Control-Click.

I have reproduced the behavior with Alt and Super Base layer remappings.

Flashing back to latest vanilla fixes it, while flashing back to 8.5.3 brings back the issue.

Hold layer concept currently suffers a few unwanted side-effects due to the nature of the layer stack. The three command sequence could be refactored into one command, which would also keep track of the corresponding keys and be able to solve conflicts (like recursive holds being released in different order).