The lag is felt in the browser and every number so far was measured somewhere
else. At x11vnc's own socket, press-to-paint is ~50ms: median 47ms over 8
synthetic presses, and 51ms with a second x11vnc running with X DAMAGE enabled
— so -noxdamage costs nothing and the comment defending it stands.
What that cannot include is the sidecar relay, the platform's socket relay and
the network, which is where the rest of the lag has to be. This prints the
end-to-end figure in the status row so the two can be subtracted.
Instrumentation, not a feature. Delete it and its row once the question is
settled.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: f7a62308-0977-4cf4-aa29-c020853fd420
text-xs muted at the bottom of the panel was where none of it got read.
Everything in that row is either a state you need before you touch the game
(connected, click the board to send it keys) or a repair for when it stops
behaving — a footer is the wrong place for both.
Now above the board, text-sm, text-primary, with the icons up to size-4 and
hover:underline instead of a colour change that is no longer available at
primary. `shrink-0` so it keeps its height and the canvas gives way, which is
the same reason the board's row has `min-h-0`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: de3ed4e6-f88a-429c-94e6-a760336ba83b
`POST /reset-input` and a "clicks acting wrong?" button in the panel's status
line. It releases every modifier and mouse button the display thinks is held.
Named for the SYMPTOM rather than the mechanism, because nobody experiencing
this knows a modifier is stuck — they know their clicks stopped doing the right
thing.
── both sides, and that ordering matters ──
Releasing on the server alone leaves the panel's own button mask stale and the
next mouse move re-asserts it, so the fix would appear not to work. Local state
is cleared first, a pointer event with an empty mask says so, and only then does
the server let go.
── a fixed list, not a query ──
`xinput --query-state` would report exactly what is held, which is better. It is
also a seventh host binary to declare and to require, for a repair. Releasing a
key that was not pressed is a no-op, so the fixed list costs nothing. Modifiers
and buttons only: a stuck letter types, which is obvious and harmless; a stuck
modifier silently changes what every click means.
── not guarded like the others ──
Every other command refuses while a dialog is open, because its clicks would
fall through onto the board. This one clicks nothing, and refusing a repair in
the state that most needs it would be the wrong way round.
Verified by stranding `Shift_L` on the display with `xdotool keydown`, hitting
the route, and watching `xinput --query-state` go from one key down to none.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: de3ed4e6-f88a-429c-94e6-a760336ba83b
Reported as "no way to send a left click". `xinput --query-state` on the
display showed `Shift_L` down on the XTEST device with nothing holding it, so
every click reached the game as shift-click, which Minesweeper reads as a right
click. The board flagged instead of opening and nothing about the panel looked
wrong.
Mine, from the keyboard work two commits ago, and two separate mistakes.
── modifiers should never have been sent ──
Press shift, release it while the canvas no longer has focus, and the keyup
never arrives — the key is then down on the server forever. They are also
POINTLESS: `ev.key` is the character the layout already produced, so a shifted
key arrives as `A` and x11vnc presses shift itself to type it. Sending our own
on top was redundant on the good path and load-bearing on the bad one.
`keysymFor` now returns null for them, which also hands them back to the
browser — shift-tab should still move focus out of a game of Minesweeper.
── and nothing released what was held ──
Any key can strand the same way, so the panel now tracks what it has pressed
and releases it on blur and on unmount. Cheap, and the failure it prevents is
invisible from the panel: the server has no way to know a key was released
somewhere it could not see.
The live display is unstuck too — `xdotool keyup` on the modifiers, since the
fix stops it happening again but does not undo the one already stranded.
The general lesson, which is the same one the difficulty command taught: input
synthesised into another program's session is state you now own. Press without
a guaranteed release is a leak, and it does not look like one.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: de3ed4e6-f88a-429c-94e6-a760336ba83b
"Your screen cannot fit a window of that size" on Extras > Play Recording.
The replay window is 504x342 — exactly expert, which the 512x352 stage holds
with ten pixels to spare — so the message is not about the window it is about
to draw.
Not a positional check either, which was the first guess: from a centred
beginner window an expert window would run 236px off the right edge, and the
game repositions it without complaint. It is a minimum-screen check wanting
slack it never spends, roughly the title bar it does not have here.
Measured rather than reasoned about, on a stage enlarged for the purpose: the
replay window is 504x342, the file dialog 420x239. Then 512x352 verified
refusing a replay and 512x384 verified opening one.
The height is the whole fix; the width is unchanged. That matters because 42
more pixels of stage cost nothing at the sizes people use: the panel caps the
scale at 2x, so any stage up to about 726x451 draws the game at exactly the
same size. The stage only starts costing pixels once the fit falls under the
cap — which is also why the number is generous rather than the minimum that
passes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: de3ed4e6-f88a-429c-94e6-a760336ba83b
The 2x cap flattened the panel's zoom control into doing nothing, and the
reason is worth writing down: `fit` is the SAME NUMBER at every zoom level.
CSS `zoom` takes off `offsetWidth` exactly what it adds to the pixel ratio, so
the fit is zoom-invariant by construction — and capping it therefore caps every
zoom level to the same size.
So the cap applies to the baseline, the size at 100%, and zoom multiplies what
comes out. 100% stays exactly where it is; zooming in goes past 2x again.
Quarter steps now go all the way down rather than whole numbers under 2x. With
whole numbers, zooming out from a 2x baseline fell straight to 1x and halved
the board in one press. Cells stay whole at every quarter — 20px at 1.25x —
which was always the property that mattered, not the size of the step.
The resulting ladder over the panel's 70-160% range: 1.25, 1.5, 1.75, 2.0,
2.0, 2.25, 2.5, 2.75, 3.0, 3.0. Eight of the ten presses move it; two land on
the same quarter, which is the price of keeping the grid even.
Also `overflow-hidden` on the box, so zooming past what the panel holds clips
rather than shoving the status line out of the way.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: de3ed4e6-f88a-429c-94e6-a760336ba83b
The quarter steps did not actually shrink it. In a panel around 1500x950
device pixels the fit is 2.56, and floor(2.56 x 4) / 4 is still 2.5 — the finer
steps changed where the next size would land, not this one.
So a ceiling instead of another nudge: 2x, whatever room the panel has. That is
a taste decision rather than a limit of the method — past 2x this stops reading
as a window on a desktop — and the panel header has a zoom control, so it is a
default, not a verdict. Raise MAX_SCALE and the quarter steps take over again.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: de3ed4e6-f88a-429c-94e6-a760336ba83b
── keys ──
`rfb.ts` already had a `key()` that nothing called. It now has `keysymFor`,
mapping `KeyboardEvent.key` to an X11 keysym — `key` rather than `code`,
because it is already the character the user's own layout produced and `code`
would need that layout re-implemented here to get back to a symbol. Latin-1
passes straight through, above it uses X's 0x01000000 Unicode offset, and the
named keys come from keysymdef.h.
The canvas is focusable and takes focus on mousedown. Scoping keys to focus is
what stops the panel eating keys meant for the rest of the app — this is one
panel on a dashboard, so a window listener would be a global keyboard trap.
Modified keys and unmapped keys are left alone: cmd-W stays the browser's and
Tab keeps moving focus. preventDefault only for keys actually sent.
Keys reach wine without a window manager — verified by pressing F2 on the
display and watching the board reset. So the README's guess that wine needed a
WM to hand it focus was wrong; Auto Options ignores Escape because that VB6
form has no Cancel button, which is a different thing. Corrected there.
20 keysym cases checked against keysymdef.h, including the off-by-one I put in
my own test first: XK_F2 is 0xffbf, not 0xffc0.
── size ──
Half steps overshot: 2x to 2.5x is too small to too large with nothing in
between. Quarter steps from 2x up, which keeps cells whole for the same reason
halves did — a 16px grid at 2.25x is a 36px cell — and lets the picture track
the panel instead of lurching. Plus a 24px device-pixel margin, because
filling the panel edge to edge is most of what "too large" looks like.
Also: the scale was ignoring the panel's own CSS `zoom`. `devicePixelRatio`
knows nothing about it, so at 75% every cell boundary went back onto fractional
device pixels — the exact defect the snapping exists to prevent, reachable from
a button in the panel header. Effective ratio is now dpr x zoom, read as
getBoundingClientRect().width / offsetWidth.
In a 1300x900 device-pixel panel: 2.5x becomes 2.25x, 1260 to 1134 px wide.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: de3ed4e6-f88a-429c-94e6-a760336ba83b
Trimming the stage alone does nothing, and that is worth writing down: the
scale is snapped, so at 3x the game is 1512 device pixels wide whether the
stage is 560 or 512. Shrinking the surround only pays when it crosses a step.
So both halves land together.
── the stage ──
560x400 down to 512x352, which is expert (504x342, measured) plus four pixels
a side. There is nothing left to give — intermediate is 342 tall too, so
anything shorter clips a board people actually play.
── half steps from 2x ──
Not a retreat from whole-number scaling. The unit that has to stay regular is
the CELL, not the pixel: this is a 16px grid, so at 3.5x a cell is exactly 56
screen pixels — as even as 3x or 4x — and only sub-cell pixels alternate
between three and four. Below 2x that alternation is a third of a pixel rather
than a seventh, so whole numbers still apply there. The case that started all
this, a fractional devicePixelRatio at nominal 1:1, put the CELL boundaries at
26.4px, which is a different thing entirely.
Together, on a 1800x1400 device-pixel panel: 3.0x becomes 3.5x, and the game
goes from 1512 to 1764 device pixels wide.
Known cost, and it is in the README: the Extras > Auto Options dialog is 328
wide and opens 25px right of the game, so it needs a 554-wide stage to fit
whole from beginner. It cannot be closed from the panel anyway — no window
manager, no title bar, no OK button — so that is the thing to fix before this
number is revisited.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: de3ed4e6-f88a-429c-94e6-a760336ba83b
Two halves of the same problem: the picture was sharp everywhere and wrong
overall.
── whole-number scaling ──
The canvas is now sized to the largest WHOLE number of device pixels per
source pixel that fits the panel, measured with a ResizeObserver and the
device pixel ratio. Below 1x it takes a unit fraction instead, so the rows
that survive are evenly spaced rather than dropped in clumps.
This is a 16px-per-cell bitmap from 1995. At a fractional scale one cell gets
three screen pixels and its neighbour gets two, the grid goes uneven and the
digits wobble — which reads as "not quite right" rather than as blur, and
`image-rendering: pixelated` does not help because unevenness is not blur.
A fractional devicePixelRatio produces exactly this at what looks like 1:1.
It is also allowed to scale UP past the framebuffer's own size, which was the
other half of it: `max-w-full` only ever shrinks, so on a wide panel the
canvas sat at its intrinsic size using a fraction of the pixels available.
── a smaller stage ──
800x600 down to 560x400. The stage is what gets scaled to fill the panel, so
every pixel of empty surround is panel the game does not get, and the whole-
number steps are far apart: in an 1866-device-pixel panel, 800 wide lands on
2x and 560 wide lands on 3x. Same panel, half again as much game.
560x400 is expert (504x342, measured on this machine) plus a margin. A custom
board bigger than the stage is now clipped at the right and bottom rather than
shrunk; `centre` clamps at zero so the menu bar stays reachable. Widen the two
constants if that turns out to be the wrong trade.
Verified: beginner centres at 204,93 on the new stage, which is exact.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: de3ed4e6-f88a-429c-94e6-a760336ba83b
── the stage ──
The framebuffer is now the picture. 800x600 whatever the difficulty, the game
centred in it by the sidecar, and the panel draws it entire — scaled to fit,
centred by its flex parent, never cropped. Changing difficulty moves the board
instead of resizing the panel.
What this replaces parked the window at the origin and had the client crop to
the window's size, polled every four seconds. Two things wrong with it. The
panel resized under the player mid-game; and wine puts the window at 3,29
rather than 0,0, so cropping from the origin showed a black strip on top and
cut a row of cells off the bottom — the "expert gets cut off" report.
Centring runs on a one-second timer because nothing announces a resize: not
RFB, which keeps the framebuffer, and not X without a window manager to listen
through. One chained `xdotool search … getwindowgeometry` per tick, one
process, and a `windowmove` only when the numbers actually changed.
The client loses the geometry poll, the offscreen canvas and the crop with it.
── the port ──
x11vnc was listening on 0.0.0.0:5900 and [::]:5900 with -nopw. Every account
on this machine, every device on the tailnet and everything on the LAN could
open it and take the display — which is precisely the hole the 5907 version
was replaced to close, reopened wider and documented as impossible.
`-unixsock` ADDS a unix socket. It does not remove the TCP one. Three flags do:
-rfbport 0 for IPv4, -rfbportv6 0 for IPv6, -noipv6 for outgoing. `-rfbport 0`
alone leaves [::]:5900 up, which is how this nearly shipped half-fixed.
Found with `ss -lntp` on the running process, and that is the only check that
was right about it at any point. Running the same argv by hand showed no IPv6
listener — most likely because the PM2 session still held [::]:5900 and the
hand-run copy failed to bind it silently. Comments in session.ts and index.ts
that asserted there was no port are corrected rather than deleted.
Verified on the live socket: the streamed framebuffer is 447k teal pixels
around a 152x214 window at 324,193 — dead centre — and window grey arrives as
c0 c0 c0, no TCP listener for the x11vnc pid.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: de3ed4e6-f88a-429c-94e6-a760336ba83b
Minesweeper X under wine on a headless display, as a plugin. It was
/api/minesweeper, a Dashboard screen, an officerdev panel, a permission
registry entry and a hand-written websocket provider in server.tsx.
The socket is why it had to live in the platform: Bun's route table is fixed
at serve(), so nothing installed later could add one. That ceiling is gone,
and this is the first plugin through the per-plugin relay.
Three things changed rather than moved:
The sidecar owns the session. The platform used to spawn bin/session.sh
detached, so the game outlived every restart, nothing supervised it, and a
crashed run left wine processes holding the prefix — the next start hung
rather than failed. PM2 supervises a sidecar, and stop() uses 'wineserver -k'
scoped by WINEPREFIX instead of 'pkill -f wineserver', which would have killed
every other wine prefix on the machine.
x11vnc moved from 127.0.0.1:5907 to a unix socket in a mode-0700 directory.
-nopw was only ever safe because of the machine, not the platform: any local
account could open that port and take the display. A fixed port is squattable
too. There is now no listener to authenticate against.
The wine prefix is confined to C:. This is the one that mattered. The platform
classified Minesweeper as kind:'execution' — never grantable — because a fresh
prefix maps the whole filesystem to Z: and symlinks the profile into the
owner's real home, and the game has Open and Save dialogs. A plugin permission
has no kind and is always grantable, so extracting it without this would have
converted a sealed capability into a file picker running as the owner.
Re-asserted on every start, because wine restores z: whenever it updates a
prefix.
Not solved: one display and one game, so two grantees share a board.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043
pastilhasandClaude Opus 5