Change Details

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: == **Update** Spent a little while trying to do a basic port, I ran into an unexpected situation: it seems like Qt creates an invisible phantom window to receive tablet events. I do not understand the implications of this, but it sounds pretty annoying. I'm wondering if the right way to go is to perhaps create a sort of patch on top of Qt. The window can be disabled with the configuration -no-feature-tabletevent, but that builds Qt without QTabletEvent support entirely. If we're going to be needing a custom build flag for Qt, it's probably just as well we write a whole custom patch. 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 "upgraded" to handling 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. (//Side note/rant: xcb-xinput is flagged upstream as unstable, buggy API. Unfortunately we have no choice but to live with it.//) Compared to Windows, this is far messier and more difficult. However, there are some very severe tablet handling issues that we probably have no ability to fix without doing this 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 are basically unchanged. So even though xcb-xinput is undocumented, (buggy, unstable) API, most of the time all you have to do is look up the corresponding Xlib call to figure out what the arguments are doing. 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. There is one interesting consideration: 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.

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: == **Update** Spent a little while trying to do a basic port, I ran into an unexpected situation: it seems like Qt creates an invisible phantom window to receive tablet events. I do not understand the implications of this, so it put me off. (See QWindowsTabletSupport::create()) I do not understand the implications of this, maybe it can be circumvented by creating a second tablet event window, or some other wintab calls. The window itself can be disabled with the configuration -no-feature-tabletevent, but that builds Qt without QTabletEvent support entirely. 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 "upgraded" to handling 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. (//Side note/rant: xcb-xinput is flagged upstream as unstable, buggy API. Unfortunately we have no choice but to live with it.//) Compared to Windows, this is far messier and more difficult. However, there are some very severe tablet handling issues that we probably have no ability to fix without doing this 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 are basically unchanged. So even though xcb-xinput is undocumented, (buggy, unstable) API, most of the time all you have to do is look up the corresponding Xlib call to figure out what the arguments are doing. 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. There is one interesting consideration: 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.

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: == **Update** Spent a little while trying to do a basic port, I ran into an unexpected situation: it seems like Qt creates an invisible phantom window to receive tablet events. I do not understand the implications of this, but it sounds pretty annoying. I'm wondering if the right way to go is to perhaps create a sort of patch on top of Qt. The window can be disabled with the configuration -no-feature-tableteventso it put me off. (See QWindowsTabletSupport::create()) I do not understand the implications of this, maybe it can be circumvented by creating a second tablet event window, but that builds Qt without QTabletEvent support entirelyor some other wintab calls. If we're going toThe window itself can be needing a custom build flag for Qtdisabled with the configuration -no-feature-tabletevent, it's probably just as well we write a whole custom patchbut that builds Qt without QTabletEvent support entirely. 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 "upgraded" to handling 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. (//Side note/rant: xcb-xinput is flagged upstream as unstable, buggy API. Unfortunately we have no choice but to live with it.//) Compared to Windows, this is far messier and more difficult. However, there are some very severe tablet handling issues that we probably have no ability to fix without doing this 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 are basically unchanged. So even though xcb-xinput is undocumented, (buggy, unstable) API, most of the time all you have to do is look up the corresponding Xlib call to figure out what the arguments are doing. 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. There is one interesting consideration: 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.