macos - How can Mac OS X games receive low-level keyboard input events?

Question

Games need low-level access to keyboard input. On Windows, there's DirectInput. But what technology do Mac OS X game developers use?

Obviously, there's enough Mac games which get keyboard input just right, without the drawbacks of the commonly known solutions:

Solution #1: Use keyUp / keyDown events

-(void)keyUp:(NSEvent*)event;
-(void)keyDown:(NSEvent*)event;

Inacceptable drawback: keyDown events are repeated based on the system preference settings for "key repeat rate" and "key repeat delay". This causes an initial keyDown event followed by a pause before it starts repeating at a rate defined by a system preference setting. This solution can not be used for continuous key events.

I wonder if the key repeat behavior can be disabled? I suppose that you could read the first keyDown key, then remember the "key with keyCode x is down" state in your class until the keyUp event is received for that key, thus bypassing the repeat delay and repeat rate issues.

Solution #2: Use Quarts Event Taps

See Quartz Event Services Reference. It seems to be sufficiently low-level.

Inacceptable drawback: requires Assistive Devices to be enabled in system preferences under Universal Access - Keyboard. While this may be on by default, there is no guarantee that it might be turned off on some systems.

I also read that Quartz event taps require the app to run as root, but found no confirmation for this.

Solution #3: Carbon Events / IOKit HID

The Carbon Event Manager Reference is marked as legacy and should not be used for new development.

Inacceptable Drawback: no one knows how long the Carbon events will continue to be supported in future Mac OS versions.

Apart from Carbon being a legacy framework, this still seems to be the best solution. But are there any other drawbacks for using Carbon Events?

Questions:

Which technology do Mac OS X game developers use for receiving low-level keyboard input events? If they use one of the above technologies, how do they work around the drawbacks I mentioned?

UPDATE:

I eventually turned to using the regular NSEvent messages and wrapped them in a neat API for polling the keyboard states.

Answer 1

I have had good luck with #3, but it requires a lot of heavy lifting if you want to support anything beyond the keyboard.

One quick point before we dive in though, Carbon and IOKit HID are two separate thing. Carbon may go away at some point. But IOKit HID is here to stay and just got a nice facelift in 10.5.

For a full example of how this stuff all fits together, take a look at https://github.com/OpenEmu/OpenEmu/blob/master/OpenEmu/OEHIDManager.m. That is a small piece of the puzzle as there are other files in there as well.

The documentation for what you're wanting to do can be found http://developer.apple.com/library/mac/#documentation/DeviceDrivers/Conceptual/HID/new_api_10_5/tn2187.html

Again, this is not going to disappear anytime soon and is completely separate from Carbon and Carbon Events.