Fixed bug 1272 - Bogus numlock key up/down events being reported on MacOS X

Vern Jensen

The problem is that in certain situations I'm getting THREE keyUp/keyDown events when I push certain keys.

In my event code I added:

case SDL_KEYUP:

printf("SDL KeyScanCode for KEYUP event: %d\n", event->key.keysym.scancode );
…

and

case SDL_KEYDOWN:

printf("SDL KeyScanCode for KEYDOWN event: %d\n", event->key.keysym.scancode );
…

The result of one test run where I push 2 keys and then release them is this:

SDL KeyScanCode for KEYDOWN event: 92   // Pushed keypad 4
SDL KeyScanCode for KEYDOWN event: 83   // Pushed left shift
SDL KeyScanCode for KEYUP event: 83
SDL KeyScanCode for KEYDOWN event: 225
SDL KeyScanCode for KEYUP event: 92     // Released keypad 4
SDL KeyScanCode for KEYDOWN event: 83
SDL KeyScanCode for KEYUP event: 83
SDL KeyScanCode for KEYUP event: 225    // Released left shift

There *should* be only a total of 4 events above… 2 for each key being pushed, and 2 for each being released. But instead some bogus events for numlock being pushed/released are sent from SDL. These events did not occur. I did not push numlock. The value above for numlock is 83. Comments above show when I pushed each key. As you can see, when I push left shift, THREE events are instantly sent to my application, keyDown and then keyUp for numlock, and then the valid event for left shift (the key that was actually pushed).

You could replace keypad 4 with pretty much any keyPad key and it'll still happen. You can also replace it with any arrow key and it'll happen. However, when trying it with normal letter keys on the main keyboard it didn't.

It happens with other modifier keys too, not just left shift.

The order in which the keys are pressed matter. For instance, if I do:

1) keypad 4
2) left shift
3) release left shift
4) release keypad 4

Then at step 2, I get the 3 events above (when there should be only one), but steps 3 and 4 work properly… I don't get extra keyUp/keyDown events for steps 3 or 4. Thereas if the order of steps 3 and 4 are reversed, I get the bogus extra events for numlock.

Also, the problem can occur even when pushing just a single key by itself. If I push left shift, then keypad 4, then release left shift, then release keypad 4, then the following push of left shift will cause the bug. If I continue pushing and releasing left shift though, it won't happen again until I again involve keypad keys.

---

Sam Lantinga

According to the Apple documentation, NSNumericPadKeyMask is set for any arrow or numeric keypad event. Indeed this is what's happening.

I verified that we get the correct events for the numlock key and the mod state gets set correcly, so it should be safe to remove this bogus code.
Fixed variable scoping for Windows build
Fixed bug 1983 - SDL_thread.h broken under MinGW crosscompiling environment

q66

after updating SDL2 to the latest RC I'm unable to build my game engine under mingw crosscompiling environment for Windows (32bit, hosted on freebsd 64bit).

The error is in SDL_thread.h with messages like this: http://codepad.org/jEQXd3Yq

The problem is, while _beginthreadex return type is correctly mapped to uintptr_t (as specified by Microsoft), the return type under mingw is unsigned long int (same size, different signature), resulting in the error above.

The reason it didn't error before is this: http://codepad.org/8FAbKAxz

You can see the _beginthreadex case is only used without HAVE_LIBC defined; at one point though, SDL_config_windows.h was changed like this:

-/* Enabled for SDL 1.2 (binary compatibility) */
-#define HAVE_LIBC     1
+/* This is disabled by default to avoid C runtime dependencies and manifest requirements */

resulting in these errors.
Added example of using the software renderer and window surface API, contributed by Nitin Jain.