jason/socktop-swipe
1
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

v2 release prep: installer, README, packaging, notes; retire the v1 scripts

Browse Source 
Installer rewritten around a preflight: distro, package manager, display
manager, window manager, terminal, tmux, cargo, git, screen locker, touch
device, device permissions and free disk are all checked BEFORE anything is
installed, and the total cost is printed once for a single confirmation.
Prompts read /dev/tty so they still work when the script is piped from curl,
and fall back to defaults with a notice when there is no terminal at all.

Several "[ test ] && action" statements were set -e landmines: under set -e an
AND-OR list that ends up false aborts the script, so a box with no lightdm, no
i3 or nothing to install would have exited silently partway through detection
-- which is exactly the fresh-Debian case the installer exists for. Rewritten
as if-statements and verified against a stripped PATH with no tmux, cargo, git
or package manager present. Also fixed cargo detection reporting blank instead
of NOT INSTALLED: the status of `cargo --version | cut` is cut's, and cut
succeeds on empty input, so the fallback never fired.

Device access now defaults to a udev rule matching touchscreens only, rather
than the input group, which grants access to every input device including the
keyboard and needs a full logout.

README rewritten for someone who has not seen the project: what the photo
shows, the hardware, install, then a config built up step by step, each step
with the YAML and the resulting map. Every example is verified verbatim
against the binary, and every relative link resolves. The mechanism and the
reasoning move to notes/: DESIGN.md, HARDWARE-NOTES.md, V1-BASH.md, TODO.md.

cad/README.md was a verbatim copy of the one inside
geeekpi_rack_adapter_release_v1/, so every path in it -- including the
screenshot -- was broken from where it sits. Corrected to its own level, and
it now states once that the 9-inch screen, the 10-inch mini-rack mount and the
19-inch rack are three different measurements.

The v1 shell implementation is removed; it stays recoverable at tag v1.2 and
notes/V1-BASH.md carries the setting-by-setting migration table.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
jasonwitty
2026-09-09 13:08:42 -07:00
parent 9f082b52b7
commit ce6acec299
29 changed files with 1388 additions and 1089 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+282 -235
View File
@@ -1,298 +1,345 @@
# socktop-swipe
Swipe-to-zoom touchscreen navigation for a wall-mounted
[socktop](https://crates.io/crates/socktop) dashboard.
A rack-mounted touchscreen you swipe through to see what your machines are doing.
Hosts are arranged in **groups**. Each group is one tmux window showing its
hosts tiled together. Swiping right-to-left on the panel zooms into each host
full-screen, one at a time, then moves on to the next group's overview; swiping
left-to-right walks back the same way.
Terminal dashboards are arranged in a grid. Swipe left and right to move along a
row; swipe up and down to move between rows. A group of hosts is one place in
that grid: it shows them tiled together first, then each one full-screen as you
keep swiping.
```
group A -> A1 -> A2 -> A3 -> A4 -> group B -> B1 -> B2
(quarters) zoomed zoomed zoomed zoomed (stacked) zoomed zoomed
<------------------------- swipe left-to-right -------------------------
```
With a single group this is simply overview -> each host -> back.
Optionally, swiping **down** from any screen shows a different TUI (an
[Uptime Kuma](https://github.com/louislam/uptime-kuma) status page on the rack
display), and swiping **up** returns to exactly the screen you left.
Built for a 10" touch panel on a server rack driving four Raspberry Pis, on a
low-power x86 box running i3 on X11.
## What it looks like
The panel in place, showing the four-Pi group overview:
![The touch panel mounted in the rack, showing all four Raspberry Pis tiled](media/rack-display.jpg)
Swiping through the carousel ([media/swipe-demo.mp4](media/swipe-demo.mp4)):
![The touch panel mounted in the rack, showing four Raspberry Pis tiled together](media/rack-display.jpg)
<video controls src="media/swipe-demo.mp4"></video>
## How it works, and why
Built for a 9" panel bolted into a 19" server rack, driven by a low-power x86 box
running i3 on X11.
**The carousel is tmux pane zoom, not extra socktop instances.** There is exactly
one socktop process per host. Zooming calls `tmux resize-pane -Z`, which makes one
pane fill the window and sends `SIGWINCH` so socktop repaints at the new size.
## What you're looking at
That matters for three reasons:
The photo is a 9" touchscreen in a 19" rack, showing four Raspberry Pis at once
via [socktop](https://github.com/jasonwitty/socktop). It is a wall display: no
keyboard, no mouse, nothing to log into. It comes back by itself after a power
cut and it never blanks.
- **Half the processes.** Separate full-screen instances would mean N extra
socktop processes and double the polling load on the monitored hosts. On a
1.9 GB display host, that is the difference between comfortable and not.
- **No reconnect delay.** Hidden panes keep running and stay connected, so
swiping back to a host shows current data, not a stale snapshot.
- **Constant load.** The monitored hosts see the same connections regardless of
what is on screen.
Everything on it is a terminal program. socktop-swipe does not draw anything
itself — it decides what is on screen and reads your finger.
**Gestures come from lisgd, below the terminal.** No Linux terminal maps
horizontal swipes to commands, so this cannot be done in terminal config.
Critically, **libinput deliberately emits gesture events only for touchpads,
never for touchscreens** — so `libinput-gestures` and similar tools cannot work
here at all. [lisgd](https://git.sr.ht/~mil/lisgd) reads raw touch events and
synthesises the swipes itself, reading `/dev/input` directly and bypassing X.
```
unifly -1x0
(UniFi network)
↕
┌──────────────────────────────┐ ┌──────────────────┐
│ 4 Raspberry Pis │→ │ 2 more machines │ row 0
│ tiled, then each full-screen│ │ │
└──────────────────────────────┘ └──────────────────┘
0x0 0x1
↕
uptime kuma 1x0
(service status)
```
## Requirements
Swipe forward through row 0 and you get: all four Pis tiled, then `rpi-master`
full-screen, then each of the others, then on to the next group. Swipe up at any
point for the UniFi network view; swipe back down and you are on the exact host
you left.
- `tmux`, `socktop`, and a working `~/.config/socktop/profiles.json`
- `lisgd` (the installer builds it)
- A C toolchain plus `libinput` and `libX11` headers, to build lisgd
- Membership of the `input` group (the installer adds you; needs a relogin)
## Hardware
| Part | What was used | Notes |
| --- | --- | --- |
| Display host | LattePanda (Atom x5-Z8350, 1.9 GB) | Debian 11, i3 on X11 |
| Display host | Dell Wyse 3040 (Atom x5-Z8350, 2 GB) | ~$35 used; 8/16 GB eMMC, DP out |
| Panel | GeeekPi 9" 1280x720 3U touchscreen | ILITEK USB touch |
| Mounting | [`cad/`](cad) — 19" rack adapter | 3D-print or laser-cut aluminium |
Any Linux box with a USB or DSI touchscreen will do. It is deliberately modest
hardware: the whole point is a display that idles at a few watts.
The panel is sold as a **10-inch mini-rack** part. [`cad/`](cad) has a pair of
side adapters — OpenSCAD source, STLs with tested print settings, and
SendCutSend-ready DXFs — that mount it in a standard **19-inch** rack, with three
keystone jack positions on each side. The geometry has been physically tested.
## Install
```sh
curl -fsSL https://gt.wittyoneoff.com/jason/socktop-swipe/raw/branch/main/install.sh | sh
```
It checks everything first and prints the whole cost — packages, toolchain, disk
— before changing anything. Then it asks, one thing at a time:
- which touch device to use (it looks for one and offers it)
- how to grant access to it: a udev rule for touchscreens only, or the `input`
group
- whether to install socktop, uptime-kuma-status or unifly
- whether to stop the screen blanking, sleeping and locking
- whether to autostart on login
- whether to log straight in at boot, so it comes back after a power cut
Every answer has a sensible default and nothing is required. Piping into `sh`
leaves no keyboard on standard input, so the script reads your terminal directly;
if there is no terminal at all it takes the defaults and says so. `--yes` skips
the questions.
There are no prebuilt binaries yet — it builds from source, so a Rust toolchain
is installed if you do not have one. Budget about 1.8 GB and, on an Atom, twenty
minutes or so.
<details>
<summary>From a checkout instead</summary>
```sh
git clone https://gt.wittyoneoff.com/jason/socktop-swipe
cd socktop-swipe
./install.sh --xignore --i3
./install.sh
```
</details>
Then **log out and back in** — the `input` group and the X rule both need a
fresh session.
## Your first config
| Flag | Effect |
| --- | --- |
| *(none)* | Build/install lisgd, install the three scripts and the default config |
| `--xignore` | Also tell X to ignore the touch panel (see below — usually wanted) |
| `--i3` | Also add i3 autostart lines (gesture daemon, fullscreen terminal, idle-pointer hiding via `unclutter-xfixes`), with a backup and `i3 -C` validation |
| `--noblank` | Also stop the screen blanking / DPMS power-down (wall displays) |
| `--autologin` | Also make lightdm log this user straight into i3 at boot (see [security note](#related-does-the-display-come-back-by-itself)) |
The config lives at `~/.config/socktop-swipe/config.yaml`. The installer writes a
starting point; this section builds one up from nothing.
Re-running is safe: an existing config file is never overwritten, and the i3
edit is skipped if already present.
### Verify
**Check every edit** with:
```sh
tools/find-device.sh # confirm TOUCH_DEV is right
tools/diag.sh # stage 1: device live? stage 2: what does lisgd see?
tools/test-foreground.sh # run the real daemon, watch the display, swipe
socktop-swipe validate
```
## Configuration
which resolves the grid, prints the map, and tells you if a program it would run
is not actually there.
Everything lives in **`/usr/local/etc/socktop-swipe.env`**. Edit it there, not in
the repo copy. After changing it, restart the daemon and rebuild the session:
### One group of hosts
```sh
socktop-gestures --replace & # restarts the daemon, running or not
socktop-rack
```yaml
touch:
device: /dev/input/by-id/usb-ILITEK_ILITEK-TOUCH-event-if00
width: 1280
height: 720
screens:
- at: "0x0"
type: socktop
socktop_group: [rpi-master, rpi-worker-1, rpi-worker-2, rpi-worker-3]
```
Use `--replace` rather than `pkill -x lisgd && socktop-gestures`: `pkill` exits
non-zero when it matches nothing, so that one-liner silently starts **nothing**
if no daemon was running — you would swipe, get no response, and reasonably
blame the config change.
That is five screens: the four hosts tiled, then each one full-screen.
| Option | Default | What it does |
```
0x0 tiled → rpi-master → rpi-worker-1 → rpi-worker-2 → rpi-worker-3
```
> **Quote the coordinate.** Unquoted, YAML reads `0x0` as the hexadecimal number
> zero. `socktop-swipe validate` will tell you so if you forget.
### Something above it
```yaml
- at: "-1x0"
type: unifly
```
Row `-1` is above row `0`. Now swiping up from any of those five screens shows
the UniFi TUI, and swiping down returns you to the exact host you were on.
### Something below, and more hosts alongside
```yaml
- at: "0x1"
type: socktop
socktop_group: "orangepi, trixie"
layout: even-vertical
- at: "1x0"
type: uptime-kuma-status
url: https://status.example.com/status/mine
```
`0x1` sits to the right of `0x0`, so you reach it by swiping forward past the
last Pi. `1x0` is below.
Full worked example with every option commented:
[`config.example.yaml`](config.example.yaml).
## How the grid works
**Row increases downward.** `-1x0` is above `0x0`; `1x0` is below it. Column
increases rightward. You start at `0x0`.
**Coordinates are ordering, not slots.** Only their sort order matters, so `0x1`
and `0x5` are interchangeable. You never have to count how many screens a group
produces in order to place something next to it — add a host to a group and
nothing else needs renumbering.
**A group of hosts is one place in the grid.** Swiping forward walks its screens
— tiled overview, then each host — and only moves on to the next place after the
last one. Coming back from the right lands you on that group's *last* host, not
its overview, so the row reads as one continuous strip.
**Swiping up or down returns you to where you were.** Each row remembers its
position. If you glance at the network view and come back, you are on the same
host, still zoomed.
**Nothing wraps around.** Swiping past either end of a row does nothing. On a
wall display, wrapping makes it impossible to tell where you are.
If a row has no screen in your current column, you land on the nearest one —
`0x3` swiping up with only `-1x0` above goes there. That only happens the first
time; after that the row remembers.
## Monitor types
Every type also accepts `command:` to replace the generated command outright, and
`title:` to change the label on the pane border.
| `type:` | Parameters | What it runs |
| --- | --- | --- |
| `SOCKTOP_GROUPS` | Pis quartered `;` Orange Pi + Debian stacked | Groups separated by `;`, each a list of socktop profile names **in swipe order**, plus an optional `@layout` (`tiled` default, `even-vertical` stacks, `even-horizontal` side-by-side, `main-*` also work). Any count of groups and hosts works. |
| `SOCKTOP_HOSTS` | empty | Legacy single-group form; used only when `SOCKTOP_GROUPS` is empty |
| `SOCKTOP_AUX_CMD` | `uptime-kuma-status …` | Command for the swipe-down "aux" screen. Full path. Empty disables the feature and its gestures. |
| `GESTURE_AUX_IN` / `GESTURE_AUX_OUT` | `UD` / `DU` | Swipe down shows aux, swipe up returns |
| `SOCKTOP_SESSION` | `socktop4` | tmux session name |
| `SOCKTOP_BIN` | `$HOME/.cargo/bin/socktop` | Full path — i3 does not have `~/.cargo/bin` on `PATH` |
| `TOUCH_DEV` | ILITEK by-id path | Touch device. **Always use a `/dev/input/by-id/` path**; `eventN` numbers change on reboot. |
| `SCREEN_W` / `SCREEN_H` | `1024` / `600` | The **panel's** resolution, not the X screen. See gotcha 2. |
| `SWIPE_THRESHOLD` | `80` | Pixels of travel before a drag counts as a swipe |
| `SWIPE_LENIENCY` | `30` | Degrees off-axis tolerated (max 45) |
| `FINGER_COUNTS` | `1 2 3` | Contact counts accepted. **The setting most likely to need changing** — see gotcha 1. |
| `GESTURE_IN` / `GESTURE_OUT` | `RL` / `LR` | Swap these to reverse swipe direction |
| `socktop` | `socktop_group` (list, or comma-separated string), `layout` | one [socktop](https://github.com/jasonwitty/socktop) per host |
| `uptime-kuma-status` | `url` | [uptime-kuma-status](https://github.com/jasonwitty/uptime-kuma-status) against a public [Uptime Kuma](https://github.com/louislam/uptime-kuma) status page |
| `unifly` | *(none yet)* | [unifly](https://github.com/jasonwitty/unifly) `tui` |
| `generic` | `command`, `title` | anything you like |
### Adding or removing hosts
`layout` takes any tmux layout name: `tiled` (the default), `even-horizontal`,
`even-vertical`, `main-horizontal`, `main-vertical`.
Edit `SOCKTOP_GROUPS` and run `socktop-rack`. Nothing else needs touching — the
carousel derives its length from the windows and panes at runtime. Every host
named must exist in `~/.config/socktop/profiles.json` on the display host.
```sh
# four Pis as quarters, then two more boxes stacked one above the other
SOCKTOP_GROUPS="rpi-master rpi-worker-1 rpi-worker-2 rpi-worker-3 ; orangepi trixie @even-vertical"
```yaml
- at: "1x1"
type: generic
title: k3s
command: journalctl -f -u k3s-agent
```
## Autostart
## Configuration reference
`./install.sh --i3` appends to `~/.config/i3/config`. For systemd user sessions
| Key | Default | What it does |
| --- | --- | --- |
| `session` | `socktop-swipe` | tmux session name |
| `terminal` | *(none)* | Terminal that `run` opens the dashboard in. Unset attaches in the current one |
| `indicator` | `false` | Show position — what is above, where you are, what is below — in the status line |
| `binaries.socktop` etc. | looked up on `PATH` | Full path to each program. `~/` is expanded |
| `touch.device` | — | **Always a `/dev/input/by-id/` path**; `eventN` numbers change on reboot |
| `touch.width` / `.height` | — | The **panel's** resolution, not the X screen |
| `touch.grab` | `true` | Take the panel exclusively so X never sees the touches |
| `touch.threshold` | `80` | Pixels of travel before a drag counts as a swipe |
| `touch.leniency` | `30` | Degrees off-axis tolerated, max 45 |
| `touch.fingers` | `[1, 2, 3]` | Contact counts accepted. **The setting most likely to need changing** |
| `gestures.forward` / `.back` | `RL` / `LR` | Named by finger motion. Swap to reverse |
| `gestures.up` / `.down` | `DU` / `UD` | |
### Commands
| Command | |
| --- | --- |
| `socktop-swipe run` | Build the session, open it in a terminal, read the panel. The one thing to autostart |
| `socktop-swipe validate` | Check the config and print the grid map |
| `socktop-swipe doctor` | Swipe, and be told what the panel reported |
| `socktop-swipe doctor --list` | List touch devices — works before any config exists |
| `socktop-swipe forward` / `back` / `up` / `down` | Move a running instance. For keybindings, or a box with no panel |
| `socktop-swipe build` / `attach` / `daemon` | The pieces of `run`, separately, for a systemd split |
## Unattended operation
A wall display has to survive a power cut with nobody in the room.
**Never blank.** The installer writes an Xorg `ServerFlags` snippet with all four
timeouts at zero, which covers every session including the display manager's
greeter and survives reboots, *and* adds an `xset` line to the session autostart,
because a session can re-enable blanking after X starts. Both are needed. Check
with `xset q | grep -A1 -E 'Screen Saver|DPMS'` — you want `timeout: 0`,
`prefer blanking: no`, `DPMS is Disabled`.
**Come back by itself.** Without autologin, a reboot leaves the panel at a login
prompt and nothing starts. The installer offers a lightdm drop-in. It is opt-in
and defaults to no, because **anyone with physical access to the panel gets that
user's session** — only do it where the account is nothing but the dashboard.
Delete `/etc/lightdm/lightdm.conf.d/50-autologin-socktop-swipe.conf` to undo it.
**Autostart.** `socktop-swipe run` is a single process that builds the session,
opens the terminal and reads the panel, so one line in your window manager's
autostart is enough. For a systemd user session,
[`packaging/socktop-swipe.service`](packaging/socktop-swipe.service) splits it up.
## Troubleshooting
Start here:
```sh
socktop-swipe doctor
```
It watches the panel and says what it saw in English — direction, contact count,
and why a gesture was ignored.
### Swipes are detected but nothing happens
`doctor` will say `saw 2 contact(s), config accepts [1]`. Many multipoint panels
report two or even three contacts for a physically one-finger swipe. Add them to
`touch.fingers`. This is the single most common problem on new hardware.
### Nothing is detected at all
In order: is the device path right (`socktop-swipe doctor --list`)? Can you read
it — is the udev rule installed, or are you in the `input` group and did you log
out and back in? Is the panel plugged in?
### Swipes work, but the terminal also reacts — text zooming, panes resizing
X is delivering touch to whatever is on screen as well. `touch.grab: true` (the
default) prevents this by taking the device exclusively. If you have set it to
`false` because you want touch in other applications, tell X to ignore the panel
instead:
```sh
cp socktop-swipe.service ~/.config/systemd/user/
systemctl --user enable --now socktop-swipe
```
Either way, **run exactly one gesture daemon**. lisgd does not grab the input
device exclusively, so two instances make every swipe fire twice.
`socktop-gestures` enforces this: it exits non-zero if one is already running,
unless given `--replace`.
## Stopping the screen blanking
A wall display must never blank. `./install.sh --noblank` applies two layers:
1. An Xorg `ServerFlags` snippet with all four timeouts at `0`, so it covers
every X session including the display-manager greeter, and survives reboots.
2. An `xset s off s noblank -dpms` line in the i3 autostart, because a session
or DM can re-enable the screensaver after X has started.
Both are needed. `xset` alone does not survive a reboot, and — the trap worth
knowing — **`xset` must run as the session user**. Running `sudo xset ...`, or a
`sudo bash noblank.sh` wrapper, targets root's X connection and silently does
nothing while appearing to succeed. Check the real state with:
```sh
xset q | grep -A1 -E 'Screen Saver|DPMS'
```
You want `timeout: 0`, `prefer blanking: no`, and `DPMS is Disabled`.
### Related: phantom outputs
Some boards report a display output that has no panel behind it. The LattePanda's
onboard DSI header shows up as `DSI-1 connected 1024x600` with **zero EDID bytes**
(`xrandr` prints `0mm x 0mm`), and X happily puts workspace 1 on it. Everything
then looks healthy from ssh -- i3 has the window fullscreen on its primary
output -- while the real panel shows an empty workspace. Check with:
```sh
xrandr | grep ' connected' # a real panel has physical mm, phantoms say 0mm x 0mm
for c in /sys/class/drm/card0-*; do echo "$c $(cat $c/status) edid=$(wc -c <$c/edid)"; done
```
Tell X to ignore the phantom and mark the real panel primary (adjust the names):
```sh
sudo tee /etc/X11/xorg.conf.d/20-outputs-socktop-swipe.conf >/dev/null <<'EOF'
Section "Monitor"
Identifier "DSI-1"
Option "Ignore" "true"
EndSection
Section "Monitor"
Identifier "HDMI-2"
Option "Primary" "true"
sudo tee /etc/X11/xorg.conf.d/99-ignore-touch-socktop-swipe.conf >/dev/null <<'EOF'
Section "InputClass"
Identifier "ignore touchscreen (socktop-swipe)"
MatchProduct "ILITEK"
MatchIsTouchscreen "on"
Option "Ignore" "on"
EndSection
EOF
```
Then set `SCREEN_W` / `SCREEN_H` in the config to the real panel's mode.
Adjust `MatchProduct` to your panel, and restart X.
### Related: does the display come back by itself?
### A pane shows `[... exited: status 1]`
Blanking is only half of unattended operation. If the display manager has no
autologin configured, a reboot leaves the panel at a login prompt and nothing
autostarts. Check with:
That monitor program stopped. The pane is deliberately kept so the layout does
not reshuffle and you can see what happened. Check the path under `binaries:`,
and that the program works when you run it by hand.
```sh
grep -E '^autologin-(user|session)' /etc/lightdm/lightdm.conf
```
### The dashboard is on a screen that isn't there
No output means no autologin. `./install.sh --autologin` writes
`/etc/lightdm/lightdm.conf.d/50-autologin-socktop-swipe.conf` for the current
user into the `i3` session. It is opt-in, not a default: **anyone with physical
access to the panel gets that user's session**, so only do it where the display
user is nothing but the dashboard. Delete the file to get the login prompt back.
Some boards report an output with no panel behind it, and X will happily put the
dashboard on it — everything looks fine over ssh while the real panel shows an
empty desktop. See [`notes/HARDWARE-NOTES.md`](notes/HARDWARE-NOTES.md).
## Uninstall
```sh
./uninstall.sh # scripts, config, X rule
./uninstall.sh # binary, config, udev rule, X snippets, autologin
./uninstall.sh --keep-config # keep your settings
```
lisgd, the `input` group and your socktop profiles are deliberately left alone;
the script prints how to remove each.
The Rust toolchain, tmux, the monitor programs and your `input` group membership
are left alone; the script prints how to remove each.
## Troubleshooting
## Notes
Four gotchas account for nearly every failure. All were found the hard way.
Design decisions and the reasoning behind them are in [`notes/`](notes):
### 1. Gestures are recognised but never fire
- [`DESIGN.md`](notes/DESIGN.md) — why tmux, why evdev, why the grid works this way
- [`HARDWARE-NOTES.md`](notes/HARDWARE-NOTES.md) — panel quirks, phantom outputs, the `sudo xset` trap
- [`V1-BASH.md`](notes/V1-BASH.md) — the shell implementation this replaced, and how to migrate
- [`TODO.md`](notes/TODO.md)
Run `tools/diag.sh` and read stage 2:
## Related
```
[swipe]: Cfg(f=1/s=3/e=0/d=0) <=> Evt(f=2/s=3/e=1/d=2)
^ configured ^ what happened
```
- [socktop](https://github.com/jasonwitty/socktop) — the host monitor this was built around
- [uptime-kuma-status](https://github.com/jasonwitty/uptime-kuma-status) — Uptime Kuma status pages in a terminal
- [unifly](https://github.com/jasonwitty/unifly) — UniFi network TUI
Matching `s=` with differing `f=` means **your panel reports more contacts than
you configured**. Many multipoint panels report 2 or even 3 contacts for a
physically one-finger swipe. Add them to `FINGER_COUNTS`.
## License
Direction enum: `0=DU`, `1=UD`, `2=LR`, `3=RL`.
### 2. Swipes register, but erratically — resizing panes, zooming text
X is also delivering touch to whatever is on screen, so a single swipe hits
several consumers at once: tmux mouse mode drags pane borders, the terminal
reads 2-contact swipes as pinch-zoom, and socktop enables its own all-motion
mouse reporting (`?1003h`). Meanwhile lisgd fires too.
Fix with `./install.sh --xignore` and relog. lisgd is unaffected because it
reads the device directly. Trade-off: no tap or pinch-zoom on that panel —
terminal keyboard zoom (`Ctrl +` / `Ctrl -`) still works.
Also ensure tmux mouse mode is **off**; `socktop-rack` sets this.
### 3. Every swipe jumps two panes
Two lisgd instances are running. `pgrep -x lisgd` should show exactly one.
`socktop-gestures` refuses to start if a daemon is already running, so this
should not happen via the normal path; `--replace` restarts cleanly. It can
still occur if lisgd was launched by hand.
### 4. Swipes do nothing at all
In order: is the session running (`tmux ls`)? Is the daemon running
(`pgrep -x lisgd`)? Does `tools/diag.sh` stage 1 read bytes? Are you in the
`input` group (`id -nG | grep input`, needs a relogin)?
Note lisgd's verbose flag is **`-v`**, not `-D`.
### Multi-monitor note
If the display host has a second monitor, X reports the **combined** root window
(e.g. 2304x720). lisgd would scale its maths to that, so `SCREEN_W`/`SCREEN_H`
must describe the touch panel alone. `socktop-gestures` always passes them
explicitly.
## Known limitations
- **~300 ms repaint on zoom-in.** Between tmux making the pane full-screen and
socktop repainting, you briefly see the old small rendering anchored top-left.
This is socktop's redraw latency, not the gesture path; nothing outside
socktop can fix it. Zooming out has no visible artifact, since panes return to
sizes they were already drawn at.
- Deliberately **no wrap-around** at the ends of the carousel — on a wall display
wrapping makes it impossible to tell where you are.
- X11 only. The lisgd build disables its Wayland backend (`WITHOUT_WAYLAND=1`).
## Tested on
LattePanda (Atom x5-Z8350, 1.9 GB RAM, Cherry Trail graphics), 1024x600 ILITEK
DSI touch panel, Debian 11, i3 on X11, Alacritty 0.16.1, lisgd from git,
monitoring four Raspberry Pis.
Apache-2.0.