I like to set my key repeat rate at a level below what is possible via the windows ui with the SystemParametersInfo function (example application https://stackoverflow.com/a/11056655 ). When I set the repeat rate lower than 17ms, remedy struggles with the input when I keep F10 pressed. It actually steps slower and the intervals between the steps are inconsistent, it's jittery. My monitor refresh rate is 60 Hz, so the the approach used for input and rendering is obviously hindering the stepping rate from being greater than the monitor refresh rate.
This is inconvenient for me, because I have to set my key repeat rate at 17ms, which is higher than I'd like it to be. So my request is that remedy be changed to handle faster key repeats. The ideal solution would be for remedy to have its own configurable repeat rate for stepping that is independent from the windows key repeat rate. It seems like this debugger is essentially capable of stepping through the code way faster than it currently does, and it would be awesome if it could actually do that. But if it could just keep up with the key repeat rate that I want to use, that would be pretty good too.
Edited by kvosdev
on
This has to do with how the Dear ImGui version that RemedyBG is currently using handles input events. Once RemedyBG is updated to use a later version (v1.87+), where input events are accumulated in a queue, then keyboard events fired faster than 60 Hz should be handled as expected. I've made a note to double check this particular case after upgrading.
In addition, I want to note that this also happens in cases when you use QMK Firmware (or ZMK) for custom keyboards and has a Mod Tap button that sends KEY-DOWN, KEY-UP events with an interval of ~ 2-6ms. For example, my Delete button behaves as Fn when hold and Delete when pressed. And I can't press Delete normally in RemedyBG — I had to assign another Delete on another layer of the keyboard layout