After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 776883 - Pen input incorrect on multiple monitor system, with different stretch factor
Pen input incorrect on multiple monitor system, with different stretch factor
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Class: GdkDevice
3.22.x
Other Windows
: Normal normal
: ---
Assigned To: gtk-bugs
Carlos Garnacho
Depends on:
Blocks:
 
 
Reported: 2017-01-04 22:09 UTC by Eske Rahn
Modified: 2018-05-02 17:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Output from mingw64 (35.39 KB, text/plain)
2017-01-04 23:15 UTC, Eske Rahn
Details

Description Eske Rahn 2017-01-04 22:09:49 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.
Comment 1 Eske Rahn 2017-01-04 23:15:19 UTC
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
Comment 2 Andrew Chadwick 2017-01-24 11:13:02 UTC
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.)
Comment 3 GNOME Infrastructure Team 2018-05-02 17:57:02 UTC
-- 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.