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