https://bugs.kde.org/show_bug.cgi?id=383407
--- Comment #8 from Alvin Wong <alvinhoc...@gmail.com> --- (In reply to Wade from comment #6) Thanks for the info. I did a bit of testing with some of them and here are my findings: Drawpile 2.0.8 uses the WinTab support from Qt, which happens to contain an ugly hack which takes the system cursor location for handling mouse mode. That code for some reason wasn't backported to the WinTab code in Krita, but it could've been intentional. SAI 1.2.5 switches WinTab to pen mode by default. The option it provides for enabling mouse mode actually causes SAI to handle the relative movement of the tablet by itself. It also moves the system cursor by its own tracking, instead of letting the Wacom driver do it. This is why moving the mouse doesn't affect the strokes made by the tablet. It also doesn't follow the mouse mode settings in the Wacom settings, but instead provide its own speed settings. This also allows making use of the full tablet resolution to get sub-pixel position for painting. SpeedyPainter doesn't work in mouse mode for me at all. Anyway, I dislike the idea of using the mouse coordinates for painting, so I did have the idea to implement relative mode in the WinTab code, just like how SAI does it. I didn't really consider it then due to how it would have to move the system cursor around, but seeing that I had to do it anyway in the Windows Ink code, I'm feeling a bit more comfortable with going this direction. -- You are receiving this mail because: You are watching all bug changes.
