touch

<!-- RESOLVED.

Reporting: changing only the device tree interrupt type, same kernel, IRQ_TYPE_EDGE_FALLING gives 0 interrupts and IRQ_TYPE_LEVEL_LOW gives 2173 in a 45 s capture, with tracking IDs, BTN_TOUCH, ABS_MT_TOUCH_MAJOR ramping, and a continuous slot-0 trajectory spanning X 86..728 and Y 765..1765. docs/evidence/touch-reports.md.

Orientation: settled by tapping a drawn target at two opposite corners, with the predictions for correct / swapped / X-mirrored / Y-mirrored written down before the result was read. Observed (250,208) and (850,2130) against (216,234) and (807,2166) predicted for the unmirrored unswapped mapping; the three competing hypotheses are out by 240 to 1900 units. docs/evidence/touch-evtest.txt.

One caveat recorded rather than smoothed over: reported X was seen to reach 1058, above the 1023 implied by touchscreen-size-x = <1024>, so the controller's native range is slightly wider than the device tree declares and a consumer must clamp. -->

The GT9895 controller SHALL be probed and SHALL report touches as standard Linux input events, over the digitizer's native 1024x2400 range declared via touchscreen-size-x / touchscreen-size-y, mapping monotonically onto the panel with the axes neither swapped nor mirrored, so that a consumer scaling by 568/1024 and 1232/2400 lands a touch where it is seen.

Why not report in the panel's own 568x1232 space, which is what a reader would expect: the driver cannot. goodix_berlin_core.c reports through touchscreen_report_pos(), which applies the swap and invert properties and does not scale; touchscreen-size-x/y only declare the advertised maximum, and the controller's raw values pass through unchanged. Pre-scaling in the kernel would mean patching the backport further and discarding digitizer resolution. Reporting the native grid and letting the consumer map it to the display is the ordinary Linux arrangement.

The GT9895 is not supported by the pinned kernel and its support SHALL be carried as an explicit patch, recorded with what was backported and from where, so the cost of the pin is visible when the kernel is next moved.

What the project HAS is LilyGO's RT-Smart gt9895.c (219 lines): not a Linux driver, but a working register-level description of this part on this board.

The route SHALL therefore be chosen by experiment rather than asserted. The goodix,gt9916 compatible is a one-word change and the Berlin generation shares a programming model, so whether the existing driver drives this part is cheap to discover once the board boots — and the answer decides between teaching the mainline driver the GT9895 and porting the vendor one.

<!-- Grounding: installed board/service evidence in docs/evidence/the-touchscreen-becomes-an-hdmi-trackpad/board/ and overall physical operator acceptance in docs/evidence/proposal-closeout/2026-10-01/trackpad.md. Additional capture is waived. Individual unreported gesture cases are not new physical proof. -->

While an HDMI connector is the active display output, the GT9895 touchscreen's raw ABS_MT_* contact stream SHALL be exclusively grabbed (EVIOCGRAB) and re-emitted through a virtual uinput device declared with touchpad properties (INPUT_PROP_POINTER + INPUT_PROP_BUTTONPAD, BTN_TOOL_FINGER/ _DOUBLETAP/_TRIPLETAP, no INPUT_PROP_DIRECT), so that libinput classifies it as a touchpad and provides pointer motion, tap-to-click, two-finger scroll, and pinch/swipe gestures for the HDMI session, in place of the panel-mode absolute touch-to-output mapping. Qualified two-contact shell gestures and three-contact bottom keyboard gestures may instead translate to the existing logical touch policies through the bounded shell gesture path; ordinary application center scrolling/pinch and pointer input remain on the touchpad path. While the panel (not HDMI) is the active output, the touchscreen SHALL be left ungrabbed and unmodified, continuing to report absolute coordinates as display/touch's existing digitizer-range requirement already states.

The project MAY describe the board's Goodix-compatible touch controller in the opt-in mainline DRM device tree. It SHALL preserve the candidate's reported digitizer dimensions and GPIO/interrupt source from the board DTS, and SHALL record serial probe evidence separately from physical touch acceptance. Coordinate mapping and physical touch behavior remain UNVERIFIED until deliberate on-panel interaction is recorded.

On the mainline full shell, a deliberate finger tap or drag on the panel SHALL reach sway and change what the shell shows, as it does under the vendor kernel.

Touch's reset (GPIO24) and interrupt (GPIO23) lines SHALL be treated as shared with the optional LT9611 HDMI bridge, not as touch-exclusive pins, by any future change to this capability. The panel's own reset and enable lines (GPIO22/GPIO25) are not part of this sharing and are unaffected.

The vendor baseline nix/dts/k230-tdisplay.dts carries touch only, matching the vendor sources surveyed (docs/research/hdmi-hotplug.md §3). The later mainline HDMI tree from task group 7 combines touch and LT9611 without giving the bridge reset/IRQ ownership: its polling bridge waits for the touch driver to bind before programming the shared-reset device. That matching trial and the operator's acceptance are recorded in docs/evidence/hdmi-mainline/README.md.

When the compositor has restarted since the last two-finger gesture, the trackpad relay SHALL reconnect and still deliver the next qualified two-finger gesture rather than drop it. A multi-finger contact that stays still SHALL reach libinput only when it moves, changes spread or contact count, or lifts. A still press that lifts SHALL be presented to libinput as a tap, so a still two-finger press of any duration is a secondary click.