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 154657 - Tablet puck or stylus doesn't track properly in relative (mouse) mode (wintab)
Tablet puck or stylus doesn't track properly in relative (mouse) mode (wintab)
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Backend: Win32
2.4.x
Other Windows
: Normal normal
: Medium fix
Assigned To: gtk-win32 maintainers
gtk-bugs
: 167958 300918 335050 401257 432443 595499 604569 608895 609885 612767 639902 653433 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-10-06 09:20 UTC by Shaneyfelt
Modified: 2018-02-10 04:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Possible patch (1.75 KB, patch)
2004-10-06 20:19 UTC, Robert Ögren
none Details | Review
Proof of concept diff for manual setting to use system cursor position (3.90 KB, text/plain)
2005-03-06 20:17 UTC, Robert Ögren
  Details

Description Shaneyfelt 2004-10-06 09:20:36 UTC
I use WaCom tablet with a puck and stylus 
on a dual monitor Windows system.  

The stylus and mouse work fine, but the puck is
obviously malfunctioning so that it is unusable
with the canvas. 

When slightly hovering over the pad, it is 
sometimes possible to have some control over 
the active tool's x,y but the problems include:

1. The scale is way off
2. The model of how it works (absolute vs. relative) 
seems to be completely wrong. so the 
tool does not follow the cursor. (for example,
if I have a brush selected, I expect to see 
a dashed circle under the point of the cursor tip,
but it is off doing its own thing, perhaps moving 
relative to where it last was when the puck 
was down close to the pad)

However, the cursor for menus, etc. tracks
properly.  A consistent model of operation
needs to be used for the puck's with the
currently selected tool, like that of the 
pointer.

The problem only occurs when using --use-wintab
to get pressure sensitivity with the stylus.
I would expect the puck to operate the same
as it did when it didn't have --use-wintab specified,
except that it could have its own tools/patterns/colors/etc. 
selected for use.

I haven't had time to reconfigure with single
monitor yet, but I expect the problem would 
occur based on observations so far.

Perhaps someone else with a puck may verify 
the problem and better characterize it...
Does it happen on a single monitor system? etc...
Comment 1 Sven Neumann 2004-10-06 10:46:45 UTC
Reassigning to GTK+.
Comment 2 Robert Ögren 2004-10-06 20:14:13 UTC
I can confirm this problem, and it occurs on single-monitor systems as well. The
problem is that the puck is by default set to relative mode (mouse mode) while 
the Wintab code in GTK+ requests absolute mode for tablet motion information.
The Wacom drivers still map the system cursor in relative mode. Therefore the
system cursor is misaligned with for example the brush outline which makes the
puck mostly unusable.

A workaround for this problem is to set the puck to use absolute mode (pen mode)
in the Wacom control panel thingy (accessible from the Windows Control Panel).

Tech details:
According to the Wintab specs, the lcSysMode context field should control the
system cursor tracking mode, but the Wacom drivers seem to ignore that field
unless one also set CXL_SYSOUT in lcLocks. See 
http://www.wacomeng.com/devsupport/ibmpc/wacomwindevfaq.html#FAQ3.7

I don't know if it is completely safe to set CXL_SYSOUT, which will lock the
mapping of the system pointer. I have only tested briefly on my simple Wacom
Graphire 3 (driver 4.78-6) and it seems to work OK for me. One minor side effect
is that if the puck is set to relative mode in the Wacom control panel, then it
will work in relative mode in other applications and then when a GTK+ Wintab
application like GIMP is activated the cursor will suddenly jump to the position
that corresponds to the absolute position on the tablet.
Comment 3 Robert Ögren 2004-10-06 20:19:06 UTC
Created attachment 32303 [details] [review]
Possible patch

Possible patch for gtk-2-4 source. As I said I don't know whether this change
is safe or not, I don't have any other hardware to test on.
Comment 4 Tor Lillqvist 2004-10-06 22:53:43 UTC
I guess the Right Thing would be to make relative mode work as well... How hard 
would it be to make that work? Is there any corresponding stuff in the XInput 
code to look at? (Yeah, I should look myself...)
Comment 5 Robert Ögren 2004-10-07 18:25:08 UTC
I don't see any code that deals with relative coordinates or even relative mode
at all in the xinput code. I would guess that the driver or X server takes care
of reporting nice absolute coordinates (that is absolute w.r.t the screen, not
to the physical position on the tablet) even though the device is set to
relative mode.

I think it would be pretty hard to make things work in relative mode under win32
with the Wacom driver (I don't know if other tablets behave in the same way). I
don't even see a way to find out whether a particular cursor is set to relative
or absolute mode in the Wintab spec. Maybe I missed something. But if the
solution involves making the puck cursor return relative coordinates in the
motion packets then it would probably be hard to make things work reliably. I
can imagine the system cursor and the coordinates reported by the wintab code
constantly getting slightly out of sync. Alternatively one could cheat and
retrieve the coordinates of the system cursor (core pointer) instead, the
downside is that one doesn't get the full resolution that at least the better
tablets can provide but instead only the screen resolution. But this would still
only be doable if there was a way to find out if a particular cursor is set to
relative mode.

One could also consider this to be a driver or even spec defect, how can it be
useful to get tablet coordinates that are absolute to the physical position on
the tablet while the system cursor tracks in relative mode (when using system
context)?

It would be interesting to know how other tablet-aware Windows programs handle
relative mode. I don't have any such program installed right now so I can't test.
Comment 6 Shaneyfelt 2004-10-09 03:49:39 UTC
>Alternatively one could cheat and
>retrieve the coordinates of the system cursor (core pointer) instead, the
>downside is that one doesn't get the full resolution that at least the better
>tablets can provide but instead only the screen resolution.

For a puck, this might be appropriate.  The stylus is better for precision
anyway.  The puck is useful for less precise things like bucket-fill-tool.

It would certainly be better than what we have today.  Is it hard to implement?
Comment 7 Robert Ögren 2004-10-11 20:20:02 UTC
I think the hard part is how to know if a (tablet) cursor is set to relative or
absolute mode (not counting gross hacks like searching for the string "puck" in
the cursor name).
Comment 8 Shaneyfelt 2004-10-12 20:32:05 UTC
I doubt that you need to search for "puck" in the name.
That would be gross, but if we wanted to do some
preliminary testing on tracking it might be a good
start.  We could then proceed in parallel to look for
the proper way to determine the tracking mode.

Looking at the WinTab Interface Spec. it looks like
you should be able to do something like 
WTInfo(WTI_DEVICES,DVC_PKTMODE,&lcPktMode);
should divulge that info, but maybe there's more
to it than that. (Is there some criteria that
has to be met before doing the call?)  I haven't
tried or read much more into it.

Also, there's some interesting demo programs 
with source code at
http://www.pointing.com/FTP.HTM
Specifically, I'm looking at one called 
WT32X126.ZIP\EXAMPLES\SYSPRESS.EXE with 
source code in WTKIT126.ZIP

The demos track the cursor fine with a pen.
I'll try them with the puck when I get back 
to the office.
Comment 9 Shaneyfelt 2004-10-13 01:12:30 UTC
Here's what I found:

I have 6 cursors associated with my tablet
    UINT ncursors;
    WTInfo(WTI_INTERFACE , IFC_NCURSORS, &ncursors);

For each cursor i, the following normally tells whether it uses absolute mode
    UINT mode=-1;
    WTInfo(WTI_CURSORS+i,CSR_MODE,&mode); 
Hwever, that only sets mode if the cursor's lsb of capabilities is set.
    UINT capabilities = -1;
    WTInfo(WTI_CURSORS+i,CSR_CAPABILITIES,&capabilities);

Here's the values I get:
Cursor #0: capabilities: 0, mode: ?, Puck Transducer
Cursor #1: capabilities: 1, mode: 0, Pressure Stylus
Cursor #2: capabilities: 5, mode: 1, Eraser Stylus
Cursor #3: capabilities: 0, mode: ?, Puck
Cursor #4: capabilities: 1, mode: 0, Pressure Stylus
Cursor #5: capabilities: 5, mode: 1, Eraser Stylus
(I don't know why there are two cursors for each item)

Also, the syspress.exe example above has the following 
problems with a puck:
 SM_CXMAXTRACK and SM_CYMAXTRACK should be used instead 
 of SM_CXSCREEN and SM_CYSCREEN when setting lcOutExtX and lcOutExtY
 when using a multimontior system.
(Fortunately, GIMP doesn't have this problem.)
 and
 The puck tracks in absolute mode like GIMP
(Fortunately, GIMP won't have this problem when it gets fixed)

Now that we know if a (tablet) cursor is set to relative or
absolute mode, do you have an easy fix?
Comment 10 Shaneyfelt 2004-10-13 01:17:22 UTC
ps. use CRC_MULTIMODE to test the lsb of cursor capabilities.
Comment 11 Robert Ögren 2004-10-13 20:34:43 UTC
I'm sorry but CSR_MODE does not seem to have anything to do with absolute or
relative mode and instead have to do with how the cursor correspond to physical
cursors. According to the specs:

CSR_MODE (1.1): "Returns the cursor mode number of this cursor type, if this
cursor type has the CRC_MULTIMODE capability."
CRC_MULTIMODE: "Indicates this cursor type describes one of several modes of a
single physical cursor. Consecutive cursor type categories describe the modes;
the CSR_MODE data item gives the mode number of each cursor type."

Just look at the values you got, mode 0 for the pressure stylus and mode 1 for
the eraser stylus. Both these are part of the same physical cursor, they are the
two ends of the pen. I definitely think they both should use absolute mode...

CRC_MULTIMODE could perhaps be used for guessing absolute or relative mode, if a
cursor has CRC_MULTIMODE set then maybe it is likely that it is a stylus-like
cursor which should be used in absolute mode. But what about simpler tablets
which have a stylus without an eraser?

(By the way, I think I read somewhere that the reason that you get twice the
number of cursors than you would expect is that Wacom Intuos tablets support
dual track, that is using two cursors simultaneously on the same tablet. I think
more coding would be required to handle that in GTK+ on win32 though.)
Comment 12 Shaneyfelt 2004-10-14 02:43:36 UTC
That makes sense (the rest of the document consistently
refers to "mode" in conjunction with the words "absolute"
or "relative"). Yes, I agree, the eraser and stylus are both
naturally absolute devices and CSR_MODE indicates which
tool it is.  I suppose rather than hard-code the string 
"puck" into the code, we could make it configurable through
something like  preferences->input->mode  
...and call it a "feature," of course! :)


Comment 13 Shaneyfelt 2004-10-14 05:30:31 UTC
FYI: I just checked my home system which has no eraser tip.
I still get all 6 cursors reported, even though I only have
a stylus tip. I get the same capabilities, names, and modes
reported.
Comment 14 Shaneyfelt 2005-01-22 18:28:02 UTC
WinTab Spec. 1.1(Oct8'04)p43 Table 7.6: WTI_DEFCONTEXT, WTI_DEFSYSCTX, 
WTI_DDCTXS (1.1), and WTI_DSCTXS (1.1) Index Definitiins defines:

Index: 
   CTX_PKTMODE 
Type/Description:
   WTPKT Returns whether the packet data items will be returned in absolute
   or in relative mode.

Is there a way to use CTX_PKTMODE to determine absolute/relative tracking?
Comment 15 Shaneyfelt 2005-01-22 19:10:05 UTC
Oops - I spoke too soon - all those D's stand for default contexts, 
none of which seem to have any relation to the puck.  I suppose the 
system cursor is handled internally by the driver, so it must figure 
out relative vs. absolute through a low level interface within 
the driver that we don't have access to (or it may be hard-coded).

I noticed another bug last night that got me thinking about this
subject... The first click (after working with a different
application) on the canvas registers in the correct place because
the system cursor is selected.  Thereafter, the correct device is 
selected, and it fails.  It might be possible to detect whether 
the cursor is relative by comparing it with the location of the 
system cursor.  This would be "Autodetect" mode.  

Since nothing in the WinTab spec. seems to allow us to discover the
mode properly, I propose that we make a config. setting that defaults
to this "autodetect" mode, that can be overridden by a user
to specify "absolute" or "relative" for each of the items listed 
in the "Device Status" window.

What do you think?
Comment 16 Robert Ögren 2005-01-22 19:38:36 UTC
I recently emailed Wacom about another Wintab issue, and did ask about this too.
So far I've not gotten an answer on whether it is possible to determine if a
particular device is set to absolute or relative mode or not, I'll tell you when
I get the answer.

If it isn't possible to determine it, your suggestion could be a pretty neat
hack. You are more than welcome to try and implement it.
Comment 17 Robert Ögren 2005-02-12 21:08:05 UTC
The not so surprising answer I got was that it isn't possible to get the
absolute/relative setting for a specific transducer through Wintab. So to solve
this, the solution suggested by mr Shaneyfelt in comment #15 is probably the way
to go.
Comment 18 Robert Ögren 2005-02-21 17:37:09 UTC
*** Bug 167958 has been marked as a duplicate of this bug. ***
Comment 19 Robert Ögren 2005-03-06 20:17:44 UTC
Created attachment 38340 [details]
Proof of concept diff for manual setting to use system cursor position

The hard part with changing the configuration dialog is that the dialog is
provided by GTK+ (GtkInputDialog) but it is GIMP that saves and restores the
settings between sessions, so it involves an API change to get this to work
which is not so fun. I tried a hackish implementation that (ab)uses the device
mode setting and adds another option besides GDK_MODE_SCREEEN when compiling
for Windows, and this works without any changes in GIMP but is still an API
change.

However, it might not be such a good idea to have #ifdef G_OS_WIN32 in the
GdkInputMode enum, glib-mkenums gives warnings, and one must make sure that
gdkenumtypes.c gets regenerated when compiling on Windows and that it doesn't
break anything on other OS:es. (Does glib-mkenums even really understand
ifdef?) Suggestions for better ways of implementing this are welcome.

I'll attach a proof of concept implementation as a source diff against gtk-2-6
from anoncvs. This allows the puck to be used in relative mode, but needs more
work and should not be committed to CVS.
Comment 20 Robert Ögren 2005-04-17 19:54:08 UTC
*** Bug 300918 has been marked as a duplicate of this bug. ***
Comment 21 James Kilfiger 2005-12-24 12:49:52 UTC
This bug is also seen in Inkscape 
(at http://sourceforge.net/tracker/index.php?func=detail&aid=1281512&group_id=93438&atid=604306)
Comment 22 James Kilfiger 2006-06-15 13:25:51 UTC
Does the proposed patch apply to current GTK? Does it compile? Does it even work? Is the patch specific to gimp? 
Comment 23 Robert Ögren 2006-06-15 18:59:23 UTC
There are actually two different patches added here, I'm unsure which one you are referring to.

> Does the proposed patch apply to current GTK?

The oldest patch needs to be adjusted to apply. The other one I'm not so sure about, but it is also over a year old. Why don't you try yourself?

> Does it compile?

Both of them did compile when I wrote them. If either patch can still be applied, it will probably also compile.

> Does it even work?

They both worked at the time I wrote them. But note that they work differently. The oldest patch just locks the tablet to use absolute mode regardless of the tablet configuration while the application has focus.

The newer proof of concept patch was an attempt at allowing relative mode. The problem with this patch is not with determining the cursor coordinates but how to allow the user to choose which alternative to use for each device. The reason this gets a bit complicated is that GTK+ provides the input device configuration dialog but leaves it to the application (e.g. GIMP) to save the settings. See also comment #19. I still don't know any easy way of fixing the user interface without needing API changes. Suggestions are welcome.

> Is the patch specific to gimp?

No, all the changes are in GTK+. They just affect how GTK+ determines what coordinates to send in the tablet events.

Also note that with the later patch, the client application (GIMP) needed to be recompiled to pick up the new enum value if I remember correctly.
Comment 24 Alex Robinson 2006-06-26 08:49:17 UTC
*** Bug 335050 has been marked as a duplicate of this bug. ***
Comment 25 Shaneyfelt 2006-06-27 21:58:26 UTC
> Suggestions are welcome.

Here's a suggestion:

For this release, we could use an environmental variable instead of GUI.
That would probably be a good enough work around for now considering 
that the proportion of people who use pucks is probably not overwhelming.

Then address GUI problem as a separate issue.
Comment 26 Michael Schumacher 2007-01-27 13:37:11 UTC
*** Bug 401257 has been marked as a duplicate of this bug. ***
Comment 27 Tor Lillqvist 2007-04-23 09:33:05 UTC
*** Bug 432443 has been marked as a duplicate of this bug. ***
Comment 28 Ola Lindberg 2007-05-18 16:30:26 UTC
I actually got both Gimp and Inkscape to work in pen mode with an Graphire 4 but after re-installing Windows I can't get it working any more. Is there any solution to this?
Comment 29 Ola Lindberg 2007-06-03 15:22:24 UTC
Now I know why it worked before. I managed to disable pressure sensibility and since I only use my tablet for ergonomic reasons I didn't realize that it was disabled. Both Gimp and Inkscape seems to be usable without the pressure sensibility.

Sorry for my posts.
Comment 30 David Császár 2007-09-27 18:23:10 UTC
same or related problem on my tc1100 tablet pc.
note that wacom's tablet pc driver has no option to choose from absolute or relative mode.
Comment 31 David Császár 2008-02-07 10:14:50 UTC
observations with recent synfig (gtk+ 2.10.11) and inkscape (.46 pre 1):

in landscape mode the mouse cursor and drawing area are in sync.

in portrait mode the drawing area is smaller than the mouse cursor area. i. e. clicking in the upper left screen will draw about 8 pixels to the lower right of the pointer, clicking in the lower right screen will draw about 4 pixels to the upper left of the pointer position.

rotating the screen or toggling rulers on/off in inkscape confuses the offset even more until the window is resized once.

wacom driver is 5.05-7
Comment 32 Peter John 2009-01-28 11:28:49 UTC
Okay, it's 2009 and the bug's been around since at least 2005. It's moving in on 4 years now and AFAIK this bug exists for no good reason.

Inkscape's "cursor markers" (arrows in the X and Y rulers) are obviously accepting input in "absolute" mode while my cursor is obviously behaving in "relative" mode. 

My question is, given that you can probably detect why TYPE of a device is on a tablet at any given moment, and that you don't need Wintab for input if the user doesn't own a tablet, why not simply ignore Wintab if a puck is present? 

Think about it. The user loses nothing; as far as I know, tablet mice, Wacom or otherwise, have never had any sort of "pressure" sensitivity. With that in mind, if GTK's Win32 port simply ignores Wintab input and simply accepts whatever Windows is sending as the pointer position (e.g. the input GTK gets when no tablet is present), there's no need to go through all the trouble of converting Wintab data to "relative" information on the fly.

Is this possible on a technical level? Obviously my knowledge of how GTK works in Windows is negligible, as I'd love nothing more than to attempt to implement what seems like an "easy" fix.
Comment 33 Hans Breuer 2009-01-28 19:51:05 UTC
(In reply to comment #32)
> [...] why not simply ignore Wintab if a puck is present? 
> 
Not sure if Inkscape is properly implementing passing through gtk options, but did you ever try "Inkscape --ignore-wintab"?
Comment 34 Ola Lindberg 2009-01-28 20:41:59 UTC
I'm running both Inkscape and Gimp with the --no-wintab option. Both works fine but I loose the pressure sensibility.
Comment 35 David Császár 2009-01-29 08:32:44 UTC
i think what peter (and ola) would like to have is a workaround like the one i suggested in bug 145430 comment 20:

...adding another option, to disable x/y tablet input (just use mouse
coordinates) but keep pressure and device detection.

this would be far away from a fix, but maybe easy to implement.
(on the user interface side it is definately trivial: just let the user choose "none" for the x and y axis. currently 'none' is offered but cannot be selected.)
Comment 36 Peter John 2009-01-29 08:44:37 UTC
Actually, David, that does indeed sound perfect. I don't see any flaws with that methodology. Has anyone asked the Blender devs? Blender doesn't seem to have this problem at all, and pressure sensitivity works fine in the sculpting tools.
Comment 37 David Császár 2009-01-29 08:57:37 UTC
just discovered that robert's patch in attachment 38340 [details] is exactly the workaround i've been talking about.
could we avoid the api change robert mentioned in comment 23 by implementing it the way i suggested: "none" for the axes? (it could be renamed "system pointer" to make it clear to the user what it means.)

regarding a correct fix:
in addition to the blender developers one could try to contact boris eyrich (the artweaver developer). although not open source (and delphi based) maybe he can offer helpful code snippets too? just ask him in the artweaver forum.
Comment 38 Peter John 2009-07-08 10:14:48 UTC
Is there a more recent version of this patch? It seems that it's from 2006 and I'm doubtful that it would compile with the current GTK source. A compiled verison would even more appreciated.
Comment 39 Michael Schumacher 2009-09-17 19:53:28 UTC
*** Bug 595499 has been marked as a duplicate of this bug. ***
Comment 40 Ola Lindberg 2009-12-21 11:27:45 UTC
Anyone seen any improvements on this issue?
Comment 41 Ola Lindberg 2010-01-07 18:47:34 UTC
A possible similar issue in the Qt bug database: http://bugreports.qt.nokia.com/browse/QTBUG-6127
Comment 42 Michael Schumacher 2010-01-27 19:41:13 UTC
*** Bug 604569 has been marked as a duplicate of this bug. ***
Comment 43 Ola Lindberg 2010-01-27 21:43:20 UTC
I created a thread in the Wacom forums: http://forum.wacom.eu/viewtopic.php?f=4&t=3078 hope it could lead to something.
Comment 44 Michael Schumacher 2010-02-03 15:56:57 UTC
*** Bug 608895 has been marked as a duplicate of this bug. ***
Comment 45 Michael Schumacher 2010-02-04 23:43:52 UTC
(In reply to comment #43)
> I created a thread in the Wacom forums:
> http://forum.wacom.eu/viewtopic.php?f=4&t=3078 hope it could lead to something.

The comment by Wacom indicates that they have not read the bugs you pointed them to.
Comment 46 Jeff Bacon 2010-02-10 03:36:50 UTC
I've reproduced this bug on a Monoprice tablet.  Tablet is made by UC Logic (model link, http://www.monoprice.com/products/product.asp?p_id=5553)

Reproduced on Inkscape and Gimp, WinXPsp3.  No option to switch relative/absolute modes in the driver for this tablet.

This is not a Wacom tablet... but appears to be the same issue.
Comment 47 Michael Schumacher 2010-02-14 13:01:27 UTC
*** Bug 609885 has been marked as a duplicate of this bug. ***
Comment 48 Matthew Clemence 2010-02-16 20:41:13 UTC
Cause of tablet offset error (win 32) on my system identified (gtk V2.16.6) demostrated with "scribble" tutorial application

Short description
        Scaling factor for tablet conversion is incorrect if root window dimensions don't match windows tablet active area.
function  gdk_input_translate_coordinates()

Long description
I wanted to use Gimp + tablet on windows 32 platform and my main system suffered from the offset error on the draw cursor. System cursor is correct (icons activated at the correct place) but drawing on canvas off. Set up two systems to build gtk2.16.6 to - one showed error, the other didn't. Compiled scribble tutorial application to demonstrate with the same effect as in gimp so scribble used there after. (GDK_DEBUG=input + some extra compiled in print lines)

System is WinXP with Aiptex tablet and hyperpen driver V3.23. (not important) but with two monitors (is important). Tablet only active area over one monitor.
Monitor 1 resolution 1440x900, Monitor 2 resolution 1280x1024, continuous desktop.

Wintab context is generated correctly in particular
lcName = AIPTEK WINTAB TABLET CONTEXT
lcInOrgX = 0, lcInOrgY = 0, lcInOrgZ = 0
lcInExtX = 2899, lcInExtY = 2149, lcInExtZ = 0
lcSysOrgX = 0, lcSysOrgY = 0
lcSysExtX = 1440, lcSysExtY = 900

However scale factors calculated by gdk_input_translate_coordinates()incorrect

Added debug line
    g_print("trans_coord dev width (%g %g) impl width (%g %g) scale (%g %g) offset (%g %g)",
      	device_width, device_height,
	(double)(root_impl->width),(double) (root_impl->height),
	x_scale,y_scale,
	x_offset,y_offset);

Recieved -
trans_coord dev width (2899 2149) impl width (2720 1024) scale (0.938255 0.476501)

In function _gdk_root_window_size_init() - 




Groot size init current (2720 1024) monitor 1 (4049048 4049052)
Comment 49 Matthew Clemence 2010-02-16 20:44:29 UTC
Sorry hit return - comment 48 contiued ...

So sees on one monitor reported, dimensions the sum of monitor x + largest of monitor y's. As scale factors calculated from this the offset is wrong.

In my case, disabling one monitor restores normal behvaior but tabet functions should be harmonised to actual screen behavior. Having a look at how best to do that but any advice welcome.

Hope this is informative

Regards

Matthew
Comment 50 Ola Lindberg 2010-02-16 20:56:14 UTC
(In reply to comment #49)
> Sorry hit return - comment 48 contiued ...
> 
> So sees on one monitor reported, dimensions the sum of monitor x + largest of
> monitor y's. As scale factors calculated from this the offset is wrong.
> 
> In my case, disabling one monitor restores normal behvaior but tabet functions
> should be harmonised to actual screen behavior. Having a look at how best to do
> that but any advice welcome.
> 
> Hope this is informative
> 
> Regards
> 
> Matthew

So your tablet works if you only use one monitor? (Mine doesn't)
Comment 51 Matthew Clemence 2010-02-16 22:01:17 UTC
(In reply to comment #50)
> (In reply to comment #49)
> > Sorry hit return - comment 48 contiued ...
> > 
> > So sees on one monitor reported, dimensions the sum of monitor x + largest of
> > monitor y's. As scale factors calculated from this the offset is wrong.
> > 
> > In my case, disabling one monitor restores normal behvaior but tabet functions
> > should be harmonised to actual screen behavior. Having a look at how best to do
> > that but any advice welcome.
> > 
> > Hope this is informative
> > 
> > Regards
> > 
> > Matthew
> 
> So your tablet works if you only use one monitor? (Mine doesn't)

Yep - but i've found one case where the tablet driver reported output dimensions doesn't match the windows root window dimensions from which the offsets are calculated. There may well be other cases where this happens. You can get the tablets status under windows using the debug options but not the root window dimensions without recompiling.
Comment 52 David Császár 2010-02-17 07:18:45 UTC
Playing with this debug option I found out that GTK completely ignores pen calibration on my system.
That is, no matter how I calibrate my pen/screen relation, GTK always uses the raw pen coordinates. That explains the cursor offset.

The (WinTab API) question is, at which stage calibration should be taken into account, and why doesn't it happen?


lcInOrgX = 0, lcInOrgY = 0, lcInOrgZ = 0
lcInExtX = 15980, lcInExtY = 21240, lcInExtZ = 0
lcOutOrgX = 0, lcOutOrgY = 0, lcOutOrgZ = 0
lcOutExtX = 768, lcOutExtY = 1024, lcOutExtZ = 0
lcSensX = 1, lcSensY = 1, lcSensZ = 1
lcSysMode = 0
lcSysOrgX = 0, lcSysOrgY = 0
lcSysExtX = 768, lcSysExtY = 1024
lcSysSensX = 1, lcSysSensY = 1
Comment 53 Matthew Clemence 2010-02-17 20:24:37 UTC
(In reply to comment #52)
> Playing with this debug option I found out that GTK completely ignores pen
> calibration on my system.
> That is, no matter how I calibrate my pen/screen relation, GTK always uses the
> raw pen coordinates. That explains the cursor offset.
> 
> The (WinTab API) question is, at which stage calibration should be taken into
> account, and why doesn't it happen?
> 
> 
> lcInOrgX = 0, lcInOrgY = 0, lcInOrgZ = 0
> lcInExtX = 15980, lcInExtY = 21240, lcInExtZ = 0
> lcOutOrgX = 0, lcOutOrgY = 0, lcOutOrgZ = 0
> lcOutExtX = 768, lcOutExtY = 1024, lcOutExtZ = 0
> lcSensX = 1, lcSensY = 1, lcSensZ = 1
> lcSysMode = 0
> lcSysOrgX = 0, lcSysOrgY = 0
> lcSysExtX = 768, lcSysExtY = 1024
> lcSysSensX = 1, lcSysSensY = 1

Based on my (admittdly old) tablet and driver, this is what I see if use the pen cursor in absolute mode. My tablet has a raw resolution of 2899x2149. Coordinates below from debug as above, i.e. origins and widths 
If I use it in full screen ... 
The In matrix (0,0) (2899,2149) maps to the out matrix (0,0,2899,2149).
The out matrix (0,0,2899,2149) maps to the Sys (windows) matrix (0,0,1440,900) - i.e. my 1st monitor dimensions (where the error occurs as gtk thinks it is bigger).

If I use a reduced working area, the pen only responds to a smaller area of the tablet. In this case tt changes to
The In matrix (576,932) (909,581) (the reduced area in tablet coords) maps to the out matrix (0,0,2899,2149) - (so internally scales up to original resolution)
The out matrix (0,0,2899,2149) maps to the Sys (windows) matrix (0,0,1440,900) as before. 

So in my case, all calibrations are handeled internally to the driver and all windows sees (and the WINTAB motion events) are windows system coordinates. 

I your driver seems to internally scale down to the monitor resolution (i.e. 1 pixel rather than sub pixel) (so instead of performing 1 to 1 mapping In->Out, it performs 1 to 1 mapping out->sys. but that shouldn't cause problems. i.e. all of your calibration is hidden in the driver at the In->Out stage all we get out at the end is the montor system coordinates. (assuming your monitor is 768x1024 portrait). I would love to know your groot window dimensions!

Matthew
Comment 54 Ian 2010-03-27 14:01:54 UTC
I have a similar problem with my Linux sysem

Only when tablet is in relative mode (as desired)

GIMP or Inkscape fixes the the drawing-tool coordinates at (0,0) on the WINDOW or SCREEN (depending on program setting)

GIMP/Inkscape reports drawing-tool coordinates as if the the tool was placed at (0,0) in the WINDOW or SCREEN
  This may be a negative value

The actual pointer (read by Kubuntu) exhibits desired/expected behavior
Therefore I can control menus, etc.

Since it happens in both GIMP and Inkscape, I think this is an issue with GTK

This does not occur when tablet is in absolute mode

Kubuntu 9.04 (Jaunty)
GTK 2.0
GIMP 2.6.6
Wacom Bamboo Fun 4x6


Any progress on this?
Comment 55 Ian 2010-03-27 14:08:29 UTC
Sorry GTK v. 2.16.1-0ubuntu2
Comment 56 Ola Lindberg 2010-03-27 15:00:12 UTC
I have similar issues as Ian in Ubuntu 9.10 and Ubuntu 10.4 (pre release)
Comment 57 Javier Jardón (IRC: jjardon) 2010-05-20 19:33:07 UTC
*** Bug 612767 has been marked as a duplicate of this bug. ***
Comment 58 David Császár 2010-11-01 22:39:21 UTC
fixed for my Windows TC1100 (comment 30) with Wacom Penabled Driver Driver 7.01-8 (RC) after re-calibration
Comment 59 Michael Schumacher 2011-06-16 09:24:28 UTC
*** Bug 639902 has been marked as a duplicate of this bug. ***
Comment 60 Michael Schumacher 2011-06-27 23:27:22 UTC
*** Bug 653433 has been marked as a duplicate of this bug. ***
Comment 61 Shaneyfelt 2011-06-30 04:35:06 UTC
Comment #37, et. al. were submitted ears ago. Some as early as 2004. Isn't it about time to commit something at least for the interim?
Comment 62 Shaneyfelt 2011-06-30 04:35:13 UTC
Comment #37, et. al. were submitted ears ago. Some as early as 2004. Isn't it about time to commit something at least for the interim?
Comment 63 Michal 'hramrach' Suchanek 2012-05-31 14:19:27 UTC
Hello,

this happens with any tablet in relative mode.

The Wacom control panel allows switching the pen to relative or absolute mode.

Absolute mode does not work with dinput, relative mode does not work with Gimp (and other GTK apps trying to use the tablet data), and Qt apps.
Comment 64 Matthias Clasen 2018-02-10 04:33:25 UTC
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and
still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue
for it.