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 732063 - tablet pc: tool position mismatches cursor position in a rotated screen when using a pen
tablet pc: tool position mismatches cursor position in a rotated screen when ...
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Backend: Win32
2.24.x
Other Windows
: Normal normal
: ---
Assigned To: gtk-win32 maintainers
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2014-06-22 21:25 UTC by dmitry1234
Modified: 2018-05-02 16:09 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description dmitry1234 2014-06-22 21:25:08 UTC
On a tablet pc, use a pen and switch the screen in upside-down position.
Now try to draw something by a pen - you will notice that cursor is right behind a tip of a pen, but the line is drawn in a position where it should be when a screen is switched in a normal position (center of symmetry of this transfer is a center of a screen). But if you draw a line using a mouse - everything is ok.
The same happens when screen is rotated by 90 degrees - cursor is in correct position, line is where it should be in a normal screen position.
Comment 1 Michael Natterer 2014-06-22 21:38:32 UTC
GIMP is not aware that your tablet screen is rotated, and it should not
need to. This is most probably a bug in windows tablet support, reassigning
to GTK+.
Comment 2 dmitry1234 2014-06-22 22:12:35 UTC
How is it not aware if all the screen, all the GIMP interface, everything is rotated?
If you use a mouse in a rotated mode, everything is fine. Even a cursor when using a pen is in a correct position. The only thing that is wrong - a line (or another tool) which you draw.
All other applications draw correct lines using a pen in upside-down position.
Comment 3 Max Mustermann 2014-06-23 04:48:46 UTC
(In reply to comment #1)
> GIMP is not aware that your tablet screen is rotated, and it should not
> need to. 

I think it should need to know about such a change to decide about reassignment of UI elements (such as the toolbox), image re-orientation, zoom level etc. This also depends on the user's workflow and we loose much control if we let solely GTK+ decide this generally. In my opinion the better way would be that GTK+ notices GIMP about such a change and offers API functions for some common tasks. But this is rather a topic for GTK+ 3 than the already almost dead GTK+ 2.

I also think the problem is more general than this particular, single bug: 
As tablets and other non-PC devices are becoming more and more popular. They necessarily introduce changes in interaction and have less computing power than an (OpenCL enabled) PC. Therefore we should decide generally how to deal with such requests (see my LGM topic proposal).
Comment 4 dmitry1234 2017-08-17 02:47:37 UTC
Just additional information.

The bug exists on Windows XP Tablet Edition.
I've noticed the following:
If I delete wisptis.exe file from windows\system32 (and from windows\system32\dllcache) then there will be the same problem with mismatching cursor and line positions in other applications.
(I also experimented with deletion of tabtip.exe from Program Files\Common Files\Microsoft Shared\Ink\ (and from windows\system32\dllcache) so maybe that file also made the same effect, I just don't remember)

What I tried to do by these deletions was to eliminate "pen lag", you can find discussion about it here:
http://forum.tabletpcreview.com/threads/pen-lag.15949/page-3

As far as I understand in that case of "pen lag" there is some kind of conflict/hampering between Wacom drivers and Win XP Tablet Edition drivers.
And somehow those wisptis.exe and/or tabtip.exe influence coordination of screen orientation and position of tools using pen. Or they recalibrate the pen or something like that, I don't know.

I don't know if it can help, but anyway. 
%)
Comment 5 dmitry1234 2017-08-17 03:05:47 UTC
And to see the bug in action you should be sure that in "Edit->Input Devices" you are using your pen not as "core pointer", but as something like "WACOM Tablet ISD Stylus", and it is not "Disabled", but in "Screen mode" for example. Because when stylus and eraser are "disabled", then (as far as I understand) control goes to "core pointer" (which should be a mouse), your pen become "a mouse" and then everything is fine: your drawing line is in the same position as a tip of the pen in any screen orientations. But! But then you are not able to use other functions of the pen like pressure sensitivity.
Comment 6 dmitry1234 2017-08-17 03:09:23 UTC
And that tablet PC is HP tc4200. 
Just in case.
Comment 7 dmitry1234 2017-08-18 00:37:31 UTC
So, I made another experiment. 
Absence of tabtip.exe doesn't affect cursor and line position in all aplications, only absence of wisptis.exe affects it.

And also there is a difference in behavior:

When wisptis.exe is in place and we see that bug in GIMP, then the main general cursor is in place, all buttons and interface is clickable in the right way and in the right positions, and only the second pointer- dotted circle for brushes, and the line being drawed are in strange position (when screen is upside-down, the dotted circle pointer and the line "think" that they are in normally oriented screen, when the screen is rotated by 90 degrees in any direction, then the dotted circle pointer and the line "think" that they are in a screen which is upside-down [yes, it's rather strange and it is not simple central symmetry as I thought earlier])

But when the wisptis.exe is absent, the main cursor in all applications is in the position as if the screen wasn't rotated.
Comment 8 dmitry1234 2017-08-18 00:39:59 UTC
And, there is absolutely the same problem in Inkscape
https://bugs.launchpad.net/inkscape/+bug/1711258
Comment 9 LRN 2017-08-18 09:19:54 UTC
Does your GIMP use a debug-enabled GTK+ build? Try running with GDK_DEBUG environment variable set to 'events'. If you get a lot out output in the console (provided that you're running development version of GIMP; if you're running stable version, you'll have to ask GIMP developers how to get its console output), then GTK+ is build with debugging enabled.

I've tried a number of available GIMP for Windows installers, and all of them came with a debug-disabled GTK+, but there's always hope that your build is different.

Otherwise i can't do anything - i don't have a tablet PC to test this on (and even then i would have wanted to look at debug logs anyway).

It would help if you manage to reproduce this bug in a different program that comes with a debug-enabled GTK+ build (MyPaint, maybe? Any other GTK+-based programs that support drawing?).
Comment 10 GNOME Infrastructure Team 2018-05-02 16:09:15 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/494.