Magic Trackpad plus 10.5 Leopard/PPC

[MrCheeto]

Here we go again.

(Yes, I understand that official support was not added until Snow Leopard)

Original Magic Trackpad has successfully paired to my 4,1 Mac Pro running 10.5.8 Leopard and works as a pointing device with click functionality. It struggles to drag. If I try to launch the Trackpad preferences, it says the Trackpad preference pane is "not available to you at this time". I'm imagining it's because something is telling the pane that I'm not on a notebook.

I dragged a copy of the pane from Sys/Lib/PrefPanes to Lib/PrefPanes which was otherwise empty and then it executed. It only offered changing tracking speed and dragging and a few options but not everything you expect to see when using a notebook. The videos demonstrating the multi-touch features do not display in the pane though I do indeed find the videos are contained within the panes. The videos demonstrate both an MBA with button and a MBP with no button. This proves that the capability to use multi-touch gestures is within 10.5.8 and by installing a different .kext other users have gotten multi-touch on their notebooks within 10.5.

Any tips on how to trick my Mac Pro into thinking I'm using a built-in trackpad? I've seen PPC users with as much success as me so I figure if I get this working it could apply to that as well.

 

[f54da]

I'm not sure I fully understand, you basically want osx to think of the magic trackpad as internal? This is quite feasible, but non-trivial for the reason that in order to change the trackpad from "plain HID" to "multitouch" mode the OS needs to send a magic packet. Once this is done, the frames received can be decoded. The frame format differs from internal trackpad.

See my post https://forums.macrumors.com/threads/magic-trackpad-2-on-10-9-or-lower.2332288 on how you can create a kext to do this.

>This proves that the capability to use multi-touch gestures is within 10.5.8 and by installing a different .kext other users have gotten multi-touch on their notebooks within 10.5.
Link to this? I don't recall if internal trackpad multitouch support existed on 10.5 or not.

 

[MrCheeto]

Link to this?

10.5.6 .kext.

Here is what I'm looking at. You can see it allows up to 4-finger gestures. I seem to recall these functions kicked off with the MacBook Air and that was released in Tiger days. I'm not saying that Tiger had full gesture support but that Apple was putting things in place for gestures before Leopard was even released. Thanks.

 

[f54da]

I see, yes that is the AppleUSBMultitouch kext which I recall contains within it the AppleMultitouchHID driver, which takes the raw frames and converts it to appropriate IOHID (quartz) events. So the plumbing for multitouch was already in place in the userspace it seems, since the generated IOHID events were properly recognized. In later versions to support magic trackpad they added a new AppleMultitouch kext (without USB in the name) and moved the IOHID plugin in there, with separate codepaths for the bluetooth and internal.


Here's something I had documented some time back:

First a brief summary of IOKit to lay the necessary background: you basically have a hierarchy of kexts that increasingly abstract away events. So for instance, at the very root you might have some driver responsible for low-level PCI communication, and above that is a driver for a USB controller on the PCI bus, and then above that a driver that interprets the specific USB frames of the device. The interaction between each layer of this stack is mediated by what iokit calls "nubs", and basically a driver will expose a "nub" for each device that it wants to be handled by some child driver. IOKit will find the corresponding driver that can "attach" to the nub, load it, and the cycle continues until the leaf. Honestly it sounds a lot more complex than it is, and I think the easiest way to see how this works is to just open up IORegistryExplorer (included as part of xcode) where the tree driver structure is intuitive. Finally, there's one last piece: IOKit also has "user clients" which allow communication with userspace.

Now the multitouch stack on osx has 4 main parts: the multitouch driver, multitouch user client, multitouchhid driver, and the multitouch framework. The former 3 are in kernel space while the latter is just a library that can be accessed. Now the interesting part is that the pathway for bluetooth and internal trackpad is actually completely separate, down to the codepath taken in the multitouch hid driver. That is, when you connect a magic mouse, the hierarchy is BNBTrackpad (just handles very low-level bluetooth property getting), AppleMultitouchDevice (note the lack of USB in the name), and AppleMultitouchHID. I remember reading that when the magic trackpad originally launched it required a software update which installed those kexts, so I guess the fact that the codepaths remains separate comes from that legacy.

The core of the "magic" is in the AppleMultitouchHID driver, which takes the raw touch events given to it from the higher layer and processes them, eventually dispatching IOHIDEvents for a swipe/gesture/etc. I think these IOHIDEvents are eventually propagated through the HID stack and end up being converted into CGEvents/NSEvents somewhere down the line. The multitouch HID driver has a lot of code related to path tracking, gesture recognition, smoothing, etc.

The overall codepath looks roughly like this: once the raw touch events are obtained from AppleMultitouchDevice, it's passed to the MultitouchHID driver, starting at MTSimpleHIDManager::handleContactFrameEntry and bubbling to MTTrackpadHIDManager::handleContactFrame. (A lot of the MultitouchHID methods have a "simple" version. I'm not quite sure what this is for, but I guess it's some sort of fallback pathway).

Basically it seems there's multitouch(usb)driver kext which seems to handle the lower level/raw events and device communication, and it then hands off the things to MultitouchHID which is responsible for the fancy gesture magic

(Note that AppleMultitouch.kext also registers a user client which allows any userspace client to register to these raw touch events via MultitouchSupport.framework (communication via mach port). This is how apps such as bettertouchtool get access to raw touch events.


From there, MultitouchHID keeps track of a lot of things like hand statistics, the current path, any chords (which I assume are sequences of actions like tap drag), and after a lot of processing logic (which I didn't bother reversing) it eventually computes a gesture code. The list of possible gestures is seen in MTPListGestureConfig:arseGestureMotionCode, e.g. "tap, hold, lift, horizontal, rotate, etc." Now the way MultitouchHID is structured is that these gestures are then mapped to actions declaratively. That is, there are setup methods (e.g. createScrollZoomCombo) which has calls like

```
MTPListGestureConfig::addGestureToArray(r15, @"Fluid Notification", @"Horizontal", @"Edge Swipe", @"OnlyIfAllMoving", @"LockOnFirstUntilPause", rbx, r12);
```

These actions (which are internally represented as MTAction) are then eventually converted into standard IOHIDEvent (which are appended to the base digitizer event created in handleContactFrame). These IOHIDEvents then somehow get picked up by MTTrackpadEventDispatcher::handleEvent where I assume they get sent to the system's usual HID stack.

To make magic trackpad work on 10.5 then you'd want to pair that kext you shared (which contains the updated IOHIDEvent portion) along with another kext that translates magic trackpad frames to internal trackpad frames. Non-trivial, but quite feasible.

 

[MrCheeto]

I understand the idea here. You’re saying the order of “branches” means that input differs whether it’s inbuilt USB device or a BT device etc.

It’s simply above my know-how. As you can see, the farthest I got was dragging a pref pane to another folder. Is this something you might be interested in doing for something in return? If it costs a bit but gets support to the PPC community and my Intel Leopard machine then it would be worth it to me 😁

 

[f54da]

>You’re saying the order of “branches” means that input differs whether it’s inbuilt USB device or a BT device etc.

No, not quite. I'm saying that the data format (to be precise, HID frames) sent by the magic trackpad is different from the data format sent by the internal trackpad, so one would need to write a kext to convert between the two, in order to be able to treat the magic trackpad as an internal one. (It is also true that the frame processing and IOHID event synthesis differs between internal trackpad and magic trackpad, but this not a fundamental issue, just Apple's weird design choice).

>Is this something you might be interested in
It's not something I have time for at the moment... I've been wanting to do something similar to use Magic Trackpad 2 on 10.9 for a while, but I don't have the time or motivation to do that either, especially since I realized using a magic tracakpad isn't really that ergonomic for me after all.

Maybe someone else in the ppc community can give it a go.

 

[f54da]

Probably moving this thread to PPC subforum would be better, there are more people there who might be interested in this compared to accessories forum.

 

[MrCheeto]

Thanks! Of course didn’t realize it’d be THAT involved.

 

[demine0]

some updates?