USB-C Magic Trackpad (PID_0324) on Win11 25H2: MI_00 interface unclaimed, Code 10 — disabling it restores wired function

[rz-100]

Summary

On the 2024 USB-C Magic Trackpad (PID_0324), AmtPtpDevice.inf claims
MI_01 but nothing claims MI_00, which then falls to generic usbhid and
fails HID descriptor validation with Code 10. Disabling MI_00 manually
restores full wired function. I use a USB switch to share the trackpad between
a Mac mini and this PC, so wired mode is required.

Device and environment

• Apple Magic Trackpad, USB-C model (2024)
• Driver v2.0 (MT2FW11-20260223-MSSigned), AMD64
• Windows 11 25H2, OS Build 26200.8875
• Desktop PC, onboard Bluetooth, trackpad connected through a USB switch
• No Magic Utilities, Trackpad++, or Boot Camp drivers present

Failing device hardware IDs:

USB\VID_05AC&PID_0324&REV_0510&MI_00
USB\VID_05AC&PID_0324&MI_00

Behaviour

Bluetooth works fully. Connecting the USB-C cable creates a second device
entry showing:

This device cannot start. (Code 10)
The HID Report Descriptor failed validation. An unknown item was found in
the descriptor.

MI_01 binds correctly as Apple USB Precision Touchpad Device (User-mode).
Only the orphaned MI_00 fails. While MI_00 is in this state, physical
click does not register.

Steps to reproduce

1. Install v2.0, pair over Bluetooth, confirm all functions work
2. Connect the USB-C cable
3. Observe the new MI_00 device entry with Code 10
4. Physical click stops registering

Findings

Note on OS version: I'm on Windows 11 25H2 (Build 26200.8875), released
after the v2.0 build date of 2026-02-23. Issue #20 reports the USB-C model
working over USB-C on 24H2, so this may be a regression from tightened HID
report descriptor validation in a newer Windows build rather than a
longstanding INF gap.

1. Disabling MI_00 in Device Manager restores full wired function,
including physical click and Precision Touchpad registration. This confirms
the unclaimed interface is the cause, not the MI_01 driver. The workaround
is per-device-instance, so it must be reapplied if the trackpad enumerates
down a different port path.

2. Binding AmtPtpHidFilter_NullDevice to MI_00 also fails with Code 10.
Done via Have Disk with "Show All Devices" and compatible hardware unchecked.
Since the null device performs no device-specific work, the descriptor appears
to be rejected by hidclass before any driver logic runs — suggesting a fix
would need to claim MI_00 at the USB level rather than within the HID stack.

3. USB 3 vs USB 2. On a USB 3 port, wired input dropped in roughly
one-second cycles. Moving to USB 2.0 substantially improved stability.
Removing the Bluetooth pairing and disabling USB selective suspend made no
difference; only the port change did.

Note on the INF

The Bluetooth section binds the second collection explicitly:

...PID&0324&Col01  -> AmtPtpHidFilter_MiniPortDevice
...PID&0324&Col02  -> AmtPtpHidFilter_NullDevice

The USB section has no equivalent for the second interface:

USB\Vid_05ac&Pid_0324&MI_01 -> AmtPtpDeviceUsbUm_Install
(no entry for MI_00)

Finding 2 suggests adding a NullDevice line alone wouldn't be sufficient,
but the asymmetry may still be relevant.

Current state

Working setup: MI_00 disabled, trackpad on a USB 2.0 port through the
switch, touchpad sensitivity set to Low. Happy to test builds, capture
traces, or provide crash dumps.

Related

Issue #30 (A3120 tutorial) documents the same device and the same orphaned
interface on firmware REV_0410 — step 4 instructs users to "ignore the alert
mark" on it. Mine is REV_0510, so this isn't revision-specific. That tutorial
routes around the problem rather than fixing it; disabling MI_00 achieves the
same result more cleanly. No documented fix appears to exist.

[vitoplantamura]

hi,

I'm using Windows 11 Pro 25H2 (AMD64), and everything is working correctly:

The differences compared to your setup are:

1. no USB switch

2. using the MT2 Lighting (the original version, not the USB-C one)

3. connected to a USB 2.0 port

You could try:

1. reinstalling the driver after cleaning everything up with DriverStore Explorer?

2. testing without the USB switch

Please note that the imbushuo USB driver (which my driver is forked from) is quite well-tested at this point. I tried searching their issues for "MI_00" and didn't find anything...

Vito