Tablet offset bug -- Interesting fix found.
Page 1 of 1 (7 posts)
Tags:
None
Registered Member 
|
So my thought is, maybe the "fix" I found exposes some underlying issue with the way Krita is programmed.
I have two workstations, a laptop and a desktop which are rigged up with a Ugee HK1650 pen display, and a normal monitor each. Krita plays nice with the Ugee HK1650 if it is in sole monitor mode, but becomes offset if the systems are in extended desktop mode. Now here's the interesting part. In multi-monitor situations, how I open Krita makes all the difference between a functional pen display tablet, and one that refuses to accept any adjustments to offsets or wintab/driver choices. Case A.) Open Krita with mouse. Create new document or load a document with mouse. Pick up stylus, touch stylus to screen. Immediately I am asked if I want to listen to wintab, the tablet drivers, or set my own resolution and offset. No matter which I chose, the offset of the mouse is always wrong and about -1600~2000 pixels on X. Attempts to change Y do nothing. This indicates that the selections are being ignored/not applied, somehow, when made this late into the usage cycle of a Krita document. Case B.) The fix. As silly as this sounds, I open Krita with my stylus. Immediately, Krita's loading logo is interrupted by asking me the same popup. Wintab, tablet drivers, or custom offset. Only now, X and Y offsets are obeyed. Choosing wintab or the drivers, is obeyed. Calibrations are obeyed. I can draw normally and my cursor tracks my stylus accurately. This means that if the stylus logic is addressed early in the Krita software loading up, it is obeyed and applied correctly. In fact, Krita will not finish loading until I make my choice. Most excitingly, this might explain why some users are unable to reliably duplicate the bug. It would be quite normal for many artists to open Krita with their stylus or operate without a mouse entirely. This might explain the mystery of why some users with the same hardware do or do not experience the bug. Environment: Windows 10 creators update / Windows 10 professional creators update. Chipsets: An I5 Mobile and an I5 desktop Graphics: Intel/GeForce on system A, and Geforce on system B Ram: 8GB and 16GB HD: SSD in both cases. Tablet: Ugee HK1560 display digitizer, in multi-monitor system, stylus constrained to it's own screen only. Krita version: 3.2 beta 2 |
|
Registered Member
|
If anyone wants to walk me through what I should file this "Solution" to on the bug tracker, please let me know. There were already a ton of bugs submitted for unrelenting stylus offset problems and I figured my bug report would be more noise in the system.
|
|
Registered Member
|
It would be interesting to see the debug output for both cases.
Would you be able to install DebugView (https://docs.microsoft.com/en-us/sysinternals/downloads/debugview)? For both cases, start DebugView, then start Krita, use the stylus, confirm the tablet resolution and offset, and then save the log from DebugView. |
|
Registered Member
|
Trouble is, that isn't designed for windows 10. It will not give me kernel debug messages or pass-through messages according to the warning message I got when I attempted to use it because it couldn't access specific things in the windows 32 directory that it wanted. In anycase, here's what I got. Broken case first.
Working case.
|
|
Registered Member
|
Turns out that after reading the handling code, it is not related to whether the stylus is used to start Krita or not. When the screen resolution dialog appears, if the stylus is moved out of the proximity of the tablet and re-entered proximity, it will cause the settings in the dialog to not be applied. If the stylus stays within proximity, then the settings are applied.
Can you confirm my observations? I have a fix for this to go in the next release. |
|
Registered Member
|
Can confirm. I purposely pulled my stylus away from the tablet after the dialogue for the choice was presented to me. Then brought the stylus back, made my selection and confirmed it, and then the offset bug came back. Huh!
So I helped you find the problem then? |
|
Registered Member
|
Yes, that's one bug fixed. Thanks for your help
|
Page 1 of 1 (7 posts)
Bookmarks
Who is online
Registered users: Bing [Bot], blue_bullet, Google [Bot], rockscient, Yahoo [Bot]
