I put some debug code in Hotkey.cpp:HotkeyInputHandler() two weeks ago but haven't been able to trigger this bug again since then. This is kind of strange because it happened on an almost daily basis to me before. Either it's a weird timing problem which would make it impossible to debug for me because I have no detailed knowledge about the inner workings of that code or some third party dependency got updated in the meantime (I'm on Debian Testing and perform an update every day). I'll try without debug code again as soon as I find time to do so (may take a while though).
janwas, on 24 September 2011 - 06:11 PM, said:
Thanks for the report; it'd be great if you would look into this!
It could be a problem within SDL, but that's a bit less likely because it seems to happen on the OS X backend, too.
If you see any gremlins lurking within out input handling chain (starting at lib/input.cpp), I will be happy to give it a look and/or apply a patch.
Incidentally, if you see this problem again, it should be possible to work around it by pressing+releasing the same `stuck' key.
I'm pretty sure I tried this and it didn't work. That's the reason why I suspect HotkeyInputHandler() because there is some code which prevents key up events from doing anything under certain conditions (which I do not truly understand).
janwas, on 24 September 2011 - 06:11 PM, said:
The problem does not arise with mouse scrolling because we check each frame whether the mouse is near the border. Once the mouse returns elsewhere, movement will stop immediately.
This makes sense.