https://bugs.winehq.org/show_bug.cgi?id=38204
--- Comment #4 from kotomixkyou@gmail.com --- After further analysis, it seems that a specific value (0X11U in hexadecimal or 17 in decimal) is always missing or not read by the ReadFileEx function. For instance when querying the XY coordinates set by the device, reading byte by byte (ReadFileEx with a nNumberOfBytesToRead of 1) recursively always fails when it would get to a value of 0x11U or 17.
e.g. terminal output when steadily increasing the coordinates and reading from the device
Normally each packet consists of 11 bytes:
syn sequence datalength checksum 55 4a 5 c7
data(ID (3 bytes) x y) 8b 0 0 f a
checksum high / low 15 c1 Sample output:
55 4a 5 c7 8b 0 0 f a 15 c1 XY Input: (15, 10) 55 52 5 67 8b 0 0 f a 15 c1 XY Input: (15, 10) 55 5a 5 e2 8b 0 0 e a ba 82 XY Input: (14, 10) 55 62 5 8 8b 0 0 f a 15 c1 XY Input: (15, 10) 55 6a 5 8d 8b 0 0 e a ba 82 XY Input: (14, 10) 55 72 5 2d 8b 0 0 f a 15 c1 XY Input: (15, 10) 55 7a 5 a8 8b 0 0 10 a 51 e8 XY Input: (16, 10) 55 82 5 d1 8b 0 0 b 6e 72 55 82 5 d1 8b 0 0 b 6e 72 55 82 5 d1 8b 0 0 b 6e 72 55 82 5 d1 8b 0 0 b 6e 72 55 82 5 d1 8b 0 0 b 6e 72
The final line has the 10 byte message 55 82 5 d1 8b 0 0 b 6e 72 repeated 5 times (number of times the program will check for a message before throwing error)
This is evident elsewhere in the code as well where a fixed 0x11U or 17 value fails to be read as a part of the start up sequence of the program.
Any idea what could be causing this? The only possible connection I can find is that in the ASCII table 0x17U or 23 stands for End transmission blocks. Perhaps this is in connection with all the aforementioned problems experienced.