> The issue that input drivers devices need high refresh frequency to be > able to achieve high-precision freehand drawing is quite well known¹.
Yes. But the bug here isn't about that. I think I'll have to elaborate a little. When you move the mouse, it will report its motion in an event with a two-component vector. Naturally both components must always be present, otherwise information is lost. When wsmouse(4) gets such an event, it will break that event into two separate events, one for the X delta and another for Y. This is because the current event structure cannot contain the deltas for both axes. Now ws(4) takes these two events and naturally considers them independent (as there is no metadata to couple them together), and fills in the blanks by setting one or the other delta to zero. The result is two orthogonal vectors which represent a motion your mouse never reported. Their sum is the original vector, but the motion they describe is still wrong. So the problem here is not refresh frequency, precision or anything like that. It's just that our data gets effectively mangled and corrupted between the two layers. My diff attempts to reconstruct the original vector by summing consecutive delta events, but as you noted below, this can also result in data loss. The lossless method would involve extending the ws event structure or adding some metadata (in the form of new events), or perhaps stuffing both deltas into the value field we have now (this is lossless only if they fit in 16 bits).. Interpolation is something I definitely wouldn't apply here :-) > I re-did a few experiments with and without your patch on my laptop > (with the Lenovo track point wihch is a relative device). I could not > reproduce the waves you're getting in Gimp, but without your patch > diagonals show indeed larger staircases effects. Under xfig(1) or > bitmap(1) the difference is much less noticeable. Clearly the > strategy used by applications to trac mouse motion for freehand > drawing are not the same. > > I do fear that with some devices your patch will collapse too many > events and make it harder to follow small radius curves. Right, I did not consider this case. If this is a problem, perhaps the code could be changed to only collapse a pair of DELTA_X and DELTA_Y events, but never more than that. This way it might still incorrectly merge two independent motions along the axes into one diagonal motion, but I would expect that to be rare, and the deltas to be so small that it has very little impact on anything.
