Extending Functionality of Magic Mouse: Do I Need a kext?

Question

I recently purchased a Magic Mouse. It is fantastic and full of potential. Unfortunately, it is seriously hindered by the software support. I want to fix that. I have done quite a lot of research and these are my findings regarding the event chain thus far:

1. The Magic Mouse sends full multitouch events to the system.
2. Multitouch events are processed in the MultitouchSupport.framework (Carbon)
3. The events are interpreted in the framework and sent up to the system as normal events
   • When you scroll with one finger it sends actual scroll wheel events.
   • When you swipe with two fingers it sends a swipe event.
4. No NSTouch events are sent up to the system. You cannot use the NSTouch API to interact with the mouse.

After I discovered all of the above, I diassembled the MultitouchSupport.framework file and, with some googling, figured out how to insert a callback of my own into the chain so I would receive the raw touch event data. If you enumerate the list of devices, you can attach for each device (trackpad and mouse). This finding would enable us to create a framework for using multitouch on the mouse, but only in a single application. See my post here: Raw Multitouch Tracking.

I want to add new functionality to the mouse across the entire system, not just a single app.

In an attempt to do so, I figured out how to use Event Taps to see if the lowest level event tap would allow me to get the raw data, interpret it, and send up my own events in its place. Unfortunately, this is not the case. The event tap, even at the HID level, is still a step above where the input is being interpreted in MultitouchSupport.framework.

See my event tap attempt here: Event Tap - Attempt Raw Multitouch.
An interesting side note: when a multitouch event is received, such as a swipe, the default case is hit and prints out an event number of 29. The header shows 28 as being the max.

On to my question, now that you have all the information and have seen what I have tried: what would be the best approach to extending the functionality of the Magic Mouse? I know I need to insert something at a low enough level to get the input before it is processed and predefined events are dispatched. So, to boil it down to single sentence questions:

• Is there some way to override the default callbacks used in MultitouchSupport.framework?
• Do I need to write a kext and handle all the incoming data myself?
• Is it possible to write a kext that sits on top of the kext that is handling the input now, and filters it after that kext has done all the hard work?

My first goal is to be able to dispatch a middle button click event if there are two fingers on the device when you click. Obviously there is far, far more that could be done, but this seems like a good thing to shoot for, for now.

Thanks in advance!

-Sastira

Answer 1

How does what is happening in MultitouchSupport.framework differ between the Magic Mouse and a glass trackpad? If it is based on IOKit device properties, I suspect you will need a KEXT that emulates a trackpad but actually communicates with the mouse. Apple have some documentation on Darwin kernel programming and kernel extensions specifically:

• About Kernel Extensions
• Introduction to I/O Kit Device Driver Design Guidelines
• Kernel Programming Guide

(Personally, I'd love something that enabled pinch magnification and more swipe/button gestures; as it is, the Magic Mouse is a functional downgrade from the Mighty Mouse's four buttons and [albeit ever-clogging] 2D scroll wheel. Update: last year I wrote Sesamouse to do just that, and it does NOT need a kext (just a week or two staring at hex dumps :-) See my other answer for the deets and source code.)