25. May. 2000, Tomi Engel

This article was written for the stepwise publication. It covers session 114 of the WWDC.

WWDC 2000: The HIDManager in Mac OS X

Hidden behind the phrase "human input device" is more then just a keyboard and mouse. Most games require a joystick, steering wheel or other special control and even simple things like a three-button mouse ask for a non standard way of handling the additional input capabilities. Some mechanism has to make sure that input which was generated by the user with one of the attached gadgets, will find its way to the right application and trigger the correct action.

For Mac OS X Apple has created the HIDManager by simplifying the existing InputSprockets which were used for gaming under the classic Mac OS. The new framework no longer performs GUI tasks and focuses totally on dispatching, queuing and delivering events from hardware-level drivers to application level clients. Basically the HIDManager owns all devices and decides on which route the data should flow into user-land.

Writing drivers is not required

HIDManager lives in kernel and user space and so there are two ways to add a new driver to the system:

1. Write an IOKit driver.
   Most of them will be in the USB domain and for those a more or less automated detection and handling will be provided, as long as they conform to the USB HID specification.
   
   
2. Write a HIDManager plug-in.
   Because the HIDManager's API has not been made public yet there were no exact details about this approach, but in concept it is just another plug-in (CFPlugIn ?) which will be loaded into the HIDManager and registered in a similar fashion like the IOKit drivers.

So if you are writing a driver for a device which is plugged into the serial port you might prefer to stay at the plug-in level, because you do not have to learn kernel level debugging in order to get you job done and you still be treated equally by the HID system.

The same applies to virtual devices which only exist on the users screen. In those cases you might have an application presenting your control (an on screen 3D pad) which communicates with a HID plug-in and thereby injects the events into the global dispatching architecture.

What are your applications "needs"?

In order to receive user generated events your application has to inform the HIDManager about its "needs". A "need" is a pipe/port which corresponds to a user action ("play", "stop", "eject", "rotate left"...). The channel must define the required datatype and orientation. What this means technically is yet unknown, but we doubt that the HID pipe/port correspond to a UNIX pipe or TCP/IP port.

In contrast to the InputSprockets, the HIDmanager no longer tries to define all possible "needs" that any application might have but instead leaves this task to the application itself. Presenting the GUI and storing the final "need-to-inputdevice" mapping is also a responsibility of each application.

Now that HIDManager only focuses on user event dispatching and delivery it can finally be used for any kind of application and not just games. A 3D modeling app could defined the "need" for two 3D mouses where it would be willing to share one with other applications but lock down the second for its exclusive usage no matter which application the user will focus on. While this sounds trivial it is still very uncommon in professional 3D to share a device between different tools. Most developers go straight to the serial port, implement their own driver and lock down the device. Finally sharing will become easier.

HIDManager supports polling (e.g. the pens pressure status) or event driven (e.g. triggered by pressing the pens button) behavior. All events are time-stamped and they can be delivered as coalesced or individual events. In addition to that some way of synchronizing events across different needs (e.g. "rotate-x", "rotate-y", "rotate-z") is also supported.

Having this central hub for input device handling is a great improvement over Mac OS X Server or Openstep and with no longer being a games-only technology it is an improvement over Mac OS 9 as well. The APIs will become available over Apples seeding server soon and the public beta of Mac OS X will have HIDManager included.