author Sam Lantinga <>
Sat, 27 Jul 2013 03:20:09 -0700
changeset 7526 6c0f0280149c
parent 7222 2435b221d77d
permissions -rw-r--r--
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.

* Porting To A New Platform

  The first thing you have to do when porting to a new platform, is look at
include/SDL_platform.h and create an entry there for your operating system.
The standard format is __PLATFORM__, where PLATFORM is the name of the OS.
Ideally SDL_platform.h will be able to auto-detect the system it's building
on based on C preprocessor symbols.

There are two basic ways of building SDL at the moment:

1. The "UNIX" way:  ./configure; make; make install

   If you have a GNUish system, then you might try this.  Edit,
   take a look at the large section labelled:
	"Set up the configuration based on the target platform!"
   Add a section for your platform, and then re-run and build!

2. Using an IDE:

   If you're using an IDE or other non-configure build system, you'll probably
   want to create a custom SDL_config.h for your platform.  Edit SDL_config.h,
   add a section for your platform, and create a custom SDL_config_{platform}.h,
   based on SDL_config.h.minimal and

   Add the top level include directory to the header search path, and then add
   the following sources to the project:

Once you have a working library without any drivers, you can go back to each
of the major subsystems and start implementing drivers for your platform.

If you have any questions, don't hesitate to ask on the SDL mailing list:

	Sam Lantinga				(