https://gitlab.synchro.net/main/sbbs/-/commit/1da9027368ba657e2ffa9a7a
Modified Files:
src/doors/termgfx/sgrmouse.c sgrmouse.h src/doors/termgfx/test/test_mouse.c
Log Message:
termgfx: a wheel notch with the motion bit is still a wheel notch

SyncTERM sets the motion bit on a wheel report whenever the pointer
moved in the same event, so a click made without a perfectly still hand
arrives as 96 or 97 rather than 64 or 65. Testing motion before the
wheel bit then classified those as hovers and discarded them, which is
why the wheel in a termgfx door works only if the mouse is held
absolutely still.

Measured over four traced sessions on 1.9rc4 and 1.10a: the worst had
75 of these against 30 clean wheel reports, so most of a scroll was
being thrown away. It is not a version regression -- both send them,
and how often depends only on how much the hand moves.

ONLY 97 IS RECOVERABLE, and the asymmetry is the terminal's. Its
no-button hover is 96 exactly: mouse_state() forces the no-button case
to button 3, the wheel remap turns that into 64, and the motion bit
makes 96. So 96 means either wheel-up-with-motion or a plain hover and
nothing can distinguish them. 97 has the low bit set, which a hover
never does.

96 therefore stays a MOVE. Half the notches come back; the other half
are a collision in the terminal's own encoding and belong in a bug
report rather than a heuristic.

Affects SyncDOOM, SyncDuke, SyncRetro and Synchroland alike -- the classification is shared, and so was the fault.

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/c9737b87032bbed1c4e4d2c6
Modified Files:
src/doors/termgfx/sgrmouse.c src/doors/termgfx/test/test_mouse.c
Log Message:
termgfx: the motion bit is authoritative -- 97 is a moving pointer

A wheel notch carrying the motion bit was rescued as wheel-down, on the reasoning that a hover never sets the low bit and on a session measured at
75 such reports against 30 clean ones. A later capture inverts that ratio completely: 1492 clean 64/65 detents against 16 of 97, several of the 97s arriving 6 to 8 ms apart with the coordinates walking one cell at a time.
No hand turns a wheel that fast; that is a pointer being moved.

What the rescue actually bought was a phantom scroll on every pointer
movement. A door's block selection changed whenever the mouse moved, and behaved correctly only while the hand was held perfectly still -- which is exactly how it was reported, and was read as a terminal bug for several
rounds.

This corrects 1da9027368 (fire-20-buys, 2026-08-09), which added
the rescue. Real detents arrive as 64 and 65 without the motion bit, in
their thousands, so trusting the bit loses nothing. The test now pins both directions: 96 and 97 are motion, 64 and 65 are notches. It fails against
the rescued decode.

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/d16b8d40c42f3d63d02f4d53
Modified Files:
src/doors/termgfx/sgrmouse.h
Log Message:
termgfx: note that SyncTERM's mouse motion encoding was fixed

The 96-and-97 hover encoding this decoder works around is no longer what
a current SyncTERM sends. bbf7c4c79b (dice-12-carpet, 2026-07-11) stopped routing the no-button sentinel through the wheel remap, so unpressed
motion now arrives as xterm's 35 and a wheel notch as a clean 64 or 65.

Captured live from CTerm 1.332 to confirm it rather than trusting the
diff: twelve motion reports at b=35, wheel notches at b=64 and b=65, no
96 or 97 anywhere.

No code change. A door serves whatever client dials in, including
releases built before that fix, so both values must keep decoding exactly
as they did; what changes is that the comment described the broken
behavior in the present tense.

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/5ed64d120647284ab1b1dc40
Modified Files:
src/doors/termgfx/sgrmouse.h
Log Message:
termgfx: name the second SyncTERM fix that finished off the 96 encoding

The note added a moment ago credited the whole thing to bbf7c4c79b (dice-12-carpet, 2026-07-11), which is only half of it. That commit fixed motion with NO button held. A wheel notch left its button latched in the
button state -- a wheel "button" is momentary and no release ever follows
-- so motion after a scroll was not the no-button case and still came
through the remap as 96, reading as a drag rather than a hover.

a34c0f4e62 (exchange-33-sign, 2026-08-09) clears it, which is what
finished the job. Recorded because the two fixes are four weeks apart and
a reader who finds only the first will conclude, wrongly, that anything
still reporting 96 must be a build older than July.

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

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