Is your feature request related to a problem? Please describe.
Describe the solution you’d like
Describe alternatives you’ve considered
Additional context
Edit: And here is a link to the featue request:
https://github.com/issues?q=is%3Aopen+is%3Aissue+archived%3Afalse+user%3Azynthian&issue=zynthian|zynthian-issue-tracking|1704
1 Like
And here’s the first Pull Request:
vangelis ← tunagenes:touch-rotation-90-270
opened 05:50AM - 29 Jun 26 UTC
# multitouch: add 90°/270° axis-swap rotation via `DISPLAY_ROTATION`
**Base:*… * `zynthian/zynthian-ui:vangelis`
**Scope:** zynthian-ui only. Additive; no change to existing `None` / `Inverted` behaviour.
**Companion:** a follow-up webconf + zynthian-sys PR (PR 2) adds a Raspberry Pi Touch Display 2 (7″) display definition and exposes the new rotations in the UI. This PR is usable on its own (see "Note on UI exposure" below).
## Problem
`zyngui/multitouch.py` reads the touch evdev device directly and disables the X-layer xinput device, so every X11 / libinput / evdev coordinate transform is bypassed. The driver maps `ABS_MT_POSITION_X → x_root` and `ABS_MT_POSITION_Y → y_root`, with only `invert_x` / `invert_y` available — **there is no axis swap.** A portrait-native DSI panel run in landscape (90° or 270°) therefore has no working touch path: the picture rotates under X, but touch does not follow.
This was hit in practice on a **Raspberry Pi 5 + Raspberry Pi Touch Display 2 (7″)** (portrait-native 720×1280, `ili9881` panel, Goodix `gt911` touch) run in landscape — touch was wrong/dead across half the screen.
## Change
Teach the driver to swap axes, and select the swap/invert flags from the existing `DISPLAY_ROTATION` value.
- `MultiTouch.__init__` gains `swap_xy=False`.
- The X/Y coordinate handling is factored into a pure `MultiTouch._transform_abs(...)` staticmethod. When `swap_xy` is set, a raw panel-X event drives `y_root` and a raw panel-Y event drives `x_root`; the invert flag is chosen by the **destination** axis and the maximum used for inversion is the **source** axis maximum.
- A `MultiTouch.ROTATION_MAP` class constant maps each `DISPLAY_ROTATION` value to `(swap_xy, invert_x, invert_y)`. `zynthian_gui.py` now instantiates the driver from this map instead of the previous hard-coded `Inverted`-only branch.
| `DISPLAY_ROTATION` | rotation | `(swap_xy, invert_x, invert_y)` |
|---|---|---|
| `None` | 0° (native portrait) | `(False, False, False)` |
| `Right` | 90° landscape | `(True, False, True)` — **verified on TD2** |
| `Inverted` | 180° | `(False, True, True)` — **unchanged** |
| `Left` | 270° landscape | `(True, True, False)` — mirror of `Right`, see below |
## Why `DISPLAY_ROTATION` (and not a new variable)
`DISPLAY_ROTATION` is already a touch-only setting:
- In webconf its field is labelled **"Touch Rotation"** (`display_config_handler.py`).
- Its only functional reader is the multitouch instantiation in `zynthian_gui.py` — it has never affected the display.
Display rotation is handled separately (firmware/KMS params and the X11 monitor file generated by zynthian-sys, keyed off `DISPLAY_CONFIG`, not off `DISPLAY_ROTATION`). So adding `Right` / `Left` here completes an existing touch-rotation enum rather than adding new config surface, and it is strictly additive: `zynthian_gui.py` previously special-cased only `Inverted`, with everything else falling through to a plain `MultiTouch(...)`; `None` and `Inverted` map to exactly their previous flag combinations.
I'm happy to switch this to a dedicated variable (e.g. `ZYNTHIAN_TOUCH_SWAP_XY` + invert flags) if maintainers prefer — `multitouch.py` would be untouched and only the small `zynthian_gui.py` selection block would change.
## `Right` is verified; `Left` is not
`Right` `(True, False, True)` was derived from labelled `evtest` corner data on the reference TD2 unit and confirmed working (full width responsive, taps land true). The included test uses that corner data as the oracle.
`Left` (270°) is provided as the exact 180° mirror of `Right` and is checked for that self-consistency in the test, but it has **not** been confirmed on hardware. This is noted in the code (`ROTATION_MAP` comment) and the test. If maintainers would rather not ship an unverified path, `Left` can be dropped to land `Right` only, and added once someone verifies a 270° mounting.
## Tests
New `zyngui/multitouch_rotation_test.py` (runs standalone or under pytest):
```bash
python3 zyngui/multitouch_rotation_test.py
```
Covers: `ROTATION_MAP` keys and the unchanged `None` / `Inverted` flag values (regression lock); `None` = identity; `Inverted` = both axes flipped; `Right` exact mapping against the TD2 corner data plus a per-corner quadrant check ("not mirrored"); and `Left` as the 180° mirror of `Right`. The test stubs `tkinter` / `tkinterweb` / `evdev` / `zynthian_gui_config` so it imports the real class with no GUI, display, or touch hardware present.
## Note on UI exposure (intentional)
This PR does not touch webconf. After it merges, `DISPLAY_ROTATION=Right` / `Left` works but is reachable only by editing `zynthian_envars.sh`; the "Touch Rotation" dropdown still offers only `None` / `Inverted`. Adding those options to the dropdown, plus a TD2 display definition that selects landscape by default, comes in the companion PR (PR 2). The brief window where the capability is env-settable only is intentional.
## Discussion
https://discourse.zynthian.org/t/add-support-for-the-raspberry-pi-touch-display-2-7-inch-screen-to-zynthian-vangelis-feature-request-1704/13332?u=tunagenes
2 Likes
And these 2 complete the set of 3,
vangelis ← tunagenes:display-rotation-90-270
opened 12:44AM - 30 Jun 26 UTC
# update_zynthian_sys: drive X11 display rotation from DISPLAY_ROTATION (add 90°… /270°)
**Base:** `zynthian/zynthian-sys:vangelis`
**Part of a set:** pairs with a `zynthian-webconf` PR (adds the Touch Display 2 option + Right/Left in the UI) and builds on `zynthian/zynthian-ui#580` (touch-side rotation). Links below.
## Problem
`update_zynthian_sys.sh` generates the X11 monitor file that rotates the screen, but only for the 180° case: it writes `Option "Rotate" "inverted"` when `DISPLAY_CONFIG` contains the `display_lcd_rotate=2` sentinel. There is no path for 90°/270°, so a portrait-native DSI panel (e.g. the Raspberry Pi Touch Display 2) cannot be brought up in landscape through configuration — the picture stays portrait.
## Change
Replace the inverted-only block with a small `case` on `DISPLAY_ROTATION`:
- `Right` → `Option "Rotate" "right"` (90°)
- `Left` → `Option "Rotate" "left"` (270°)
- `Inverted` → `Option "Rotate" "inverted"` (180°)
written to a single `69-display_rotation.conf` (the existing `69-display_*.conf` cleanup glob still covers it, so no stale files).
### Design note (worth a maintainer opinion)
This keys the X11 screen rotation off **`DISPLAY_ROTATION`**, the same variable `zynthian-ui` already uses for touch rotation (see #580). The intent is that one setting rotates both layers together, which is what a user mounting a panel sideways expects. This does widen `DISPLAY_ROTATION` from touch-only to touch + display; an alternative would be a `DISPLAY_CONFIG` sentinel mirroring `display_lcd_rotate=2`. Happy to switch to the sentinel approach if you'd prefer to keep the variable touch-scoped — it's a localized change to this block.
### Backward compatibility
The legacy `display_lcd_rotate=2` sentinel is kept as a fallback: if `DISPLAY_ROTATION` is unset/`None` but that sentinel is present, the script still produces an inverted screen. So existing inverted displays (including the V5 legacy fixup earlier in this script) are unaffected. Verified behaviour:
| `DISPLAY_ROTATION` | `DISPLAY_CONFIG` has sentinel | result |
|---|---|---|
| `None` | no | no rotation file (unchanged) |
| `Right` | no | `Rotate "right"` (new) |
| `Left` | no | `Rotate "left"` (new) |
| `Inverted` | yes | `Rotate "inverted"` (unchanged) |
| `None` | yes (legacy) | `Rotate "inverted"` (preserved) |
## Testing
Verified on a Raspberry Pi 5 + Raspberry Pi Touch Display 2 (7″): with `DISPLAY_ROTATION=Right` the panel comes up in landscape and, combined with #580, touch tracks correctly across the full screen.
## Related
- zynthian-ui: zynthian/zynthian-ui#580 (touch-side 90°/270° rotation)
- zynthian-webconf: github.com/zynthian/zynthian-webconf/pull/200 (Touch Display 2 display option + Right/Left in the dropdown)
…/270)
vangelis ← tunagenes:display-td2-7inch
opened 01:05AM - 30 Jun 26 UTC
# display: add Raspberry Pi Touch Display 2 (7″) option + 90°/270° rotation in t… he UI
**Base:** `zynthian/zynthian-webconf:vangelis`
**Part of a set:** pairs with a `zynthian-sys` PR (X11 screen rotation) and builds on `zynthian/zynthian-ui#580` (touch rotation). Links below.
## What this adds
1. **A "Raspberry Pi Touch Display 2 (7″)" display preset**, defaulting to landscape. Selecting it sets the values verified on a real Pi 5 + TD2 unit:
```
DISPLAY_CONFIG: disable_overscan=1
dtoverlay=vc4-kms-dsi-ili9881-7inch
DISPLAY_WIDTH: 1280
DISPLAY_HEIGHT: 720
DISPLAY_ROTATION: Right
DISPLAY_KERNEL_OPTIONS: (empty)
FRAMEBUFFER: /dev/fb0
```
The TD2 is a portrait-native panel (720×1280, `ili9881`, Goodix `gt911` touch); these values bring it up in landscape. Rotation is handled via `DISPLAY_ROTATION=Right` (touch in `zynthian-ui`, screen in `zynthian-sys`) rather than an overlay rotate param, which is inert for this panel on the current KMS stack.
2. **`Right` and `Left` options in the rotation dropdown**, so 90°/270° are selectable in the UI instead of requiring a hand-edited env var.
3. **Renamed the dropdown title "Touch Rotation" → "Display Rotation".** With the paired `zynthian-sys` change, `DISPLAY_ROTATION` now rotates both touch and screen, so the touch-only label was no longer accurate. This is a deliberate consequence of keying screen rotation off `DISPLAY_ROTATION`; if you'd rather keep the variable touch-scoped (and the old label), say so and I'll revert both this and the sys keying.
## Dependencies
- The preset's `DISPLAY_ROTATION=Right` only rotates the **screen** once the `zynthian-sys` PR lands, and only rotates **touch** once zynthian/zynthian-ui#580 lands. Until both merge, selecting the preset sets the values but full landscape behaviour isn't active.
- Additive otherwise: no existing preset is changed, so this hurts nobody who doesn't select it.
## Notes
- Only a landscape (`Right`) preset is added. Other mountings (portrait, 270°) are reachable by changing the rotation dropdown, though portrait would also want the width/height swapped — left out to keep this focused; easy to add a variant if wanted.
## Related
- zynthian-ui: zynthian/zynthian-ui#580 (touch-side 90°/270° rotation)
- zynthian-sys: github.com/zynthian/zynthian-sys/pull/224 (X11 screen rotation via DISPLAY_ROTATION)
All 3 together give the support for rotating from a default portrait mode, PR1 (580) adds the actual support to multitouch.pi and the combination of PR2 (224) zynthian.sys and PR3 (200) webconf provide the user interface to set it and change it from default, which is Landscape, Rotate Right.
Claude and I could not find a way to have a PR cover multiple repos, that’s the main reason there are 3.
2 Likes
For PR3 (200) webconf - There was a problem with the first pr uploaded - a double quote in the touch display 2 entry, we removed it and then did: git push --force-with-lease origin display-td2-7inch
1 Like
Also re PR3 (200) webconf - Made this comment in the PR - Verified on Pi 5 + TD2: Right works; Left is accepted by X but not honored by the DSI/KMS scanout on this panel (display stays right), so 270° appears to be a panel/driver limitation rather than a config issue. Right/Inverted are the usable orientations here. We considered changing to not allow “left” to be selected, but decided not to in case other layers do support it in the future.
1 Like