Thank you for sending me to that project. Their code was invaluable in helping me spot the problem with my SGR driver.
The language in the "xterm control sequences" doc for SGR is unclear. According to the Definitions section, C denotes "A single (required) character". Therefore, when I was trying to construct my encoded string, I was using %c in the sprintf() function as per this wording:
The normal mouse response is altered to use CSI < followed by
semicolon-separated encoded button value, the Cx and Cy ordi-
nates and a final character which is M for button press and m
for button release.
o The encoded button value in this case does not add 32
since that was useful only in the X10 scheme for ensuring
that the byte containing the button value is a printable
The logic follows that, according to the Definition, Cx and Cy should be a character. In reality, it is a sequence of integer values.... that is %d in the sprintf() world.
Just as you mention that:
"The normal mouse response is altered to use CSI <"
I would think that it should say something more fully like this.
The normal mouse response is altered to use CSI < and Cx and Cy are altered to use Ps ; Ps" (or something like that).