GNOME Bugzilla – Bug 154657
Tablet puck or stylus doesn't track properly in relative (mouse) mode (wintab)
Last modified: 2018-02-10 04:33:25 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...
Reassigning to GTK+.
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.
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.
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...)
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.
>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?
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).
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.
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?
ps. use CRC_MULTIMODE to test the lsb of cursor capabilities.
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.)
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! :)
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.
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?
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?
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.
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.
*** Bug 167958 has been marked as a duplicate of this bug. ***
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.
*** Bug 300918 has been marked as a duplicate of this bug. ***
This bug is also seen in Inkscape (at http://sourceforge.net/tracker/index.php?func=detail&aid=1281512&group_id=93438&atid=604306)
Does the proposed patch apply to current GTK? Does it compile? Does it even work? Is the patch specific to gimp?
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.
*** Bug 335050 has been marked as a duplicate of this bug. ***
> 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.
*** Bug 401257 has been marked as a duplicate of this bug. ***
*** Bug 432443 has been marked as a duplicate of this bug. ***
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?
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.
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.
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
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.
(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"?
I'm running both Inkscape and Gimp with the --no-wintab option. Both works fine but I loose the pressure sensibility.
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.)
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.
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.
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.
*** Bug 595499 has been marked as a duplicate of this bug. ***
Anyone seen any improvements on this issue?
A possible similar issue in the Qt bug database: http://bugreports.qt.nokia.com/browse/QTBUG-6127
*** Bug 604569 has been marked as a duplicate of this bug. ***
I created a thread in the Wacom forums: http://forum.wacom.eu/viewtopic.php?f=4&t=3078 hope it could lead to something.
*** Bug 608895 has been marked as a duplicate of this bug. ***
(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.
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.
*** Bug 609885 has been marked as a duplicate of this bug. ***
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)
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
(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)
(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.
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
(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
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?
Sorry GTK v. 2.16.1-0ubuntu2
I have similar issues as Ian in Ubuntu 9.10 and Ubuntu 10.4 (pre release)
*** Bug 612767 has been marked as a duplicate of this bug. ***
fixed for my Windows TC1100 (comment 30) with Wacom Penabled Driver Driver 7.01-8 (RC) after re-calibration
*** Bug 639902 has been marked as a duplicate of this bug. ***
*** Bug 653433 has been marked as a duplicate of this bug. ***
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?
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.
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.