https://gitlab.synchro.net/main/sbbs/-/commit/f1ecc065541d98d00490a8ce
Modified Files:
src/doors/termgfx/term.c term.h
Log Message:
termgfx: correct the DECSDM ?80 rationale in the comments

The term.h/term.c comments claimed mode 80 "defaults to SET" and that ?80l "pins the sixel to top-left" -- both wrong. SyncTERM/cterm reversed mode 80 in rev 1.328 (2026) to match real VT-340 hardware (it defaults to RESET), and the load-bearing effect of ?80l for us is POSITIONING, not scroll-prevention: under ?80l a non-SyncTERM sixel terminal draws the image at the text cursor (so the door centers it), while SyncTERM's cterm ignores the cursor and anchors top-left. Scroll-prevention is handled separately by keeping the image off the last text row (the bottom-cell reserve). Comments only; no code change.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/66367891c957d731bc78f1b2
Modified Files:
src/doors/termgfx/term.c term.h
Log Message:
termgfx: quiet the terminal's own mouse pointer while a door runs

An arrow floating over a full-screen scene is what gives away that this
is a window rather than a game, and a door that draws its own cursor -- SyncSCUMM does -- ends up showing two.

Two sequences, because no terminal implements both and each ignores the other's. xterm gets XTSMPOINTER pointerMode 3, which hides the pointer
and keeps it hidden across the window border; mode 2 is the near miss,
unhiding whenever the pointer crosses it. The default is not enough on
its own: it is mode 1, "hide if the mouse tracking mode is not enabled",
and these doors enable tracking, so xterm deliberately keeps the pointer visible for exactly this case. foot gets OSC 22 with an xcursor name --
it cannot hide a pointer at all, an empty or unknown name only resets
the shape, so a crosshair is the closest it gets to not being an arrow.

SyncTERM implements neither. cterm has no XTSMPOINTER, and its OSC
handler knows only 4, 8, 10, 11 and 104 and discards the rest, so both
are safe to send blind.

Cosmetic, and only that: no terminal offers the pointer LOCK that would
let a door hide the pointer and still track the hand, so this changes
how the pointer looks and nothing about where it can go or what it
reports.

XTSMPOINTER has no query, so restore writes pointerMode 1 -- the
documented default -- and assumes the user had not chosen their own. A
caller should therefore restore only if it quieted.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/49bec00ed95e3b57a39e3b3e
Modified Files:
src/doors/termgfx/term.c term.h
Log Message:
termgfx: drop the OSC 22 pointer shape, keep only the hide

Setting the pointer SHAPE was the wrong half of this. xterm and foot both implement OSC 22, so the shape changed on both and neither hid anything:
a crosshair ended up floating over the game, which reads as a second game cursor and is worse than the arrow it replaced.

There is no name that hides instead. foot's documentation is explicit
that an empty or unknown name only resets the shape, and a visible
pointer of any shape is still a pointer sitting on the scene.

What remains is XTSMPOINTER, which is the only sequence that can hide
anything. Its own limit is now recorded beside it: xterm frames
pointerMode as deciding whether to hide the pointer AS THE USER TYPES, so
it is a hide-while-typing policy rather than an unconditional hide, and a
hand resting on the mouse can keep the pointer on screen regardless.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net