My current nightly build works fine, build 8e8c855 from a little while ago. When attempting to update to a newer nightly ( 5c98a72 ), I found that my pen is incorrectly offset when using the environment variable QT_SCALE_FACTOR set to anything but 1. For me it is set to 1.5. The distance the pen is offset seems to be proportional to this value. Krita seems to believe the pen is further toward the bottom of the screen than anticipated. As my tablet is 4k and my main monitor is not, and KDE does not currently support fractional scaling, I must scale Krita using QT_SCALE_FACTOR in a bash script before launch. This has worked fine for a couple years now, but no longer works and I'm not sure exactly which build the problem began. OS Information Build ABI: x86_64-little_endian-lp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: linux Kernel Version: 5.19.0-29-generic Pretty Productname: Ubuntu 22.10 Product Type: ubuntu Product Version: 22.10 OpenGL Info Vendor: "NVIDIA Corporation" Renderer: "NVIDIA GeForce RTX 4090/PCIe/SSE2" Version: "4.6.0 NVIDIA 525.60.11" Shading language: "4.60 NVIDIA" Requested format: QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) Current format: QSurfaceFormat(version 4.6, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::DoubleBuffer, swapInterval 0, colorSpace QSurfaceFormat::DefaultColorSpace, profile QSurfaceFormat::CompatibilityProfile) Version: 4.6 Supports deprecated functions true is OpenGL ES: false supportsBufferMapping: true supportsBufferInvalidation: true forceDisableTextureBuffers: false
Also happens in 5.1.5 stable All the popup dialogs (new file, configure krita, etc) will only map correctly to mouse inputs, the tablet is offset significantly (For example if I want to select a preset I have to click the "Image Size" label) relative to QT_SCALE_FACTOR, in my case they're offset to the upper left corner, this may be relative to if the tablet has higher resolution than the primary screen(s) or not, Ralek's tablet is 4K with a smaller primary screen, mine is 1440p with 4K primary screens. Krita's builtin hiDPI setting does not seem to have any effect, as a workaround I'm overriding the .desktop file in .local/share/applications but this isn't tenable long-term (since it requires manual intervention to update) to force krita to launch with QT_SCALE_FACTOR=1.0 My guess is that the main UI already ignores QT_SCALE_FACTOR since I didn't notice any apparent size change of UI elements when forcing scaling off, and it only partially does this for popups.
Created attachment 155368 [details] Example of offset, the dropdown box for presets was clicked
Created attachment 155570 [details] Possible offset origin An update- The amount that the pen is offset on the y axis is not dependent on resolution or scale, it is a product of the monitor's position as viewable by the command xrandr By moving my drawing tablet monitor to have a '0' y axis offset, as reported by xrandr: >DP-0 connected 3840x2160+5440+0 (normal left inverted right x axis y axis) 522mm x 293mm The pen offset has disappeared entirely, as far as I can tell. Within the monitor settings GUI, this is visible as the drawing monitor being neither above nor below the 'bounding box' of all monitors. See attachment
(In reply to Ralek Kolemios from comment #3) > The pen offset has disappeared entirely, as far as I can tell. It is worth noting this workaround does not apply to dialog windows. Dialog windows are dependent on QT_SCALE_FACTOR. They work properly so long as the top left of the dialog matches exactly with the top left of the screen they are on, otherwise they are offset by the scale amount down and to the right. (Or up and to the left for scale factors smaller than 1)
I've discovered this is a QT specific bug that made its way into the recent Krita QT update. Bug was reported here: https://bugreports.qt.io/browse/QTBUG-77826 Workaround to get Krita to correctly track the mouse position is to set the QT_XCB_TABLET_LEGACY_COORDINATES environment variable to an empty string "" like so > QT_XCB_TABLET_LEGACY_COORDINATES="" application
Then we can close this as upstream
Git commit 419271386586d1fa6c34efd7ec231f2f3bed002c by Dmitry Kazakov. Committed on 06/04/2023 at 11:21. Pushed by dkazakov into branch 'master'. Fix highdpi conversion of QTabletEvent coordinates on xcb That was a regression from updating to Qt 5.15 M +1 -1 3rdparty/ext_qt/CMakeLists.txt https://invent.kde.org/graphics/krita/commit/419271386586d1fa6c34efd7ec231f2f3bed002c