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