No check in this repo reads a real input device — all four feed their own events #28

New Issue

fabi · 2026-09-13T12:45:24Z

fabi commented

2026-09-13 12:45:24 +00:00

Four defects in a row this week were invisible to every check in this repo, for one reason: each instrument supplies the input it then measures.

instrument	what it feeds
`verify-input`'s `repeat` rows	call `repeat_due()` directly
`--script=down,accept`	`InputEventAction` — bypasses the input map
`--script=hold:down:2.0`	injects one `InputEventJoypadMotion`
`--input-probe`	reads the device — the only one, added 2026-09-13

The first three agree with each other by construction. On 2026-09-13 all three were green while a held stick moved the cursor once, because held_direction() read the stick's position out of the event history and no synthetic test could tell the difference.

gamepad.gd has opened with this lesson since 2026-09-01 — "a synthetic-input test asserts the code after the input map, never the input map itself" — and it was written after a human found the previous instance. It has now caught us twice with the warning already in the file.

This is a shaping request, not a fix. What, if anything, can assert the device path unattended? Options worth weighing rather than assuming: Godot's --headless with a virtual gamepad (uinput), a recorded device trace replayed at the driver level, or the honest answer that this class requires a human and the right move is a short, written play-test checklist run before any input change merges.

Pass: either a mechanism that fails when the device path breaks, or a written argument that no such mechanism exists here and a checklist in its place. Both are answers.

Four defects in a row this week were invisible to every check in this repo, for one reason: **each instrument supplies the input it then measures.** | instrument | what it feeds | |---|---| | `verify-input`'s `repeat` rows | call `repeat_due()` directly | | `--script=down,accept` | `InputEventAction` — bypasses the input map | | `--script=hold:down:2.0` | injects one `InputEventJoypadMotion` | | `--input-probe` | **reads the device** — the only one, added 2026-09-13 | The first three agree with each other by construction. On 2026-09-13 all three were green while a held stick moved the cursor once, because `held_direction()` read the stick's position out of the event history and no synthetic test could tell the difference. `gamepad.gd` has opened with this lesson since 2026-09-01 — *"a synthetic-input test asserts the code after the input map, never the input map itself"* — and it was written after a human found the previous instance. It has now caught us twice with the warning already in the file. **This is a shaping request, not a fix.** What, if anything, can assert the device path unattended? Options worth weighing rather than assuming: Godot's `--headless` with a virtual gamepad (`uinput`), a recorded device trace replayed at the driver level, or the honest answer that this class **requires a human** and the right move is a short, written play-test checklist run before any input change merges. **Pass:** either a mechanism that fails when the device path breaks, or a written argument that no such mechanism exists here and a checklist in its place. Both are answers.

fabi added the state/proposed kind/defect labels 2026-09-13 12:45:34 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: fabi/Sylpheed#28