This is very timely, as we've been approached by a PC keyboard
manufacturer that wants to enter the Mac market. Most of the
non-standard keys I can handle from a user land app (buttons for
email, music, pictures etc). However, the keys for Option and
Command are mapped backwards making the keyboard mostly unusable...
On Feb 3, 2005, at 1:39 PM, Rich Kubota wrote:
On the face of it, the task doesn't look too daunting. It should
be a simple matter of adapting the already available open source
Apple keyboard driver. Looking around on the Apple dev web site
didn't turn up (m)any clues about how usb keyboard input is
handled, but downloading the USBFamily.kext code made things a
little clearer.
the IOUSBHIDDriver.cpp code does show that the process point for
the incoming report is with the
handleReport(_buffer) call line 1081.
At this point, the call takes you to the
IOHIDDevice::handleReport call in the IOHIDDevice.cpp file which
is a part of the IOHIDFamily source. The actual processing of the
keystroke is in the
IOHIDKeyboard::handleReport() call which is in the IOHIDKeyboard.cpp code.
Here you can see how the report is processed.
This should help get you started. What you should be able to do is
implement a vendor specific driver for your keyboard modeled after
the standard HID class driver. When the incoming report is
received, you have a chance to inspect the bytes and twiddle them
to make it appear that a keys were pressed or released.
I've written a lot of Mac code, but never a kext before, so maybe
you can clarify this a bit. If it helps to pretend I'm dense, please
do so. :-)
What you are saying we should do is:
- Change the IOUSBHIDDriver project target to match against our
keyboard (plist change) and I presume change the name of the class
to something appropriate.
- In InterruptReadHandler, twiddle the raw data before handleReport
is called to make whatever modifications are desired.
Is that it?
Thanks,
Dave
