I’m implementing an Apple AssistiveTouch eye tracker accessory for iPad over USB-C using iAP2 plus native HID Gaze Point reports. Current state: iAP2 authentication succeeds identification succeeds StartNativeHID is received AssistiveTouchInformation(IsEnabled=true) is received iPadOS enumerates the HID interface and consumes the interrupt IN reports The remaining issue is that the gaze-point behavior is not interpreted as direct screen coordinates. Repeated fixed gaze inputs produce deterministic but incorrect cursor motion, often appearing like orbiting or projection around a locus rather than stable placement. I have tested: the 119-byte Apple example HID descriptor from the Accessory Interface Specification two report-1 layouts: timestamp + x + y status + timestamp + x + y normalized and physical coordinate scaling verified on the wire that the intended report bytes are sent and consumed iPad console logs show internal model point (HID r) values and multiple derived Pointer positions for a single commanded point, which suggests the device is accepted but the gaze report semantics are still not what iPadOS expects. Questions: Is the example Gaze Point HID descriptor in the Apple Accessory Interface Specification sufficient as-is for iPadOS? What exact payload layout is expected for the Gaze Point report? Is a per-sample status byte required in the gaze input report? Are additional HID feature/input reports required for correct interpretation? I can provide: the exact HID descriptor bytes sample report payloads USB analyzer traces iPad console excerpts showing the resulting model-point and pointer projections