kareltucek / firmware

This is fork of UHK's firmware featuring extended macro engine.
Other
82 stars 9 forks source link

tapKeySeq does not release modifier at the end #101

Closed provinzio closed 2 years ago

provinzio commented 2 years ago

I want to enter the Alt+ code Alt +20AC and use the macro $tapKeySeq pLA- keypadPlus np2 np0 a c rLA- for that. Sometimes the Alt button gets not released after the sequence, but I don't now why.

The Alt Code should become . Somehow, when I trigger the button multiple times, sometimes I get a space, sometimes and sometimes Ȋ which is Alt+20A.

Any ideas? Could this happen, because Alt+C is a shortcut in most applications, which does something odd with the UHK macro? Nethertheless, the Alt should be released...

Edit: The error does not occur, when I "enter the scancodes separately" (see image below) grafik

kareltucek commented 2 years ago

Please, try to set set keystrokeDelay 25, for instance at the beginning of the macro, and report back whether it helps or not (with missed keystrokes).

Regarding alt, are you sure that it remains actually pressed? Many applications produce similar behaviour when alt is simply tapped (alone without another key). If yes, are you pressing any layer switcher?

provinzio commented 2 years ago

Please, try to set set keystrokeDelay 25, for instance at the beginning of the macro, and report back whether it helps or not (with missed keystrokes).

I'll report back.

Regarding alt, are you sure that it remains actually pressed? Many applications produce similar behaviour when alt is simply tapped (alone without another key). If yes, are you pressing any layer switcher?

Yes, I am sure. After activating the macro, I can sometimes trigger Alt+letter commands in arbitrary software and can not type letters. I leave this state with the diagnose macro.

No layer switching. Everything happens in the base layer.

provinzio commented 2 years ago

Tested again without and with keystrokeDelay.

$tapKeySeq pLA- keypadPlus np2 np0 a c rLA-

result: `ȊȊ€ €ȊȊȊ€ȊȊȊȊȊ€ȊȊȊȊ  Ȋ€  €€Ȋ€ȊȊȊȊȊȊ  ȊȊ€ ȊȊȊ Ȋ ȊȊ€Ȋ€ ȊȊ €`

Without keystrokeDelay, I had it once times, that Ctrl was kept pressed after the command. I really don't get that... The command shouldn't trigger Ctrl at all. After tapping the macro a few times (with delay in between), I ended up with Ctrl all time active and could use Ctrl+c etc. by just pressing c and was unable to type letters. (Edit: tested some more, and can not reproduce this, I don't know what leads to keeping the modifier keys pressed). Most of the time Ȋ was produced instead of , but without any other issues.

$set keystrokeDelay 25
$tapKeySeq pLA- keypadPlus np2 np0 a c rLA-

result: ` ȊȊȊȊȊ Ȋ ȊȊȊȊȊȊȊȊȊȊ ȊȊȊȊȊȊȊ Ȋ Ȋ Ȋ Ȋ€€ €ȊȊ€€ ȊȊ€Ȋ€€ȊȊȊȊȊȊȊ`

With keystrokeDelay, I had no issues with kept pressed modifiers, but still problems evaluating the Alt + Code.

Edit2: Keeping in mind, that the "manual" entry of single scancodes in agent does everything as excepted, I find it difficult to understand, why the tapKeySeq does not work. I hope you have an idea here.

Edit3: Tested with keystrokeDelay 50 and modifier Ctrl was kept pressed after the macro. So this seems to happen with longer keystrokDelays, too.

kareltucek commented 2 years ago

I finally managed to reproduce the problem, and it seems like I had forgotten to have had fixed related problem since last release.

So uhk-firmware-v8.10.12.kt.3.tar.gz should fix the problem.

Thanks for your collaboration!