I have setup a 2160p monitor and a 1080p pen display. Moving the cursor in the window responds as expected, but on the canvas in offsets the brush proportionately to the pen/mouse/cursor's distance across the screen this persists from 4.0.0, but did not occur in 3.3.3 https://imgur.com/a/zSpeW there is also an issue with window sizing and placement, but I believe these are related so I will not file it as separate bug.
Krita also works normally if used on the 4k display. This issue occurs in all monitor configurations, though horizontal arrangements cause a vertical offset not horizontal as shown in the linked image
Hi, yesimwearingpants! Could you please tell us exact model of your tablet and generate a tablet log as explained here? https://docs.krita.org/KritaFAQ#Linux Btw, does the tablet work correctly in other applications? Basically, on Linux we just read the coordinates directly from X11 events' so the scaling happens somewhere in the driver... Btw, to which display do you map the tablet? To the 4k one or to another one? Or to both?
>lsmod hid 131072 3 hid_generic,usbhid,hid_uclogic >xinput ⎡ Virtual core pointer ↳ Tablet Monitor Pad ↳ Tablet Monitor Pen Pen (0) ⎣ Virtual core keyboard ↳ Tablet Monitor Pen >xinput list-props Device 'Tablet Monitor Pen Pen (0)': Device Enabled (142): 1 Coordinate Transformation Matrix (144): 0.500000, 0.000000, 0.000000, 0.000000, 0.333333, 0.666667, 0.000000, 0.000000, 1.000000 Device Node (268): "/dev/input/event8" Device Product ID (269): 9580, 110 libinput Tablet Tool Pressurecurve (585): 0.000000, 0.000000, 0.000000, 0.000000, 1.000000, 1.000000, 1.000000, 1.000000 libinput Tablet Tool Area Ratio (586): 0, 0 Also I added a third monitor as a test. It seams the brush problem has to due with the empty space beside the 1080p monitor. So it may have to do with how XFCE handles empty space. But feel I should repeat "This didn't occur in 3.3.3"
Yes the tablet works correctly in other applications. I have it bound to the (original as now I have 2 attached) 1080p display
I apologize for the Triple post. log https://etherpad.net/p/vQ9FPBDYMv
I just tried 4.0.1 again and It seems that adding a third monitor was a temporary fix. I am this still having issue. See the Screenshot https://imgur.com/a/zSpeW for an accurate bug report
I've also got this bug, but interestingly unlike Pants this bug occurs on all versions of Krita I have available - including 3.3 and current master built today. Here is a recording of it in action: https://youtu.be/RLbvfJwICvQ The cursor is in the right spot with mouse and tablet, but the brush pen on the canvas moves too fast when multiple monitors are attached. Of interest is that this bug is only happening for me since I got back my AMD graphics card. I was previously using my Intel GPU while it was out for RMA, and when I got the replacement back this started happening. If I disable my other monitors it works as expected, but each monitor introduces "offset" in the direction of the addd screen, same as Pants. I'm going to try to isolate some more variables on this behavior, because it seems to be GPU related.
(In reply to Matt Scheirer from comment #7) > I've also got this bug, but interestingly unlike Pants this bug occurs on > all versions of Krita I have available - including 3.3 and current master > built today. > I hadnt considered but that. For 3.3 I wasnt using the appimage but rather the dedian version > Of interest is that this bug is only happening for me since I got back my > AMD graphics card. I was previously using my Intel GPU while it was out for > RMA, and when I got the replacement back this started happening. > > I'm going to try to isolate some more variables on this behavior, because it > seems to be GPU related. I am using an AMD gpu as well, what mode is your card? Im using an RX 580.
(In reply to yesimwearingpants from comment #8) > I am using an AMD gpu as well, what mode is your card? Im using an RX 580. Also have a 580, and I isolated the problem: https://youtu.be/HIE21UjYawM In my case, the offsets are happening when using the "session-wide" scaling the Displays KCM offers. I had it at 1.5, and once I turned it back to 1 and relogged in the behavior stopped. I know the Displays KCM is doing more than just setting QT_SCREEN_SCALE_FACTORS since it also affects GTK programs, but I'll have to dig in to what exactly its doing.
(In reply to Matt Scheirer from comment #9) > (In reply to yesimwearingpants from comment #8) > In my case, the offsets are happening when using the "session-wide" scaling > the Displays KCM offers. I had it at 1.5, and once I turned it back to 1 and > relogged in the behavior stopped. I know the Displays KCM is doing more than > just setting QT_SCREEN_SCALE_FACTORS since it also affects GTK programs, but > I'll have to dig in to what exactly its doing. I am using XFCE so I dont know where to find that setting. But at least the Debian-testing package is available now and the issue is fixed there.
(In reply to yesimwearingpants from comment #10) > I am using XFCE so I dont know where to find that setting. But at least the > Debian-testing package is available now and the issue is fixed there. I assume that is of some use Again sorry for the double post
Okay, so I'm going to close this then.