Keyboard rate does not use the FilterKeys setting (>30 keys per second)
NeKJ opened this issue · 11 comments
Windows keyboard rate setting goes up to ~30 keystrokes repetitions per second. But there is another setting that overrides this behavior and can go up to 100+, by using Filter Keys.
This is controlled by the following registry keys:
[HKEY_CURRENT_USER\Control Panel\Accessibility\Keyboard Response]
"AutoRepeatDelay"="200"
"AutoRepeatRate"="16"
"DelayBeforeAcceptance"="0"
"Flags"="59"
(AutoRepeatRate here is in ms, which means 1000/16 = 60 keystrokes per second)
More information:
https://superuser.com/a/509811
https://geekhack.org/index.php?topic=41881.0
As far as I understand, this doesn't affect the event rate which touchcursor is receiving the low level keyboard events, therefore if the Filter Keys has been set to 60, then touchcursor repeats at a rate of 30, whereas the rest of the keyboard has a rate of 60.
This is somewhat annoying for people like me who are used to high repeat rates, it's getting difficult to navigate using two separate rates.
Is there a solution to this, so that touchcursor can match the same rate as the Filter Keys setting?
...
touchcursorrepeats at a rate of 30, whereas the rest of the keyboard has a rate of 60.
Do you mean that the key events generated by TouchCursor while Space is held repeat slowly, and when using the keyboard normally the keys repeat fast?
It's probably down to the order in which the keyboard hooks are installed, and it's hard to control that. TC tries to be at the front of the queue. Otherwise other hooks can stop it working. This could perhaps be made optional.
Yes sometimes this is the behaviour as yo describe it,but other times it works well, so I'm not entirely sure how to reproduce this consistently. As you said, it probably has to do with the hook order of the hooked functions.
...
touchcursorrepeats at a rate of 30, whereas the rest of the keyboard has a rate of 60.Do you mean that the key events generated by TouchCursor while Space is held repeat slowly, and when using the keyboard normally the keys repeat fast?
It's probably down to the order in which the keyboard hooks are installed, and it's hard to control that. TC tries to be at the front of the queue. Otherwise other hooks can stop it working. This could perhaps be made optional.
This is still bothering me and I want to fix it. Would you perhaps give me some pointers on how "it tries hard" to be in the front of the queue in order to modify that code and test it out? (I have already setup my dev environment and have built it)
I built the code, and commented out the "rehook" call and tried it. But unfortunately, it still manages to stay on the front of the queue. Is there a way to move it to the end I wonder?
Glad to hear you got it building and managed to find the right bit of code. I suppose this may mean that the original hypothesis is wrong and filterkeys isn't using a low-level keyboard hook. It's not clear to me what TC should be doing differently at this point. Let me know if you make any progress!
You are right, it's not clear what can be done about this. I am not very familiar with the win32 hooking system in order to debug this in depth. So, at this point, I will have to stop trying.
After a few hours of debugging I managed to find the cause and how to fix it:
in dllmain.cpp line 192
// Sleep(1) seems to be necessary for mapped Escape events sent to VirtualPC & recent VMware versions.
// (Sleep(0) is no good)
// Also for mapped modifiers with Remote Desktop Connection.
// Dunno why:
Sleep(1);
the Sleep(1) is causing the delay of the key events. Using Sleep(0) instead, the rate of the injected keys is the same as the rate of the real key events (~64) and everything works well. I read the comment which states that there are some issues however I tried a remote desktop connection and tested many key combinations and all of them worked correctly. Also no issues with the rate.
I am not sure though what do you mean by "mapped modifiers", or "mapped Escape events", so I may need to understand in order to correctly test this.
Anyway I will use it as it is now and will report back if I found any issues.
Hi. Glad to hear you found the problem. The comment about "mapped modifiers" I think means when you have (shift/crl/alt/win + generated key) generated in response to, e.g., (space+pressed key).
It's possible that the behavior of these VMs and RDC programs has changed since that workaround was added.
After a few hours of debugging I managed to find the cause and how to fix it:
Sleep(1);the Sleep(1) is causing the delay of the key events. Using Sleep(**0**) instead, the rate of the injected keys is the same as the rate of the real key events (~64) and everything works well. I read the comment which states that there are some issues however I tried a remote desktop connection and tested many key combinations and all of them worked correctly. Also no issues with the rate.
Can you please upload the corrected version publicly? I can't find the lib files for my OS for this version of wxWidgets.
@martin-stone Could you provide the compiled version of the program without Sleep(1);?
I cannot find the necessary .lib files to build the program from the source code.
Building wxMSW-2.8.0 from the source code was also unsuccessful.
I don't have a Windows machine to compile it on at the moment. I suspect I'd have the same problem finding the specified wxWidgets library version too, so I think the version will need to be updated in any case.