SUMMARY Hi guys, just wondering if you are aware of: https://github.com/linuxwacom/xf86-input-wacom/issues/93 This is *not* a Krita bug, but I'm wondering if Krita's flatpak distro should set / mention `QT_XCB_TABLET_LEGACY_COORDINATES=1` as this fixed the issue. STEPS TO REPRODUCE 1. Use Krita 4.3.0 via flatpak on current Manjaro / Gnome Desktop 2. Use external USB Wacom tablet stylus to click user interface 3. Offset in clicks on UI OBSERVED RESULT Clicks with Stylus are offset so that Krita is basically unusable via Stylus. Strangely, the offset does not occur when drawing inside the canvas. Anyway, it's a xf86-input-wacom bug (see above). EXPECTED RESULT Correct offsets. SOFTWARE/OS VERSIONS macOS: Manjaro/ gnome ADDITIONAL INFORMATION
Hi, Bernhard! Could you check if the bug is reproducible using our AppImage build? https://download.kde.org/unstable/krita/4.4.0-beta1/krita-4.4.0-beta1-x86_64.appimage We have a heavily patched Qt in our AppImages, it might be that the problem is solved by one of our patches.
The ticket mentions this Qt bugreport. I don't know how it is related, but we don't have the patch for it shipped with our AppImage https://bugreports.qt.io/browse/QTBUG-77826
Hi Dmitry, I tried the 4.3.0 AppImage and it works out of the box. So it is a issue only with flatpak. The only reason I use flatpak and not the AppImage is that only flatpak supports the QT Breeze style (via QT_STYLE_OVERRIDE), but that's a different issue.
Hi, Bernhard! Do you know what Qt version is used for building flatpack? Is it the one that comes from the distribution? The problem is that `QT_XCB_TABLET_LEGACY_COORDINATES=1` will make the quality of the stylus lines much worse. So I'm a bit hesitant to adding this workaround silently. I would prefer if people just used AppImage instead. Though we should still find out why this problem appears (might be that flatpack uses some newer version of Qt, which is buggy).
Created attachment 132083 [details] flatpak manifest.json
Created attachment 132084 [details] manifest.json for org.kde.platform
The QT version seems to be 5.14.2. From the krita's flatpak manifest.json (see attachment), it includes org.kde.Platform 5.14, which on the other hand (see attachment for manifest.json of org.kde.Platform) seems to be based on QT 5.14.2. This makes me wonder whether the bug from https://bugreports.qt.io/browse/QTBUG-77826 is actually really fixed in 5.14.1, as the ticket there states.
Checked again: I can very reliably reproduce this issue with the flatpak version (QT 5.14.2) and with the Manjaro package version (QT 5.15). I also added a detailed description of the issue in the QT tracker at: https://bugreports.qt.io/browse/QTBUG-77826?focusedCommentId=529613&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-529613 Really hope that this thing does not get ping-ponged between QT and xf86-input-wacom.
CLosing as upstream then. There's nothing _we_ can do.
Hi, Bernhard! I have installed flatpack version of Krita on Ubuntu 18.04 and the offset is reproducible. I have a feeling like that bugfix in Qt actually **caused** the offset problem. The offset problem appears only in case HiDPI settings is enabled, e.g. QT_SCALE_FACTOR=2 flatpak run org.kde.krita
Reported upstream: https://github.com/flathub/org.kde.krita/issues/25
Hi Dmitry, this is interesting. I can confirm that I did all my tests on a HiDPI display with scale factor 2.
Hi, Bernhard! Looking at the code, I have a feeling that the fix for the Qt bug you linked actually introduced this regression, though I didn't test that yet: https://codereview.qt-project.org/c/qt/qtbase/+/285182 Flatpak people also started a build of Krita with our own version of Qt, please test when it is ready: https://github.com/flathub/org.kde.krita/pull/26
Okay, I confirm that this patch introduces the issue: https://codereview.qt-project.org/c/qt/qtbase/+/285182