USB-C Magic Trackpad (PID_0324): haptic feedback never fires, actuator enumerates OK — no physical click at all

[pz2hsv99sy-png]

Summary

On the USB-C Magic Trackpad (VID_05AC / PID_0324), haptic feedback is never produced. The Actuator interface enumerates and is healthy, the driver binds correctly, and the control panel applies settings without error — but the Taptic Engine never fires. Since the Magic Trackpad has no mechanical switch, this means the trackpad has no click feel and no physical click at all; only tap-to-click works.

This looks distinct from #37 (settings lost after idle) — here the actuator is never driven in the first place, from a cold connection.

Environment

• Windows 11 Pro 25H2, build 10.0.26200.9168
• Driver: amtptpdevice.inf 2025.3980.1.1000 (12/06/2025), signed Microsoft Windows Hardware Compatibility Publisher, Attested / Universal
• Control panel: AmtPtpControlPanel.exe from MT2FW11-20260223-MSSigned.zip (v2.0)
• Device: Magic Trackpad, USB-C, USB\VID_05AC&PID_0324, REV_0510
• Connection: wired USB-C for all tests below

What works

• Cursor, multitouch, and all Windows precision-touchpad gestures
• PrecisionTouchPad\Status\Enabled = 1; three- and four-finger gestures registered
• Tap-to-click
• Battery over Bluetooth (Battery (only Bluetooth) field populates)

What does not

Haptic feedback, in every configuration the control panel offers.

Device state while wired

USB\VID_05AC&PID_0324&MI_00   Error, problem 10   (disabled deliberately, see below)
USB\VID_05AC&PID_0324&MI_01   OK   Apple USB Precision Touchpad Device (User-mode), oem38.inf
USB\VID_05AC&PID_0324&MI_02   OK   -> Apple Inc. / "Actuator",      UP:0xFF00 U:0x000D
USB\VID_05AC&PID_0324&MI_03   OK   -> Apple Inc. / "Accelerometer", UP:0xFF00 U:0x0003
HID\...&MI_01&COL01           OK   UP:000D U:0005 (Touch Pad)
HID\...&MI_01&COL02           OK   UP:000D U:000E (MTConfig)

The Actuator interface is present and reports ProblemCode 0.

Steps taken

1. MI_00 ("Device Management") fails with code 10 —
   HID report descriptor validation failed. An unknown item was found in the descriptor. (0xC000021D).
   Per USB-C Magic Trackpad (PID_0324) on Win11 25H2: MI_00 interface unclaimed, Code 10 — disabling it restores wired function #50 this can block the physical click on 25H2, so it was disabled:
   Disable-PnpDevice, confirmed ConfigFlags = 1. No change to haptics.
2. Control panel, Use macOS Click Options, Silent clicking unchecked, slider Medium → Apply → no haptic response.
3. Applied the Silent Clicking setting is lost after system idle/sleep (Magic Trackpad 2 USB-C) #37 toggle workaround (switch to Click Options NOT available in macOS → Apply → switch back → Apply) → no change.
4. Control panel, "Maximum haptic feedback (very clicky and loud!)" → Apply → no haptic response.

Step 4 seems decisive: the loudest setting available applies without error and produces nothing, which suggests the failure is below the settings layer rather than a configuration issue.

Additional data point

Opening MI_02 from user space (hidapi) succeeds and the device identifies as Apple Inc. / Actuator, but it returns no readable feature reports across report IDs 0x00–0xFF at lengths 2/8/16/64/256, and no input reports. Same for MI_03 (Accelerometer).

Question

Is haptic control implemented for PID_0324 (USB-C), or only for the Lightning Magic Trackpad 2 (PID_0265)? If the actuator report format differs on this model, that would explain settings applying cleanly while the hardware never responds.

Happy to run any test build, capture traces, or dump descriptors — the device is available for testing.

[pz2hsv99sy-png]

Follow-up: the actuator ignores the Magic Trackpad 2 haptic protocol on PID_0324

I tried driving the Taptic Engine directly, bypassing the driver and the control panel entirely, to find out whether this is a driver gap or a hardware protocol change. Result: the plumbing all works, the device just ignores the commands.

Method. Bound MI_02 (the Actuator interface) to WinUSB and reproduced magicmouse_enable_hostclick() from hid-magicmouse.c with pyusb:

enable : ctrl_transfer(bmRequestType=0x21, bRequest=9, wValue=0x0321, wIndex=2, data={0x21,0x01})
fire   : interrupt OUT ep 0x04, {0x53,0x01,0x17,0x78,0x02,0x06,0x24,0x30,0x06,0x01,0x06,0x18,0x48,0x12}
release: interrupt OUT ep 0x04, {0x53,0x01,0x14,0x78,0x02,0x00,0x24,0x30,0x06,0x01,0x00,0x18,0x48,0x12}

Device descriptors (bcdDevice=0x0510), confirming the transport is correct:

interface 2  class=0x03
   ep 0x84 IN  INT  maxpkt=16 interval=8
   ep 0x04 OUT INT  maxpkt=64 interval=2

MI_02 HID report descriptor — note there are no Feature reports declared, only input 0x3F and output 0x53:

06 00 FF 09 0D A1 01 85 3F 09 0D 15 00 26 FF 00 75 08 95 0F 81 02
                     85 53 09 0D 15 00 26 FF 00 75 08 95 3F 91 02 C0

This is why the enable step cannot be done through the Windows HID API at all — HidD_SetFeature is rejected (-1) since report 0x21 isn't in the descriptor. Linux gets away with it by issuing a raw USB control transfer. Over WinUSB the control transfer is accepted (returns 2 bytes written).

Variants tried, each fired ~13 down/up cycles, all transfers accepted, no haptic response from any:

1. baseline, 14-byte report as Linux sends it
2. payload zero-padded to the full 64-byte declared report size
3. enable sent with wIndex=1 instead of 2
4. no enable step at all
5. maximum intensity — vibration bytes forced to 0xFF
6. alternate enable payload {0x21, 0x03}

Conclusion. Correct interface, correct endpoint (from the device's own descriptors), control transfers ACKed, output reports accepted — and nothing happens, even at maximum intensity. The USB-C Magic Trackpad appears to use a different actuator command format from the Lightning Magic Trackpad 2, rather than this being a plumbing problem in the driver.

That would explain the original report: the control panel applies settings successfully and the hardware simply never responds.

If it helps, I can capture a USB trace of the working sequence from macOS for comparison. Happy to run test builds.

[pz2hsv99sy-png]

Resolved — my earlier conclusion was wrong. A reboot is required.

Correcting the record, since both my report above and my follow-up comment were misleading.

The haptic click works. The Taptic Engine on PID_0324 is fine and the driver drives it
correctly. What was blocking it was the orphaned MI_00 interface, exactly as suspected in #50 —
but with a step I missed:

Disable-PnpDevice on MI_00 does not take effect until Windows is restarted.

ConfigFlags is set to 1 immediately and Device Manager shows the interface as disabled right
away, so every diagnostic reports a correct configuration — while the running driver stack still
holds the old state and the click stays completely dead. Unplugging and replugging the trackpad is
not sufficient, and neither is re-pressing Apply in the control panel. Only a full restart
re-enumerates the composite device.

After the reboot, with the trackpad wired over USB-C, the control panel behaves exactly as
documented: click mode, click pressure and haptic strength all apply, and the setting persists when
the trackpad is used over Bluetooth.

Confirmed working configuration, Windows 11 25H2 (build 26200):

Interface	Service / driver	State
MI_00 (Device Management)	HidUsb	disabled — CM_PROB_DISABLED, ConfigFlags = 1
MI_01 (Touchpad)	MsHidUmdf — AmtPtpDevice 2025.3980.1.1000	OK
MI_02 (Actuator)	default HID	OK
MI_03 (Accelerometer)	default HID	OK

Retracting the protocol claim. My follow-up comment concluded that the USB-C model uses a
different actuator command format from the Lightning Magic Trackpad 2, on the grounds that the raw
WinUSB approach (magicmouse_enable_hostclick() from Linux's hid-magicmouse.c, six payload
variants) produced no response. That inference was unsound — MI_00 was still active in the driver
stack throughout those tests, so the negative result says nothing about the payload format. There
is no evidence of a protocol change, and nobody should spend time on raw USB access here.

One incidental detail that is still accurate and may save someone else the attempt: MI_02 declares
no Feature reports (only input 0x3F and output 0x53), so HidD_SetFeature cannot succeed
against it through the Windows HID API in any case.

Suggested takeaway for the docs, if useful: the MI_00 workaround in #50 is worth stating with
"then reboot" made explicit. The failure mode is very confusing without it — the machine looks
correctly configured while the hardware does nothing.

Happy for this to be closed.