touch-probe.txt

The GT9895 binds to the backported goodix_berlin driver.
Captured on hardware 2026-09-20, extracted from docs/evidence/panel-probe.txt.

Device tree declares, in nix/dts/k230-tdisplay.dts:

    touchscreen@5d {
        compatible = "goodix,gt9895", "goodix,gt9916";
        reg = <0x5d>;
        reset-gpios = <&gpio0_ports 24 GPIO_ACTIVE_LOW>;
        interrupt-parent = <&gpio0_ports>;
        interrupts = <23 IRQ_TYPE_EDGE_FALLING>;
    };

Kernel log:

    [    1.495480] goodix-berlin-i2c 1-005d: supply avdd not found, using dummy regulator
    [    1.495631] goodix-berlin-i2c 1-005d: supply iovdd not found, using dummy regulator
    [    1.652309] input: Goodix Berlin Capacitive TouchScreen as \
                   /devices/platform/soc/91408000.i2c/i2c-1/1-005d/input/input0

Resulting input device:

    $ cat /proc/bus/input/devices
    I: Bus=0018 Vendor=0000 Product=0000 Version=0000
    N: Name="Goodix Berlin Capacitive TouchScreen"
    P: Phys=input/ts
    S: Sysfs=/devices/platform/soc/91408000.i2c/i2c-1/1-005d/input/input0
    H: Handlers=mouse0 event0
    B: PROP=2
    B: EV=b
    B: ABS=261800000000003

    $ ls -l /dev/input/
    crw-rw---- 1 root input 13, 64 event0
    crw-rw---- 1 root input 13, 32 mouse0

WHAT THIS SETTLES

Task 4.1 asked which driver can drive this part, by experiment rather than
assumption. The answer is the v6.12 goodix_berlin backport, reached through
the "goodix,gt9916" fallback compatible.

It binds at address 0x5d on i2c-1 and registers an input device with
PROP=2 (INPUT_PROP_DIRECT, i.e. a touchscreen rather than a trackpad) and a
multitouch ABS bitmap. The driver reads its register layout off the part at
runtime from the IC-info blob at 0x10070 -- see gt9895-touch.md -- and
neither goodix_berlin_read_version() nor goodix_berlin_get_ic_info() logged
a failure, so the GT9895 answers the Berlin protocol.

Task 4.1b therefore resolves to NEITHER of its two branches. No gt9895_data
chip entry is added, because the driver has no chip table to add one to. No
port of LilyGO's RT-Smart gt9895.c is needed, because the backport works.
The only change required was the fallback compatible in the device tree.

STILL UNPROVEN

That it binds is not that it tracks. Task 4.3 requires an evtest transcript
of a deliberate drag, to show coordinates follow the finger and that the axes
are neither swapped nor mirrored on a portrait panel. Not yet captured.

The two "dummy regulator" lines mean avdd and iovdd are not described in the
device tree. The panel works, so they are evidently supplied in hardware,
but the device tree does not model them.


=====================================================================
2026-09-21 UPDATE: it binds, but it does not report
=====================================================================

Two evtest runs, 22s and 40s, with a finger dragged across the panel:
39 lines of output each time, all of it evtest's capability dump, and
ZERO "Event:" lines. No touch events at all.

The interrupt is wired and requested:

    $ cat /proc/interrupts
    87:     4   gpio-k230  23 Edge      goodix-berlin

Four interrupts since boot. A 40-second drag would produce thousands.
So the line is correct, the driver claimed it, and the controller is not
asserting it when the panel is touched.

WHAT THIS CORRECTS

Task 4.1 was marked done on the evidence that the backported
goodix_berlin driver binds at 0x5d and registers an input device with
INPUT_PROP_DIRECT. That is still true and is literally what 4.1 asked for
("record whether it binds"). But it was reported here as "the GT9895
answers the Berlin protocol", and that claim is not supported: binding
proves the driver matched a compatible string and created a device node,
not that the controller is talking.

This is the same error made twice elsewhere in this project on the same
day -- treating a successful DSI write as proof the panel received it
(it only proves the controller's FIFO drained), and treating a faithful
transcription as proof it came from live code (it was dead code). The
pattern is accepting a proxy for the thing itself.

WHAT IS ACTUALLY UNKNOWN

- Whether the GT9895 needs a firmware or configuration upload that the
  backported driver does not perform for this part. goodix_berlin reads
  its register layout from the IC-info blob at 0x10070 at runtime; if
  that read is returning something plausible-but-wrong the driver would
  initialise without error and then never see data.
- Whether the IRQ polarity is right. Ours is IRQ_TYPE_EDGE_FALLING from
  the reference board's touch controller, not from any GT9895 source.
- Whether the four interrupts seen are init-time or spurious.

NEXT STEP

Read back the controller over i2c directly -- i2cget on bus 1 address
0x5d -- and compare against what goodix_berlin expects. i2c-tools is in
the image. That distinguishes "the part is not responding" from "the
driver is misreading a part that is".


=====================================================================
i2c probe: the controller is alive and answering
=====================================================================

    $ i2cdetect -y -r 1
    50: -- -- -- -- -- -- -- -- -- -- -- -- -- UU -- --      (0x5d, claimed)

    $ i2ctransfer -f -y 1 w4@0x5d 0x00 0x01 0x00 0x70 r16     # IC info, 0x10070
    0xad 0x00 0x01 0x00 0x00 0x00 0x22 0xfc 0x0b 0x65 0x02 0x01 0x00 0x01 0x00 0x00

    $ i2ctransfer -f -y 1 w4@0x5d 0x00 0x01 0x00 0x00 r8      # 0x10000
    0xaa 0xaa 0xaa 0xaa 0xaa 0xaa 0xaa 0xaa

Real data, not 0xff (dead bus) and not 0x00. The GT9895 is present,
powered, and responding to 32-bit-addressed reads -- the Goodix Berlin
access pattern.

So the earlier framing of the problem was wrong in an instructive way.
"The panel does not answer" was true of the DISPLAY's DCS reads; the
TOUCH controller answers fine. These are different parts on different
buses and they were briefly conflated.

WHAT THIS LEAVES

The controller is alive on i2c and never asserts its interrupt (4 counts
since boot on IRQ 87, where a 40s drag would give thousands). That is a
driver-initialisation mismatch, not absent or broken hardware:
goodix_berlin derives every register address at runtime from the IC-info
blob above, so if a GT9895's layout differs from the GT9916 the driver
was written for, it will initialise without error, compute wrong
addresses, and then wait forever for data that is being written
somewhere else.

That is precisely branch two of task 4.1b -- "port LilyGO's RT-Smart
gt9895.c" -- and the i2c evidence now supports choosing it, where before
the choice rested on the driver merely having bound.

CONCRETE NEXT STEP

Decode the IC-info blob by hand against goodix_berlin_get_ic_info() and
check whether the addresses it derives are plausible. The first bytes
(0xad 0x00 0x01 0x00 ...) are a length and version header in the Berlin
format; if the length field does not match what the driver expects, the
parse silently produces garbage. LilyGO's gt9895.c in
repo/canmv_k230/src/rtsmart/ is the reference for what the layout should
be for this exact part.


=====================================================================
2026-09-21 RESOLVED (pending a boot): wrong interrupt trigger type
=====================================================================

The concrete next step above was taken. Both of its premises turned out
to be false and the answer was somewhere else.

The IC-info blob parses CORRECTLY. Length 0xad = 173 is exactly
2 + 16 + 10 + 4 + 25 + 114 + 2, where 114 is sizeof the driver's misc
struct and 25 is the five variable-length parameter arrays with counts
summing to 10. The decoded version fields are all in range. The parse
cannot be producing garbage.

LILYGO's RT-Smart gt9895.c has NO init sequence, NO config upload and
NO firmware upload -- it opens i2c and polls 90 bytes from 0x00010308,
which is the Berlin layout byte for byte (8-byte header, count in byte
2 low nibble, ten 8-byte points, 2-byte checksum). There is nothing for
a port to add.

The bug is the device tree. `IRQ_TYPE_EDGE_FALLING` was cloned from the
reference board's edt-ft5306 at k230-canmv-v3-lcd.dts:66. A Goodix
Berlin part holds INT low until the host clears the status byte, so it
wants IRQ_TYPE_LEVEL_LOW. caveman99/k230-linux runs this same driver on
this same board on this same kernel with LEVEL_LOW and working
multitouch; its /proc/interrupts line says "Level" where ours says
"Edge".

Also missing: touchscreen-size-x/y, without which the driver advertises
a 65536-unit axis for a 1024x2400 sensor.

Full decode, citations and the confirming sources are in
docs/evidence/gt9895-port.md. The fix is DTB-only.