Video audit: real-touch keyboard trial

The source is 20260923T000200Z-keyboard-real-touch.mp4, SHA-256 891ff11bac41d4153ed044baf6d72cfab2f78437187d5590b84239255f5db27c. ffprobe reports H.264, 1920x1080, 30/1 fps, and 85.033 seconds. The JSON manifest records 180 seconds as the requested maximum and 85.033333 seconds as the actual duration. The capture ended after the operator reported done and SIGINT finalized the container. The manifest also identifies the interaction as operator-declared real touch; that field is not itself proof of finger input.

Camera observations

I reviewed the full recording at one frame per second and inspected the show/typing portions at the native 30-fps cadence. The camera visibly records a finger/hand contacting the panel at several points while the terminal remains on screen. The opening frame shows the terminal with no legible keyboard keys. Later frames show the hand over the lower display and a dim lower-screen region, but glare, angle, and the hand prevent reliable key-grid or key-label reading. The camera therefore supports visible hand contact and terminal state changes, but does not independently establish each keyboard show/hide/show transition.

The native captures provide a clearer state check: during-test-native.png and after-test-native.png both show the keyboard visible. No native hidden-state capture is present in this directory, so the complete show/hide/show sequence remains only partially evidenced by the artifacts.

Representative physical frames are physical-keyboard-hidden.png (video 0 s, SHA-256 699a0eb71ddfd1a16cc438ba9476960cd64da7da64474ba81705b5d8fec17534), physical-keyboard-shown.png (video 15 s, SHA-256 6930b7368e408187b3d9a320f608909aee2b93f8bfb6653c639f1fe65295f3ca), and physical-typed-output.png (video 80 s, SHA-256 7168cfc491aba317481d812179ef49c50ff4019a301c1002be40e843090035f9). The last frame is deliberately described as camera evidence of terminal text; the text is too blurred there for character-by-character transcription.

Input and text evidence

input-mapping-json.txt identifies the Goodix touch input and reports send_events: enabled with the identity calibration matrix (lines 18–31). touch-events.txt contains real evdev contacts from that device, including touch-down/up sequences and movement in the lower device range (for example lines 107–176). This establishes that the kernel/libinput path received physical-device contacts during the test. It does not prove that every contact landed on the intended on-screen key.

The native after-test capture shows two commands: an initial exho command that fails, followed by a successful echo command. Its visible argument and output appear to be 1qazoplm, using the letter o. This asymmetric string is useful for detecting a rotation or mirror error, but it does not establish the requested 1qaz0plm string with a zero. The initial exho typo and this letter-versus-zero discrepancy keep per-key accuracy/calibration open; treat the successful follow-up as output evidence only.

The recording does not prove a full calibrated touch workflow, complete key accuracy, or a power-on/cold-boot scenario.