Unreliable remappings with modifiers using RDP (timing issues)

[orthoceros]

First of all, thanks for UHK! I have an ANSI UHK (QUERTY) and use the English US/international keyboard layout in Windows 10. This keyboard layout includes German umlauts, e.g. ü for AltGr+y (= RAlt+LCtrl+y). I am trying to remap Fn+u=ü, Fn+o=ö and Fn+a=ä. If shift is pressed, it should result in ÜÖÄ, respectively.

• First attempt: If I directly remap the u key to scan code RAlt+LCtrl+y, then it works on the host PC, but only sometimes through RDP (the Windows 10 in the remote desktop window has the same ENG/Intl keyboard layout enabled). Often, I see a "y" entered instead, i.e. the RAlt+LCtrl modifiers are not transferred properly through RDP.
• Second attempt: Intended as a workaround, I then defined a macro: "press LCtrl + press RAlt + delay 0.1s + tap y + release RAlt + release LCtrl". While this works reliably through RDP (it always enters ü for Fn+u), I now cannot enter capital Ü via Shift+Fn+u, which worked with the first attempt (sometimes again...often I got a Y instead in the RDP window...).

This is just one example. I noticed similar problems with other custom and default remappings through RDP, too (for example, I remapped Mod+< to LCtrl+z for undo, but often got just a z entered instead, i.e. no LCtrlDown in the RDP window, at least not in time). How does the press/release/delay logic work for keys remapped with modifiers? Can this be tweaked somewhere to work more reliable with RDP/remote desktops? I would also be interested if the macro workaround could be expanded by some if/switch logic, depending on the current state of shift.

Thanks.

[kareltucek]

I would also be interested if the macro workaround could be expanded by some if/switch logic, depending on the current state of shift.

If you don't fear custom firmware hacks, you might like to check out https://github.com/kareltucek/firmware.

Second attempt: Intended as a workaround, I then defined a macro: "press LCtrl + press RAlt + delay 0.1s + tap y + release RAlt + release LCtrl". While this works reliably through RDP (it always enters ü for Fn+u), I now cannot enter capital Ü via Shift+Fn+u, which worked with the first attempt (sometimes again...often I got a Y instead in the RDP window...).

I think that this should work on the custom firmware too. The thing is that while a macro is running, all key handling is skipped in the official firmware. On my firmware, macros are being run asynchronously.

[kareltucek]

How does the press/release/delay logic work for keys remapped with modifiers? Can this be tweaked somewhere to work more reliable with RDP/remote desktops?

As far as I understand things correctly, when a key is held, it is being added into a state report, which is being sent to PC every few milliseconds (or maybe on state change only - that's what I am not sure about atm). The reason why RDP misbehaves is apparently that the modifiers are added in the same report as the action key and not earlier (which would be the case if a real human pressed the keys). However, I have no idea why it is a problem for RDP.

Would you try the following firmware? It is the official firmware with just one little tweak - it postpones adding keystrokes by one report if modifiers are not null. firmware.zip

Also, you might have some luck searching old issues - I remember this being reported before....

[luteijn]

As far as I remember, when you bind a key on uhk to send a modified key (e.g. map Fn+Y to send lctrl-ralt-y), there are also no intermediate reports sent with just the modifiers added one by one , then the key, and then breaking it back down, like a natural pressing of such a chord would be. So one moment the report is empty, next it will be Y pressed, modified with lctrl and ralt - followed by a report saying 'nothing pressed' again.

This usually gets interpreted correctly by the directly connected OS, but I can imagine it going wrong when pushed through a second layer of software, like RDP, which probably does its own processing of these reports to turn them in to a 'one key changes state at a time' sequence, and might end up sending something like Y pressed, left control pressed, ralt pressed. That's why things like the macro that more closely mimics real timing of such chords works well, and why Karel's firmware will likely also fix it.

Shift becoming its own layer would help the official firmware to be able to send a different macro for shift-fn-Y (which could then include the shift modifier along with the ctrl and alt-graph modifiers)

Moving to using macro-functionality outside of the keyboard to something like AHK, or , with Fn-Y sending some unique scancode/sequence for the macro-expansion program to trigger on might be the easier way to do things like this. I used to do something like that in the past, with a barcode reader that I set up to prepend something like 'ctrl-G[' and append ']' to whatever sequence it read and injected in the keyboard buffer. Then the macro handling software could trigger on that sequence and do something based on the barcode read, like add one to an internal counter software register, emit the current value of the counter, select a certain window and send commands to it etc.

[orthoceros]

Wow, already three great replies with lots of useful info; thank you! :) I will process it and try the new firmware from above this weekend and then report back. I also read the docu of your firmware with the extended macro language. Sounds very useful; I will try it, too. Does its latest version (uhk-firmware-8.5.3.kt.7.tar.bz2 from 14h ago) already contain the same "one little tweak" for the non-macro remappings? (Then I would directly flash and test this one.)

[kareltucek]

No, it does not. The code (one line to be exact) can be found on branch https://github.com/kareltucek/firmware/tree/871 . I will decide whether it is a good idea to merge it into master depending your feedback and on reply of UHK devs. I think that it should be tested on official(-like) firmware first, and that merging it into origin/master should be discussed prior to merging it into my master.

(Somehow I have a feeling that if it were this simple, official firmware would already have contained a fix.)

[orthoceros]

Hi, I have tested your "v8.5.3 + little tweak" firmware today and it is MUCH better than before, but still not 100% reliable. More precisely, I have tested Fn+u => LCtrl+RAlt+y == ü on Win10 with US/Intl keyboard layout. Likewise, Fn+o => LCtrl+RAlt+p for ö and a remapping for ä:

• on the host and tablet (direct USB connection) it works always, also with shift like (shift+)Fn+u=üüüüüüüüüüüüüüÜÜÜÜÜÜÜÜÜÜüüüüüüüüüüüüüüüÜÜÜÜüüüüüüüüüüüü
• via RDP from host to VM: almost 100% reliable now (was ~50% before the tweak)
• via RDP from tablet via WLAN to the same VM: only ~70% reliable. Often I get Ctrl+p==print instead of LCtrl+RAlt+p==ö; see screenshot with tracked modifiers below (the bottom onscreen keyboard is osk.exe running on the tablet, the upper one runs within the RDP window on the VM and did not receive RAlt):

[kareltucek]

Hm, that's bad. I think that it is better now only due to the delay cased by adding the key one cycle of the event loop later - i.e., due to the same effect you use in the macros.

Which means that the only working solution is really to introduce an artificial delay. I think that I could do that on my fork - the delay would be configured via macro engine and set by default to something like 50ms (and take effect only when modifiers are not null). Let me think about it for a few days.

What is the result if you define the macro the same way (i.e., with modifiers pressed in separate action from tap of the action key) but without the delay?

I assume that if you use the macro with the delay, but lower the delay, it will start misbehaving - is that right? How low can you go?

[kareltucek]

I've just added a delay mechanism on my fork. You are welcome to try it out (default delay is set to 10 ms; the value can be set via macro commands).

[mondalaci]

This is the second issue of its kind, but unfortunately, I can't find the first one. The way I see it, this is an application-specific issue. For some reason, RDP delays the activation of modifiers. I think it's a fundamentally bad approach to work around application-specific issues on the firmware level.

It'd be worth to find out whether this issue affects the RDP client or the server. In the former case, using a different client may be the ultimate (pun clearly intended) solution.

[mondalaci]

I'm closing this issue, because given the above, it's hardly a UHK issue, but feel free to follow up. I'm interested whether this is a client or server-specific issue, and in the former case which clients are affected.

[kareltucek]

Well, the way I see it is that sending multiple new keys within a single report to be a phenomenon enough rare and unexpected (w.r.t. other software) that considering it as UHK's issue is not entirely unreasonable.

Especially if we consider possible view of RDP devs - for them, this could easily be an "exotic issue whose fixing would affect few" (pun clearly intended).

[mondalaci]

Sending multiple new keys within a single report is completely legit as far as USB is concerned. If it's not handled well by an application, it's clearly an application bug.

[kareltucek]

I am not arguing against that - I am just pointing out that we don't live in a world in which limiting our concerns to technical specs is always the best solution.

[orthoceros]

Guys, you are too fast for me (or my research week is just too busy... ;)

As an intermediate result: I am still working with the "official+little tweak/no delay firmware" via RDP on a Hyper-V host (Windows Server 2016, integrated terminal server client via ActiveX or mstsc.exe). I have written a lot of code and text in the last few days through RDP into my work VM and did not have a single missed modifier so far from the remapped keys. So, it has definitely gone from "UHK is not usable for RDP" to seemingly 100% reliable. That's very good! However, I cannot say anything new about the harder "RDP via slow WLAN" scenario from my tablet, yet. I will try to find some time for tests and playing with macros and delays next weekend.

I wonder: Maybe it is not RDP alone, but the OS-integrated Alt+Shift pure-modifier hotkey that Windows uses for switching between installed languages? This is probably implemented as some kind of low level keyboard filter and might need a frame or two... So, maybe it isn't a delay issue at all? I mean, maybe it would be enough to send each single modifier in a separate event report without any delay? I.e. "press LCtr + press RAlt + press key..." instead of "(press LCtrl+RAlt) + press key...". Or did the little tweak already break down each single modifier activation/deactivation into single events? (Sorry, I did not yet have the time to read and understand your source code...)

[kareltucek]

Or did the little tweak already break down each single modifier activation/deactivation into single events?

On the "official+little tweak/no delay firmware" , the tweak sends all modifiers in the "first" report, and then modifiers+key in the "second" one.

I mean, maybe it would be enough to send each single modifier in a separate event report without any delay?

I think that if it was the case, the behaviour would be deterministic. Anyway, you can test that via macro engine - each macro action is evaluated in different event-loop cycle, which also means in different USB reports.

Sorry, I did not yet have the time to read and understand your source code...

No problem and I don't you expect to do so (links were posted for reference of those who might possibly be interested).

[luteijn]

In reality it is almost impossible to press down two keys (modifier or 'general') exactly at the same time, even if you wanted to. You can (and in some case want) to get them 'very close' together in time, but when doing this and trying to hit them exactly at the same time, then it is should be impossible (and not really matter) to which one was first. So, I don't think the keyboard should ever try to pretend simultaneous changes of state of more than one key happen, it is asking for race conditions to bite you.

Old-fashioned ps/2, AT, XT and even MIDI keyboards send a serial stream of key up/down events, no events are ever really simultaneous, so no software should depend on this -> sending separate updates shouldn't break anything.

Even though the USB protocol allows for simultaneous key-state changes, it can only cause issues and grief to use it. It might solve some latency issues but generally I think it is a bad idea, and to me fixes something that was never really broken. So, I would suggest to add no artificial delays between updates, but just always change only the state of one key between reports.

[kareltucek]

That sounds very reasonable except:

1) Unlike the simple timer, it would bring hell lot of additional complexity into the code.

2) According to orthoceros's report it does not necessarily solve the problem of the one app which we know is suffering from this bug. (The WLAN case.)

Yep, in this light I admit that the timer is a bit hacky solution, but I think that it is the best tradeoff between solving actually existing issues and keeping it simple. Anyway, considering the last report, I will be lowering the default delay to symbolic 1ms, which will practically act just as the "official+little tweak/no delay firmware".

[orthoceros]

Some more results (still the same official+tweak firmware and direct RDP to VM; no tablet/WLAN testing, yet; will do this at home next weekend). I tried to create a macro today that shows the size of a selected variable in Matlab. It copies the currently selected variable name (via LCtrl+C), changes from the editor to console (LCtrl+0), enters "size(", pastes the variable name (LCtrl+V), enters ")+Return" and goes back to the editor (LCtrl+LShift+0). Results:

• If I use tap events containing the modifiers, the macro always fails. Most often, it immediately overwrites the selected variable name with a "c" from LCtrl+c.
• If I split modifiers in pressModifier+tapKey+releaseModifier, control hotkeys always work as expected. There are no delays necessary in the macro.
• Notably, I fully dissected LCtrl+LShift+0 into pressLCtrl+pressLShift+tap0+releaseLCtrl+releaseLShift. It does not work reliably, if it is just pressLCtrl+tap(LShift+0)+releaseLCtrl.
• Importantly, it is still not reliable, as the "write text" macro command is also affected from the same fundamental problem: I get the intended text "size(copiedVarName)" only in ~50% of all retries. Instead, I get something like "size(copiedVarName0" or "size9copiedVarName)".

This actually seems quite logical to me: if a modifier is reported simultaneously with another key (that could also be another modifier like in the report="LCtrl+LAlt"), then this event simply does not contain any information, which of the two keys was pressed first. Windows may also process it as "LAlt+LCtrl" instead, which most software will treat identically anyway, as luteijn already pointed out. In the problematic case above of entering a "(", applying the same logic, the report may be processed like "9->LShift"==9 instead of the intended "LShift->9"==(. This unintended interpretation seems legit to me, unless each USB report also defines an inner order of key events...?

[kareltucek]

Yes, that all could be expected. At this point, I am namely interested in the tablet/WLAN testing (ofc take all the time you need).

I should probably explain that the tweak is implemented only in the key action handler in the update reporter. That means that it does not affect any macro actions, and it does not even affect the key macro action. The new timer is implemented in both update reporter key action handler and in macro key action handler, but not in the macro text action.

Originally, I did not consider implementing the timer into macro text action and macro recorder important, but now I see that it would be probably be good thing to do. The macro text action could use heavy refactor anyway. But neither of these are high priorities for me atm.

Btw, do you use the macro text action often? What are the usecases? (I have not encountered any sensible usecase for that so far... apart from misusing it as a command container.)

[luteijn]

I'd not rely on write text to write anything else than 'tapping' simple single keys one by one. So, split out '( ' into 'shift down', 'tap 9', 'shift up'.

Changing reports to send modifier up/down separate from keys will probably also improve behavior of modifiers as secondary key function, I often get / instead of ? currently...

[kareltucek]

!@#$%^ I did not realize that the problem would affect secondaries too.

[orthoceros]

Hi, sorry for my late reply, but times were&are busy and I wanted to be sure: On the tablet, neither WLAN nor UHK (with the "little tweak") were the problem, but AHK (AutoHotkey): I had defined keyboard combinations like:

        <^>!s::
            Send, ß
            Return  

With these global AHK hotkeys activated, I was even able to get a sticky LCtrl on the tablet locally when entering a hotkey combination via its onscreen keyboard (osk.exe)... I.e., a software issue even before sending keys through RDP. On the host, still no problems via RDP since the "little tweak". And after disabling/exiting AutoHotkey, UHK remappings also work well from the tablet through RDP via WLAN. So, the "little tweak" seems to have solved it after all! :)

Btw, I also found that it suffices to remap, e.g., Mod+u=>RAlt+y to get an ü with an US/English International QWERTY keyboard layout in Windows 10. I.e., you can replace the AltGr key by RAlt only (just one modifier). You do not need to also send LCtrl (although usual keyboards send and the capture feature shows AltGr==LCtrl+RAlt). This also helps if you want to get ü,ä,ö via UHK remappings simultaneously for Windows and Linux VMs.

---

Btw, do you use the macro text action often? What are the usecases? (I have not encountered any sensible usecase for that so far... apart from misusing it as a command container.)

• If I understand you correctly, the text action is currently a separate case on firmware level? I only use it as a convenient shortcut to enter strings like commands in a macro (instead of creating many tap events manually in Agent). So, from my point of view, text actions are not necessary on firmware level: The Agent GUI could stay the same, but under the hood, Agent could just upload a sequence of tap events to the keyboard. Then, you could even flexibly add options like "insert xx ms delay between tap events" in the text macro dialog, without any firmware change at all.
• However, maybe this "GUI implementation" of text actions will need some silent actions in the sequence to store metadata/markup like "text action start/end", so that Agent can parse and show a macro correctly that has previously been stored on the UHK (i.e. a text action as one group and not as the long flattened list of tap events).
• Talking of markup, I sometimes misused the text action in unfinished macros to store TODO/testing notes. Such notes could remain in the final macro, if the whole text action would get a "silent" switch/checkbox.

  ---

  Sorry, no time yet to test your macro language with support for using the current LShift state in the macro. As I need the "little tweak" constantly now (working through RDP all the time), I will test this as soon as this little tweak (or something equivalent) has made it into the firmware including the extended macro engine. (In particular, I will try it for my anti dead key macros like Mod+'" => Tap'" + TapSpace that currently only works for ' and not " when holding LShift...)

Thanks, again sorry for my late reply and happy New Year!

[kareltucek]

• If I understand you correctly, the text action is currently a separate case on firmware level?

Yes. The entire string is stored within "macro text action" "data type", and the firmware translates it into scancodes and then "types" them.

• Talking of markup, I sometimes misused the text action in unfinished macros to store TODO/testing notes. Such notes could remain in the final macro, if the whole text action would get a "silent" switch/checkbox.

Sounds as a reasonable usecase, I think I will add '#' as special comment character.

this little tweak (or something equivalent) has made it into the firmware including the extended macro engine

Yep, the the configuration you are after is even the default.

---

General updates:

• In the meantime, I have refactored the solutions entirelly into two independent features:
  • Composite key separation, which does exactly the "little tweak" thing, except it does it with macro tap actions too.
  • Delay mechanism, which globally postpones event-loop evaluation for a given time after every USB-report-state change. This solution therefore affects even macro playback. (It does not slow down regular actions in average workflow, because the delay occurs only after a state change.)
• Also in the meantime, I have encountered another problematic app (a game), which failed to recognize "Esc" sent via secondary role. This was solved by setting the delay mechanism to 50ms. This case makes me confident that both decisions to add the features (in the forms in which they were added) were good ones.

[orthoceros]

Cool, great! Thanks! I will install the new firmware and try the extended macro engine at one of the following weekends. :)

[kareltucek]

You are welcome :).

[orthoceros]

Unfortunately, I have to report a regression: I tried uhk-firmware-8.5.4.kt.1.tar.bz2 today, but immediately noticed that all my remappings stopped working through RDP: The simplest ones are Fn+x/c/v => LCtrl+x/c/v. Instead of copying/pasting, they just entered the letters x/c/v. Also, a macro starting with "tap LCtrl+c" just entered c... I have now flashed back to "official+little tweak" (your firmware.zip from this thread with the little tweak from 2018-11-29) and all my remappings started to work again through RDP.

[kareltucek]

Oops, it seems that I have not set it as default after all. For the time being, use the following macro $setSplitCompositeKeystroke 1 (paste it into a normal text action and then use from keyboard).

[orthoceros]

I can confirm that remappings start working through RDP again with the newest uhk-firmware-8.5.4.kt.1.tar.bz2 firmware after executing the "$setSplitCompositeKeystroke 1" macro, thanks!

I noticed today that writing "size(" via a text action still inserts size9 in the RDP window (not on the host and it works when I replace "(" by a LShift+9 tap action). Could it be that the little tweak is still missing for the shift modifier within text actions?

Btw, is there an option to make Agent remember its last window size&position instead of automatically maximizing at start?

[kareltucek]

Yes, true. I Will look into that later.

[kareltucek]

Here we go https://github.com/kareltucek/firmware/releases/tag/v8.5.4.kt.2 , I think it should be ok now. And thanks for reporting the problem!

[ewancoder]

I have the issue described here over RDP when using the latest version of the firmware (8.10.+). I just upgraded from 8.6.0 and noticed the issue immediately. I have caps lock key mapped to escape and to control if it's used with another key, and Ctrl+S combination stopped saving the file, instead producing 's' character.

I downgraded to 8.6.0 and it works as expected, flawlessly. So I'm going to use this version for now because I heavily rely on RDP.

[kareltucek]

I guess this is caused by the following change introduced in 8.7.0:

• When a dual-role key is held and the secondary role gets triggered by another key, don't debounce the latter key.

Before that release, secondary roles suffered by a 50ms delay, which is what made RDP work flawlessly. Since fixing this bug, there has been just 0-4 ms delay between activation of secondary role and primary action.

Currently, there is 1ms delay (i.e., Ctrl is activated first and then after a short pause, S follows).

[UndeadKernel]

I'm also experiencing this "bug"/problem. @kareltucek does your fork address this issue? I've been thinking of just moving fully to use your fork instead of the official version.

[kareltucek]

@kareltucek does your fork address this issue?

Not at the moment. But I guess I can implement some solution again.

[ewancoder]

Can we get a configurable option of making a delay on purpose for these scenarios (rdp etc)? I don't mind using 8.6.0 though, I don't have any issues with it or a need to upgrade, but I'd like to be able to run the latest firmware.

[kareltucek]

Alright, here we go: https://github.com/kareltucek/firmware/releases/tag/v8.10.2.kt.1

The firmware now provides setKeystrokeDelay command.

TL;DR; on how to use it:

• flash the firmware
• create a macro with a text action containing $setKeystrokeDelay 25 (and maybe another one with $setKeystrokeDelay 0)
• use the macro whenever you need to turn the feature on. (The setting is not persistent, so you will need to activate it again after every powercycle of the keyboard.)
• For more detail see readme of the firmware and search for setKeystrokeDelay.

Btw, this feature seems very promising w.r.t. testing/debug too - setting it to a high value (e.g., 200) combined with https://keyboardchecker.com/ allows seeing features of the keyboard (such as macros, or extra usb reports) act in slow motion.

---

Can we get a configurable option of making a delay on purpose for these scenarios (rdp etc)?

To be clear, I can talk only for the kareltucek/firmware firmware fork. Regarding official firmware, firmware-side the feature can be merged quite easily if @mondalaci decides so. Still, merging it would require extending the configuration format and interfacing the option in the Agent, which I do not see very likely since it is a niche feature which basically just works around bugs of third-party software.

Reasons why not to restore the 8.6.0 state of affairs in default settings are following:

• 50ms delay "randomly" placed on one of the keyboard features is in my opinion a bug, not a feature.
• There are other features in the keyboard which suffer (and suffered even in 8.6.0) the same problem with RDP. For instance, any composite keystrokes (mod + scancode) or almost any macro action. So it does not make sense to delay only secondary roles while leaving other aspects of the problem untreated.
• Unlike 8.6.0, the feature in the fork fixes all of the mentioned problems by generically introducing delays. Of course, having these delays turned on globally would be unacceptable - especially for gamers.

[ewancoder]

Thank you very much. I understand how things are and why we need to use the latest firmware if possible and that it's a bug of RDP third-party software yet from a simple user's viewpoint it just looks like 8.6.0 works perfectly well (without a single issue) when the latest official firmware doesn't (since I currently use RDP 100% of the time, just interfacing from my slow laptop to my own powerful PC). I was also not aware of any issues that 8.6.0 had and never encountered them during my usage of UHK that's why I was completely content to use this version.

I will test your fork v8.10.2.kt.1 version shortly (in a matter of a few days since I don't have by UHK near me for now) and let you know if it works for me.

[ewancoder]

Works like a charm, thanks!

[kareltucek]

Works like a charm, thanks!

Thanks for confirming!

[ewancoder]

It would probably be nice to have an option to save it so it's on by default. Is there any (hacky) way to do it?

[kareltucek]

I prefer to have an "init" keymap set as default. This keymap has space mapped to a macro which sets my configurations and then switches to the standard keymap. So whenever I reconnect my keyboard, first thing I (have to) do is to tap space, which sets up everything.

The init keymap is quite handy, because it also contains switches to all other keymaps, so all other keymaps need to contain only a link to this init keymap. This saves a lot of confusion with keymap switching due to out-of-date mappings...

[ewancoder]

Hm, thanks. This is actually brilliant! :) Going to do the same.

[GrauLab]

I can confirm that $setKeystrokeDelay is quite essential with newer firmwares, as my UHK became unusable when working in Hyper-V VMs or via RDP.

quantitative test results

I defined 1) Fn+a :=Agent action RAlt+LShift+p (which should yield an Ö on US international keyboard layouts) and 2) Fn+s := $tapKey RALS-p, i.e. the same via a macro action.

Then I held Fn and hammered a or s in Notepad++ in a guest Win 10 for different $setKeystrokeDelay x, using an enhanced session mode RDP connection on an up-to-date Windows Datacenter Server 2019 LTSC host:

x=0ms:
1) pppPppPppppppPpppppppPpppPpPppppppppPppppppppPpppppPpppppppppPpppppppPpppPPpppPppPpppPP
2) PppppppppppppppppppppppPppppppppppPppppppPpppPppPppppPppppPpppppPPppPpppppppppppppppppp
x=1ms:
1) pppppppPpPpppPPPpppppppppPpppppPpPPpppppppppppppPpÖppPÖppppPpPÖÖpppÖPpppppppppppppppppP
2) PpPppppPPppppppppppPppppPpppppppppPPpppppPpPpppppppPppppPpppppppPpppPppPpppppPppÖppÖÖPp
x=2ms:
1) ÖÖÖÖÖÖpÖÖPÖÖÖÖÖÖÖÖÖÖpPpÖÖÖPÖÖpÖÖÖÖÖÖpÖÖÖppPÖPÖppÖpppppÖÖÖÖÖpppppppPpÖppPPÖpPppÖÖÖÖÖpÖÖÖ
2) ÖÖÖÖÖÖppÖÖpÖÖpÖppÖÖÖppÖÖÖppÖÖÖÖÖpÖpPppppÖpÖppÖpppppPÖÖÖPppÖÖÖppÖÖppÖpÖpÖÖÖÖPppÖÖÖÖÖÖÖÖÖ
x=3ms:
1) ÖÖÖÖÖÖÖÖÖÖÖÖÖpÖÖÖpÖPÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖpÖÖÖPÖÖÖÖÖÖÖÖÖPÖÖÖÖÖpÖÖÖÖÖÖÖÖÖÖÖÖÖpÖÖÖÖÖÖÖÖÖÖÖÖÖ
2) ÖÖÖÖÖÖÖÖÖÖÖÖÖPÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖppÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖ
x=4ms:
1) ÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖ
2) ÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖ
x=5ms:
1) ÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖ
2) ÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖ

So, 4ms was the minimum; I am now at 5ms for reliability. (There was no visible difference between agent and macro based actions.)

test over network

To test whether this issue might also be network dependent, I started a normal (non Hyper-V) RDP connection to my Win 10 tablet (also up-to-date) and repeated the test in this client's Notepad++:

• via WLAN (ping ~1ms)

  0ms: ppPpPpPppPppPPppppppPpppppppPpppppp
  3ms: ÖÖÖÖÖÖÖÖÖÖpÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖpÖÖpÖÖÖ
  5ms: ÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖ

• via LTE=>VPN1=>VPN2 (ping ~200ms):

  0ms: pppPppppppppppppPppppPppPppppPPpppP
  5ms: ÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖÖ

  So, fortunately, the issue did not scale with ping delays. Really puzzled though where this 5ms threshold comes from (host idle, 4GHz, 16 threads, tons of RAM...)?!?

default init

Yes, the idea with an init keymap and an autoexec macro on space is great; thanks. I will configure $setKeystrokeDelay 5 there, now. If others can confirm this low 5ms threshold, you might consider making this the default after all. A pro tool like the UHK should first and foremost be reliable imho. Compatibility with not-so-rare scenarios like RDP-ing is important, even if the issue can be viewed as an external bug. Besides, 5ms are physically negligible given that any composite action has to be manually kicked off with your hand, first. Or can you type 200 keystrokes/s?😉 (High speed gamers could still use extreme tuning to $setKeystrokeDelay 0 if they really think it helps them win...)

[ewancoder]

Any news about this? I recently needed to heavily start working with RDP now and I'm using the latest stable firmware, not the custom @kareltucek provided. Did we have something like that implemented in the main software or I'm gonna need to flash custom one again?

[ewancoder]

Ah sorry disregard my comment, I didn't follow your linked feature request. I assume it has been incorporated in the main software seeing as the request is closed now.