GNOME Bugzilla – Bug 776883
Pen input incorrect on multiple monitor system, with different stretch factor
Last modified: 2018-05-02 17:57:02 UTC
A bug first seen on myltiple versions of MyPaint, but also seen on the GTK3 demo https://github.com/mypaint/mypaint/wiki/Debugging-tablet-issues-on-Windows#testing-with-gtk3-demo It only works correctly with pen on multiple monitors if win 10 is set for the SAME SCALING on both monitors (have not tested it with more than two) It gets the pen position wrong (using the wrong scaling I assume). Mouse or finger positioning works correct. I'm on a 14" 2560x1400 (almost QHD) touch and pen enabled laptop [Lenovo X1 Yoga, type 20FQ] set for 125% with an external secondary non touch 40" 3840x2160 (QFHD/UHD) display [Philips bdm4065uc] set for 100%. If both are set to the same e.g. 100% or 125% pen positioning works just fine The pen driver is by Lenovo, version "1.82.04.01 built by: WinDDk", and is called ApsHM64.sys The scaling is done from the lower left of the screen. It does not matter which display I set for primary/secondary if the scaling factor is the same on both displays everything is OK If the scaling factor on my pen display is LARGER than on the secondary, then the actually point addressed is further away from the lower left by the RATIO of the two scaling factors, (both X and Y). If the scaling factor on my pen display is SMALLER, then X only(!!!!) gets closer to the left edge, I can't figure out by what factor, but dependant on both scaling factors, but not JUST the ratio... (Y is correct though!) All works perfectly correct with both mouse and finger touch. And other pen programs works just fine. Note in both, the pen-marker it self when close to or touching the display is correct. It is the cross-hair (and pressure marker) that is placed wrong. I noted something REALLY strange, that might help debugging: If I change the scaling to the same on both monitors, and test that everything works, and then change the scale on one, and hover the pen over the test-windows WITHOUT touching the display, the cross-hair is positioned correctly under the pen(!) until I touch the display, then it jumps. So the engine CAN do it correct, and does so until first pen-touch!! So have a look on whatever happens at touch, that might mess up things.... Both pen-touch, finger-touch and mouse-click trigger the error It seems that the mingw ONLY displays "gdk_input_other_event:" AFTER the first touch, but updates the cross-hair correctly BEFORE that. And the event displays physical (not logical) pixel coordinates within the test-window. e.g.: WINTAB motion: 3154.97,1304.04 gdk_input_other_event: window=00000000006e14fc +2521+1316 so it seems that it scales things that should not be scaled. (or things are scaled more than once) But note that the behaviour is different in X and Y when the pen display got the smallest scaling factor, here Y is correct and X is wrong.
Created attachment 342912 [details] Output from mingw64 Started the test-program, gtk3-demo --gdk-debug=input --run=event_axes moved the pen rather quickly into the window, touched the display once and removed the pen
There is a downstream suggestion that a 3rd-party program called "Lazy Nezumi" might work around the problem, to a first approximation: https://github.com/mypaint/mypaint/issues/704#issuecomment-274322395 It's something we should be aware of. To reproduce this bug enough to help fixing MyPaint and GTK, that program will almost certainly need to be uninstalled. Anyone formerly using it should probably reinstall their manufacturer's tablet drivers too, just to be on the safe side. (MyPaint v1.2.1 for Windows has just been released. It contains GTK 3.22.7, GTK3-Demo, and GDB (and bash) because I'm sick of useless bug reports☺ I am intending to make matching debug .DLLs for slotting into our builds. Let's get this fixed.)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/734.