mcmonkey's picture

Keyboard occasionally sticks without reason

Using this to get the keyboard state:

                CurrentKeyboard = Keyboard.GetState();

Followed by a simple keyboard check like this:

                if (CurrentKeyboard.IsKeyDown(Key.Left))

(Both in the UpdateFrame method, definitely firing at 60 FPS) (I triplechecked to make sure the code fires with lots of debug output)

It generally works out fine, but sometimes the keyboard suddenly locks into one state. It will either assume the Left key is held down constantly or released constantly, regardless of it's real state.
Its sticking seems to be unrelated to any event I can identify: The window remains focused, no keys are newly pressed/release when it occurs, ...
It sometimes is stuck right at startup, sometimes it's a few seconds-minutes into running the application, sometimes it doesn't appear to stick at all.

Restarting the program un-sticks the keys.
Keys don't stick in any other programs...

EDIT: Also, the KeyPress event fires exactly as it should, clearly not effected by this bug. I guess, worst case scenario, I could try to use Key events to build my own Keyboard object... but that seems like extreme overkill.

I'm 99.9% sure everything I'm doing is correct (This is too simple + the randomness implies external causes) - is there a different way I should be reading the keyboard state, or is there an issue with OpenTK's keyboard handling, is there some setting that would bug this, or is there some driver I should be updating, it's vaguely possibly my keyboard configuration could be switched around by my OS - would that cause this, ...?
Only tested/confirmed on my Windows 7 PC (sufficient RAM / CPU power to not be relevant, AMD Radeon 7750 graphics card, ...)

note: I want state objects so, later, I can compare whether a key is being pressed for the first time this tick, or it's being held.

Side issue: when it's not stuck, it's returning fully accurately even when the Window isn't selected. I could easily work-around that with some if statements... just seems like that shouldn't be standard though.


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
the Fiddler's picture

This is most likely a bug in the keyboard handling code.

Does it affect specific keys or key combinations (e.g. when pressing shift/alt/control or multiple keys together) or is it totally random?

As a workaround, you can try using the SDL2 backend (just copy SDL2.dll from opentk/Dependencies/x86 or x64 to your application directory.)

mcmonkey's picture

It's totally random - it even occasionally happens at startup before any keys are pressed at all.

And it appears to not happen with SDL2.dll present.

I guess I'll remake this as an issue then.

EDIT: SDL2 won't fire KeyPress events for control keys (EG, CTRL-C, CTRL-V) which breaks the other chunk of keyboard code I have...

the Fiddler's picture
Quote:

EDIT: SDL2 won't fire KeyPress events for control keys (EG, CTRL-C, CTRL-V) which breaks the other chunk of keyboard code I have...

Please file another bug for this, this was not intended.

mcmonkey's picture

https://github.com/opentk/opentk/commit/0052ff435e8a3bf48aef0ea04a49ea47...

^ I'm going to assume that was your response to / handling of that, and an extra issue is no longer needed.

the Fiddler's picture

Indeed, SDL2 not raising KeyPress events for Ctrl-C is the correct behavior - the native backend was in the wrong here.

As per the documentation, KeyPress is only raised for printable (text) characters. For non-text input (e.g. Ctrl-C, Ctrl-V), use KeyDown and KeyUp instead.