Xinput2 bug report: https://bugs.freedesktop.org/show_bug.cgi?id=92186
Qt bug report: https://bugreports.qt.io/browse/QTBUG-48151
Patch fixing jitter: https://codereview.qt-project.org/#/c/110334/
-----
Workaround library (built/tested on Kubuntu 15.10)
https://dl.dropboxusercontent.com/u/16058153/Krita/libqxcb.so
```
cd /usr/lib/x86_64-linux-gnu/qt5/plugins/platforms
sudo mv libqxcb.so libqxcb.so.old
sudo cp ~/Downloads/libqxcb.so .
```
--------
Prospect for a return to handling our own tablet events.
** Windows:
Windows tablet support has its own API and is contained in qwindowstabletsupport.cpp, a file of about 500 lines, and which seems very similar to the Qt4 version code.
The main benefit here is to include our own support of badly behaved tablets, such as the Surface Pro 3. My opinion is that the best option would be to Option B for this is to simply throw a patch on top of Qt and distribute the patched .dll with Krita. There is no restriction to doing this. It also becomes possible to distribute upstream. The drawback is that Krita Windows developers would have to apply this patch themselves, or wait for our changes to be merged upstream.
The other option is to merge their new code with our previous Windows handling code, which is still included in the repo, just disabled. Maybe ecloud could weigh in on how much he cares about upstreaming any tablet fixes we make. If he would shepherd patches for us, that would make it less of a burden.
** Linux:
Qt has "moved forward" and now handles X calls exclusively through XCB. This means the existing customized code would have to be rewritten for XCB. The epicenter, where everything we know and love has been destroyed, is that QAbstractNativeEventFilter() now sends xcb events, not xlib.
Compared to Windows, this looks like a huge mess. However, as we know, there are some very severe tablet handling issues that we probably have to fix on our own.
Now, on the one hand, it is quite possible to rewrite the old tablet handler code as xcb code. This is because, a vast majority of the time, an X call can be written equivalently as two xcb calls, like "xcb_request_info + xcb_wait_for_response." Most of the time, the arguments hardly even change.
The bigger problem is that the Qt internal API has changed. There is a huge delta between what Qt is actually doing, and the old code. The format of QTabletEvent has changed. (Now, that's not necessarily an argument against porting our old code. The new QTabletEvent now looks a lot like the old KisTabletEvent, which means porting the old code would be a little easier.)
The other option is to extract the new Qt XCB code and modify it. We can then forward-port the individual fixes contained in the Xlib version, if they are still necessary. It may be possible to extract this tablet handling code, then register our *own* handler, which steals all tablet XCB events from the Qt processing loop.
The main difficulty in porting is that tablet events are mixed in with *all* xcb events. The primary location where events are handled is qtcore/plugins/platforms/xcb/qxcbconnection_xi2.cpp, and the function xi2HandleTabletEvent. See in particular around 989, which points out where proximity events could be handled, but currently aren't.
My guess is that the is to go with the latter, that is, to disregard the old handler code and start from scratch by copying the current Qt handler code and then modifying it. However neither way sounds fun.
Regarding trying to restore KisTabletEvent: I don't think it brings any benefits. As far as I understood, the main justification for KisTabletEvent was to carry extended button masks, which QTablet now supports.
Currently the main limitation of QTabletEvent is that there is no way to reliably signal a hover event. I am not sure whether hover events themselves get sent reliably. If they are, perhaps we can just fall back on the old ProximityNotifier, and not worry about altering the event loop more than necessary. However, even if we want events themselves to carry hover information we don't necessarily require a new class: my first inclination is to try registering a new event type QEvent::TabletHover, and simply create QTabletEvents with type = TabletHover.