I'm using SDL2 with .NET bindings. Keyboard handling is encapsulated in static class, and keyboard handling code part looks like this:

// class members
private static int _numkeys;
private static IntPtr _keysBuffer;
private static byte[] _keysCurr = new byte[(int)SDL_Scancode.SDL_NUM_SCANCODES];
private static byte[] _keysPrev = new byte[(int)SDL_Scancode.SDL_NUM_SCANCODES];

// called once, to get buffer pointer
_keysBuffer = SDL_GetKeyboardState(out _numkeys);

// update keyboard state each frame
var tmp = _keysPrev;
_keysPrev = _keysCurr;
_keysCurr = tmp;
// copy new state
Marshal.Copy(_keysBuffer, _keysCurr, 0, _numkeys);

all is workig as expected mostly, however once in while one of the following behavior occurs:

  1. Physical key is pressed, but no key press is detected. Keypress is detected after key repeat interval.
  2. Physical key is pressed, but no key press is detected. Lasts for infinite amount of time.

For example, I press Right (D), the movement to right starts, shortly after I press Fire (SPACE), movement is stopped, no firing occurs, then after key repeat interval firing starts, but movement to Right is stopped despite key is also still pressed.

Unfortunatelly I have both 1) not discovered 100% reproducible pattern for the bug yet (seems like it happens on burst sequental presses), 2) have no ideas what is the cause.

For now I just want, a fresh view on my code (is it solid?) and maybe some ideas on what to check. Thanks!

  • 2
    \$\begingroup\$ Sounds like a typical issue from matrix keyboards. IOW, that's a hardware issue. \$\endgroup\$
    – Quentin
    May 11, 2017 at 12:00
  • \$\begingroup\$ @Quentin thanks for the tip. But I have a ghosting-free gaming keyboard, so it's unlikely the issue IMO. But i'll check it out to be sure. \$\endgroup\$ May 11, 2017 at 16:29
  • \$\begingroup\$ Is there a reason you can't use the event system instead of manually handling the key state? \$\endgroup\$
    – Pharap
    May 11, 2017 at 16:36
  • \$\begingroup\$ @Pharap thanks for the option, but I'm happy with my implementation, would not change it unless there is unfixable bug :) \$\endgroup\$ May 11, 2017 at 17:04
  • 1
    \$\begingroup\$ @PetrAbdulin glad to help! but I doubt "your keyboard is busted, get a new one" is a useful answer for future devs ;) \$\endgroup\$
    – Quentin
    May 12, 2017 at 8:16

2 Answers 2


This could be a hardware issue as stated by @Quentin.

Anyways, you could write a workaround tracking the KEYDOWN and KEYUP events instead of trying to fetch the keyboard state, i'm not pretty sure how it works in C#, i've never worked with SDL2 in that language, but here's an example of how do I manage it in C++, i suppose it's pretty similar.

Instead of doing that, what you would need is an array of unsigned char, writting 1 into the key code index when pressed and 0 when released.

After that you will have the state of the keyboard with no hardware state dependency

  • \$\begingroup\$ Thanks for the answer. But that's exactly how SDL's keyboard state works internally! It simplifies keyboard handling by great amount. It's much more likely for me to implement it poorly than SDL. So I see no reason to try fixing that is not broken (unless you can say what is wroing with my code now). \$\endgroup\$ May 11, 2017 at 16:38

Surprisingly it actually turned out that Quentin was right is some sense. It was not keyboard ghosting however, but pure keyboard malfunction. It just happened that it really not reporting some keys pressed then they are. And it was incosistent as the "bug" was.

I used Keyboard Ghosting Demonstration page and Keyboard Ghosting & Rollover Test windows app for the test.

The costly piece of garbage was replaced by my old good membrane keyboard and the "bug" is gone now.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .