Subj : src/doors/termgfx/sgrmouse.c sgrmouse.h src/doors/termgfx/test/test_mo To : Git commit to main/sbbs/master From : Rob Swindell (on Debian Linux) Date : Sun Aug 09 2026 07:19:11 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) --- SBBSecho 3.37-Linux * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705) .