Touch controls added#4
Conversation
…changed Add display_rotator to rotate framebuffer pages and update service/README
|
@codex[agent] check the issue |
[WIP] Add touch controls to improve user interaction
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 027d132933
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if now - last_tap_ts <= DOUBLE_TAP_WINDOW_SECS: | ||
| cmd_q.put("TOGGLE_SCREEN") | ||
| last_tap_ts = 0.0 | ||
| else: | ||
| cmd_q.put("PREV" if last_x < (touch_width // 2) else "NEXT") |
There was a problem hiding this comment.
The double-tap path still performs a page navigation because the first tap immediately enqueues PREV/NEXT, and the second tap only adds TOGGLE_SCREEN; in practice, users trying to turn the display off/on with a double tap will also rotate to another page. This contradicts the documented gesture behavior and is reproducible whenever two tap-release events occur within DOUBLE_TAP_WINDOW_SECS.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
@codex[agent] What if there was a 0.3s delay between a single tap and page change? script waits for the second tap and if it's within 0.3s it treats it as double tap, if after 0.3s it's single? Is this a good idea??
| candidates = sorted(glob.glob("/dev/input/event*")) | ||
| return candidates[0] if candidates else None |
There was a problem hiding this comment.
Auto-selection currently binds to the first /dev/input/event* node, which is often a keyboard or other non-touch device on Raspberry Pi setups; when that happens, touch events are never seen and controls silently stop working unless ROTATOR_TOUCH_DEVICE is manually set. Selecting by capability (or at least validating touch events) would avoid this common misbinding.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
@codex[agent] Please provide further explanation
There was a problem hiding this comment.
Absolutely — here’s the clarification for that review note on display_rotator.py line 127.
Why the reviewer flagged line 127
At line 127, auto-selection is:
return candidates[0] if candidates else NoneSo the script takes the first /dev/input/event* device found, without checking whether it is actually a touchscreen. In many Raspberry Pi/Linux setups, event0 is often a keyboard, GPIO button input, or another non-touch device, so touch events (BTN_TOUCH, ABS_X, etc.) never arrive in touch_worker. That makes touch controls appear broken unless ROTATOR_TOUCH_DEVICE is manually configured. display_rotator.pyL122-L127 display_rotator.pyL155-L168
Why this matters in practice
touch_worker() assumes the selected node emits:
- absolute X coordinates (
EV_ABSwithABS_X/ABS_MT_POSITION_X), and - touch press/release (
EV_KEYwithBTN_TOUCH).
If the bound device does not expose those capabilities, none of the gesture logic will execute meaningfully. So the root issue is device capability mismatch, not gesture parsing itself. display_rotator.pyL155-L168
What “detect touch-capable input” would mean
A robust selector would iterate /dev/input/event* and pick one that advertises touch-relevant capabilities (e.g., BTN_TOUCH + absolute position axis), rather than first-in-list. The existing environment override can remain as a manual fallback. display_rotator.pyL123-L127
Commands I used
pwd && rg --files -g 'AGENTS.md'nl -ba display_rotator.py | sed -n '100,190p'python - <<'PY' ... urllib request to duckduckgo ... PY(attempted web lookup; blocked by proxy 403)curl -I https://www.kernel.org/doc/html/latest/input/event-codes.html | head(attempted web lookup; blocked by proxy 403)
If you want, I can draft a concrete capability-based select_touch_device() patch next (minimal and dependency-free).
Summary
Testing
|
Co-authored-by: openai-code-agent[bot] <242516109+Codex@users.noreply.github.com>
2 participants
No description provided.