title: How can Mac OS X games receive low-level keyboard input events?
body: <p>Games need low-level access to keyboard input. On Windows, there's DirectInput. But what technology do Mac OS X game developers use? </p>
  
  <p>Obviously, there's enough Mac games which get keyboard input just right, without the drawbacks of the commonly known solutions:</p>
  
  <p><strong>Solution #1: <a href="https://stackoverflow.com/questions/275088/how-do-i-collect-key-input-in-a-video-game-style-cocoa-app">Use keyUp / keyDown events</a></strong></p>
  
  <pre><code>-(void)keyUp:(NSEvent*)event;
  -(void)keyDown:(NSEvent*)event;
  </code></pre>
  
  <p><em>Inacceptable drawback:</em> 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.</p>
  
  <p>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.</p>
  
  <p><strong>Solution #2: <a href="https://stackoverflow.com/questions/3546730/how-do-i-observe-keyboard-input-event-while-the-applicaion-is-not-actived">Use Quarts Event Taps</a></strong></p>
  
  <p>See <a href="http://developer.apple.com/mac/library/documentation/Carbon/Reference/QuartzEventServicesRef/" rel="noreferrer">Quartz Event Services Reference</a>. It seems to be sufficiently low-level.</p>
  
  <p><em>Inacceptable drawback:</em> 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.</p>
  
  <p>I also read that Quartz event taps require the app to run as root, but found no confirmation for this.</p>
  
  <p><strong>Solution #3: <a href="https://stackoverflow.com/questions/5844892/no-really-what-is-the-proper-way-to-handle-keyboard-input-in-a-game-using-cocoa">Carbon Events / IOKit HID</a></strong></p>
  
  <p>The <a href="http://developer.apple.com/legacy/mac/library/#documentation/Carbon/Reference/Carbon_Event_Manager_Ref/Reference/reference.html" rel="noreferrer">Carbon Event Manager Reference</a> is marked as legacy and should not be used for new development.</p>
  
  <p><em>Inacceptable Drawback:</em> no one knows how long the Carbon events will continue to be supported in future Mac OS versions.</p>
  
  <p>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?</p>
  
  <p><strong>Questions:</strong></p>
  
  <p>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?</p>
  
  <p><strong>UPDATE:</strong></p>
  
  <p>I eventually turned to using the regular NSEvent messages and wrapped them in a <a href="http://www.learn-cocos2d.com/2011/09/kobold2d-polling-user-input-kkinput/" rel="noreferrer">neat API for polling the keyboard states</a>.</p>