Side-edge Back on the board by injected pointer, 2026-10-16
Evidence class: injected events on HDMI (a uinput mouse through
/tmp/bp.py, i.e. tools/board-pointer.py) with grim captures and the
compositor’s own K230_CARD_SHELL side-back target=N log lines. This is not
real touch, so the “feels right from a real finger” judgement that task 1.3
asks for is still open.
- System:
/nix/store/m1c3jq413s8acils9y6jrpdk02xq5lmz-nixos-system-nixos-26.11.20260919.20b1ddd, live-deployed frominteg-1016atf082393a, which includes this change’sec1bf497. It landed rebased as3a912936. - Output: HDMI-A-1 at 1280x720.
The mouse button path enters the same input_down recognizer as touch
(card_shell_pointer_button → input_down(CARD_POINTER_ID, …)).
| Case | Injected swipe (px) | Log | Result |
|---|---|---|---|
| Shade open, left edge, inward | (10,360)→(160,364), 300 ms | side-back target=2 | Shade closed (1-shade-open…, 2-after-left-side-back…) |
| Shade open, right edge, inward | (1275,520)→(1120,522) | side-back target=2 | Shade closed |
| Plain Home, left edge, inward | (10,300)→(160,305) | none | Home unchanged |
| Shade open, 30 px inward | (10,520)→(40,520) | none | Shade stays open |
| Shade open, right edge, outward | (1240,520)→(1279,520) | none | Shade stays open |
| Shade open, top-left corner, inward | (10,10)→(160,14) | none | Shade stays open (top band belongs to the Shade) |
| Fullscreen terminal (no shell context) | (10,300)→(160,305) | none | Terminal unchanged; no stray keystroke at the prompt |
Not covered: keyboard target
With wvkbd shown, the injected mouse swipe was not claimed. The touch reached
the Shade under it: a left-edge swipe at y=300 dragged the Shade’s volume
slider to zero, and it was dragged back to its earlier position afterwards
(3-keyboard-shown-swipe-not-claimed…). The same happens to the existing
top-edge Shade pull from Home while the keyboard is shown. So this predates
side Back: with the keyboard visible, input_down returns before the
touch-first edge block for the pointer path. The cause was not isolated; the
two failures were tracked to input_down returning false, and wvkbd maps two
layer surfaces, not an xdg popup.
The keyboard step of the dismiss order (target=3) therefore has host-fixture
proof only. It needs a real touch on the panel, or a pointer-path fix, before
task 1.3 can close.
Keyboard target after the popup fix (2026-10-16, panel)
Evidence class: injected events on the panel (DSI-1, 1232x568
landscape, HDMI unplugged): a uinput mouse through /tmp/bp.py
(tools/board-pointer.py), grim captures, and the compositor’s
K230_CARD_SHELL side-back target=N lines. This is not real touch.
The cause of the failure above was wvkbd 0.20’s key-preview xdg_popup.
wvkbd keeps it mapped while the keyboard is shown, so the card shell
treated it as an open menu and skipped every touch-first edge. Commit
b3c44dd0 (rebased from 630fa3f2) ignores a popup that lies inside the
keyboard’s own rectangle extended upward by its height.
- System:
/nix/store/6mmvyyasczi0xsgw9hx2bhx6vrlycr07-nixos-system-nixos-26.11.20260919.20b1ddd. It was built from integration branchinteg-cma-popupat84b8b993, which contains this fix, the 64 MiB CMA change and the vision redesign. It was installed and soft-rebooted at 15:41. - The keyboard was shown with
SIGUSR2to the supervised wvkbd.
| Step | Injected swipe (px) | Log | Result | Capture |
|---|---|---|---|---|
| Keyboard shown on Home | — | — | Keyboard up | 4-panel-keyboard-shown-1232x568.png |
| Top-edge pull | (400,2)→(400,300), 400 ms | — | Shade opened over the keyboard | 5-panel-keyboard-top-pull-opens-shade-1232x568.png |
| Left edge, inward | (3,200)→(160,204), 300 ms | side-back target=2 | Shade closed, keyboard still shown | 6-panel-side-back-closes-shade-keyboard-stays-1232x568.png |
| Left edge, inward again | (3,200)→(160,204), 300 ms | side-back target=3 | Keyboard dismissed | 7-panel-side-back-dismisses-keyboard-1232x568.png |
| Settings opened (Shade, then “Settings”) | (400,2)→(400,300); tap (402,40) | — | Settings (at the board’s saved vision step) | 8-panel-settings-1232x568.png |
| Left edge, inward | (3,300)→(160,304), 300 ms | side-back target=2 | Settings closed to Home | 9-panel-settings-side-back-1232x568.png |
So the dismiss order (sheet, then keyboard) holds on the board for the pointer path. Injected pointer swipes from the bottom edge and the dock did not open the drawer, so the drawer case is not covered here. Real-finger feel stays open.
Long-press menu before the drawer (2026-10-16 23:18Z)
Source: branch side-back-sheet. The adapter’s overlay step now sends
back; the Rust client closes an open long-press app menu and otherwise
hides like hide. The board ran
/nix/store/5vj9z6z0ims1svg437qncsv7y2p5hw2z-nixos-system-…, built from
integration commit e71dabce. That is this change plus the clock restyle
commit, with no other source. It was deployed live with
switch-to-configuration test.
Method: on the landscape panel, a uinput mouse through /tmp/bp.py
(tools/board-pointer.py), with native grim captures. The drawer was opened
with the shell socket’s drawer route.
Evidence class: injected pointer input. There was no finger on the glass.
| Step | Injected input (px) | Log | Result | Capture |
|---|---|---|---|---|
| Drawer open | socket drawer | — | Drawer | 10-panel-drawer-open-1232x568.png |
| Long-press “Clock” | hold 616 190 900; up | app-menu-open, app-menu-ready rows=3 | App menu (Open, New Window, Add to Home) | 11-panel-long-press-menu-1232x568.png |
| Left edge, inward | (3,300)→(160,304), 300 ms | side-back target=2, then app-menu-dismiss | Menu closed; the drawer is still open | 12-panel-side-back-closes-menu-drawer-stays-1232x568.png |
| Left edge, inward again | (3,300)→(160,304), 300 ms | side-back target=2 | Drawer closed to Home | 13-panel-side-back-closes-drawer-1232x568.png |
While the menu is open the drawer is not drawn behind it (capture 11). That is the existing menu presentation and was not changed here.
The compositor still reports target=2 (overlay) for the menu, because the
menu is on the same k230-shell-drawer layer. The Rust client makes the
menu-first decision. sheet_open() in the adapter stays false by design (see
its comment).