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 496958 - Wacom Bamboo doesn't function with GTK apps in Win32
Wacom Bamboo doesn't function with GTK apps in Win32
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: Win32
2.12.x
Other All
: Normal normal
: ---
Assigned To: gtk-win32 maintainers
gtk-bugs
: 503445 504628 511104 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-11-15 04:57 UTC by Andy Selvig
Modified: 2008-08-07 08:54 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Wintab packet rate bugfix proposal (470 bytes, patch)
2008-05-09 08:10 UTC, Thomas Bleeker
committed Details | Review

Description Andy Selvig 2007-11-15 04:57:23 UTC
Please describe the problem:
My Wacom Bamboo Fun does not function with GTK apps in Windows (tried GIMP and Inkscape). The pen and mouse work fine when navigating through windows and using other applications (like Paint.NET) but whenever a GTK app is started, then input freezes or responds VERY slowly (once every several seconds). Here's my setup:

Windows XP SP2 32-bit
GTK+ Runtime 2.10.13
GIMP 2.4
Inkscape 0.45.1
Wacom Pen Tablet Driver 5.05-7




Steps to reproduce:
1. Get a Bamboo Fun (or any Bamboo, I don't know)
2. Try it out on a GTK app in Win32



Actual results:
The input (pen or mouse) freeze or respond VERY slowly (once every several seconds). They are completely unusable once the application launches.

Expected results:
The input should remain responsive and allow me to draw pretty pictures.

Does this happen every time?
Yes.

Other information:
I don't know if this is limited to Win32. I was unable to get the tablet working at all on my Ubuntu install, which is the reason I'm using XP in the first place. This could, as far as I know, affect other platforms as well.
Comment 1 Andy Selvig 2007-11-15 14:05:55 UTC
More info: I tested both GIMP and Inkscape with the --ignore-wintab parameter and they both seem to work, except for pressure sensitivity and eraser tool memory. I tried this based on some googling. Some reports also said that the resolution is reduced when you don't use wintab, but I never really used the tablet when it worked correctly do I don't really know. 

Anyway, no pressure is fine for Inkscape but it's a real deal breaker for GIMP. As I said, I've found some other posts online about this, but none that seem to accurately capture it in this database (and it certainly is a bug).

Thanks.
Comment 2 Cody Russell 2007-12-27 17:38:17 UTC
*** Bug 503445 has been marked as a duplicate of this bug. ***
Comment 3 Andy Selvig 2007-12-28 21:08:49 UTC
UPDATE: Problem persists on version 2.12.
Comment 4 Michael Schumacher 2008-01-23 09:50:23 UTC
*** Bug 511104 has been marked as a duplicate of this bug. ***
Comment 5 Tor Lillqvist 2008-01-23 10:31:49 UTC
> UPDATE: Problem persists on version 2.12.

Which isn't surprising as nobody has done anything to fix it. There are only a handful of people who occasionally maintain parts of the Windows-specific code in GTK+, and none of us seems at the moment to be particularly interested in the tablet-related code. Not to mention that few of us probably even have a tablet. I have an old Wacom ArtPad II, but don't really use it, and I am not going to buy a Wacom Bamboo (as suggested in the initial comment) just to fix this bug. Sorry. 
Comment 6 Roger Sæle 2008-01-23 10:50:52 UTC
In bug 496958 Andy Selvig says, and I quote: "...completely unusable once the application launches."

In bug 511104 I am saying that I am using the tablet to draw with GIMP and it works fine, but it freezes from time to time which is annoying.

The way I see it the bugs are not the same since it looks like Andy cannot use his tablet at all due to the problem, whereas I can.



Comment #4 from Michael Schumacher (developer, points: 19)
2008-01-23 09:50 UTC [reply]

*** Bug 511104 has been marked as a duplicate of this bug. ***
Comment 7 Andy Peterson 2008-01-25 13:50:59 UTC
Can you point me to the area of the GTK+ code that would need to be investigated to address this issue?  I'm just curious.
Comment 8 Tor Lillqvist 2008-01-25 15:25:30 UTC
The code you want to look at is gdk/win32/gdkinput-win32.c.

The tablet support in GTK+ on Windows uses the Wintab API. Unfortunately the Wintab API is involved in some legal crap. The Wintab SDK, containing documentation, header files and sample source code used to be freely available from www.pointing.com. But then some "inventor" claimed the Wintab API infringed on his patent. See http://www.pointing.com/Wintab.html .

I guess it shouldn't be too hard to stil find a copy of the Wintab SDK on the net, though. It is useful for the documentation. (The SDK is not required to build the Wintab support in GTK+, as the wintab.h and pktdef.h headers are included in the GTK+ sources. Their license allows this.) I think for instance Wacom distributes the SDK, as they apparently have done a deal with the "inventor" who sued the www.pointing.com guys, or something. I hate legal crap.

It is possible that the Bamboo series doesn't even provide a Wintab interface, but only interfaces through some other API. I don't know what API Microsoft themselves suggest should be used to talk to tablets? TabletPC stuff, even if not running on a TabletPC, but a normal machine, with a separate tablet? DirectInput maybe? I have no idea... It would be useful if you investigated these matters.

Comment 9 Vladimir Domes 2008-01-26 16:12:15 UTC
My Windows Vista with Wacom Bamboo Fun drivers installed looks like TabletPC Edition.
Comment 10 Stuart Rendall 2008-02-03 00:51:33 UTC
In a WACOM forum the problem is discussed fully
http://www.wacom-europe.com/forum/topic.asp?lang=uk&ARCHIVE=&whichpage=4&TOPIC_ID=9696

and a workaround is suggested by the WACOM support team

'The problem that we see here is that you can use the Bamboo including pressure sensitivity until you take the pen out of proximity. When you do this, you should put it back on the tablet at the about the same place from where it was lifted. Otherwise the pointer doesn't move and you have to try perhaps several times bringing the pen into proximity and back until it responds normal again. - This seems to be related to 'unusual' pointer mapping within Gimps tablet handling.'

This tallies with the problems I have experienced
Comment 11 Michael Schumacher 2008-02-04 10:26:33 UTC
*** Bug 504628 has been marked as a duplicate of this bug. ***
Comment 12 Michael Schumacher 2008-02-05 12:22:29 UTC
Maybe someone could ask Wacom to explain the "unusual pointer mapping" a bit further?
Comment 13 mikes 2008-02-17 23:22:35 UTC
(In reply to comment #12)
> Maybe someone could ask Wacom to explain the "unusual pointer mapping" a bit
> further?
> 

just mail to: forumtechnik@wacom-europe.com
i would do if i knew what to ask but i think its better some dev would do...
Comment 14 Kakurady Drakenar 2008-02-20 12:49:59 UTC
I've found this:

http://www.wacomeng.com/devsupport/index.html

Unfortunately since I do not know anything about C or GTK+, I can't help much. (I can't even get the examples on the site to compile and run without error...)

I also found http://sourceforge.net/projects/vbtablet/ which is a wrapper for WinTab for Visual Basic. Seems to work with Bamboo Fun very well.
Comment 15 J.P. 2008-03-04 20:50:25 UTC
I'm running Vista; I'm thinking of getting a Bamboo soon (knowing, of course, that it probably won't work well with the GIMP and Inkscape).  If I do get one, I would be glad to do any sort of testing you guys need to help fix this bug.

-- J.P.
Comment 16 Jon Colverson 2008-03-25 02:43:36 UTC
Hello. I bought a Bamboo Fun last week and I've run into this bug so I've started trying to track it down. I finally made myself a debug build of GTK+ (phew!), so I thought I'd post my initial findings:

To recap the problem (which occurs when using the tablet in the GIMP):

Initially the tablet can appear to be working fine, complete with pressure sensitivity etc.

Sometimes, after moving the pen out of proximity and then back into proximity, the cursor moves to the correct position but then it stops moving. When in this state, pressing the pen onto the tablet doesn't have any effect, nor does pressing the buttons on the pen. Moving the pen back out of proximity does work as expected, and the cursor jumps to the correct position (where the pen was when proximity was lost). Moving it back into proximity again repeats this process (i.e. sometimes the cursor starts working correctly, but sometimes it jumps to the correct position and then stops).

Here is the logging output of when moving out and then back into proximity works correctly:

_gdk_input_other_event: window=000B080C +315+242
WINTAB motion: 315.291,242.328
_gdk_input_other_event: window=000B080C +315+242
WINTAB motion: 315.291,242.328
_gdk_input_other_event: window=000B080C +315+241
WINTAB motion: 315.291,241.912
_gdk_input_other_event: window=000B080C +315+241
WINTAB motion: 315.291,241.912
_gdk_input_other_event: window=000B080C +315+241
WINTAB proximity out
_gdk_input_other_event: window=000B080C +315+241
WINTAB proximity in
_gdk_input_other_event: window=000B080C +332+236
WINTAB motion: 332.202,235.979
_gdk_input_other_event: window=000B080C +331+236
WINTAB motion: 331.78,235.979
_gdk_input_other_event: window=000B080C +331+236
WINTAB motion: 331.075,235.979
_gdk_input_other_event: window=000B080C +330+236
WINTAB motion: 330.793,236.291
_gdk_input_other_event: window=000B080C +330+236
WINTAB motion: 330.511,236.291

and here is the output for when it doesn't work correctly:

_gdk_input_other_event: window=000F0A2C +549+230
WINTAB motion: 548.875,230.446
_gdk_input_other_event: window=000F0A2C +548+230
WINTAB motion: 548.029,230.758
_gdk_input_other_event: window=000F0A2C +547+231
WINTAB motion: 547.183,231.07
_gdk_input_other_event: window=000F0A2C +546+231
WINTAB motion: 546.62,231.382
_gdk_input_other_event: window=000F0A2C +546+231
WINTAB motion: 546.056,231.382
_gdk_input_other_event: window=000F0A2C +546+231
WINTAB motion: 546.056,231.382
_gdk_input_other_event: window=000F0A2C +546+231
WINTAB proximity out
_gdk_input_other_event: window=000F0A2C +546+231
WINTAB proximity in
_gdk_input_other_event: window=000F0A2C +416+321
WINTAB motion: 416.681,320.992

As you can see, the proximity in event is received and apparently processed correctly, and then one motion event is received. No other events are received after this by _gdk_input_other_event (I checked by adding a g_print right at the beginning of the function), until the pen is moved out of proximity again. When that happens a single motion event is received, followed by the proximity out event.

I've also just tried using Spy++ to watch the events, and when the tablet is in the in-proximity but not working state described above, no events are seen by Spy++ either.
Comment 17 Tor Lillqvist 2008-03-25 07:32:18 UTC
Jon, thank you very much! You are doing exactly what we have been waiting for somebody do to all this time, i.e. actually debugging the problem yourself. (Even if "only" by adding more debugging printouts, however for the tablet handling code it is hard to see how one even could do interactive debugging without disturbing what one is debugging...) This will be very helpful.
Comment 18 J.P. 2008-03-26 19:09:20 UTC
Hey--

To Jon: "Hey, I was going to do that!" (re: the debugging; see above messages)

If you guys need any more help with stuff, I'd be glad to help.  Also, any idea on a timeframe for a updated version of GTK with this bug fixed?

Thanks.

-- J.P.
Comment 19 Jon Colverson 2008-03-27 00:55:04 UTC
I can't really give a meaningful timeframe since we don't yet know what the problem is.

I had another look at things tonight, but I haven't made much progress. Here's the initialization log. I don't know if any of this is unusual:

Wintab interface version 1.3
NDEVICES: 1, NCURSORS: 6
Using device-specific default context
Default context:
lcName = 
lcOptions = CXO_SYSTEM CXO_MARGIN
lcStatus =
lcLocks =
lcMsgBase = 0x7ff0, lcDevice = 0, lcPktRate = 100
lcPktData = PK_BUTTONS PK_X PK_Y
lcPktMode =
lcMoveMask = PK_X PK_Y
lcBtnDnMask = 0xffffffff, lcBtnUpMask = 0xffffffff
lcInOrgX = 0, lcInOrgY = 0, lcInOrgZ = 0
lcInExtX = 14760, lcInExtY = 9225, lcInExtZ = 0
lcOutOrgX = -800, lcOutOrgY = 0, lcOutOrgZ = 0
lcOutExtX = 2080, lcOutExtY = 960, lcOutExtZ = 0
lcSensX = 1, lcSensY = 1, lcSensZ = 1
lcSysMode = 0
lcSysOrgX = -800, lcSysOrgY = 0
lcSysExtX = 2080, lcSysExtY = 960
lcSysSensX = 1, lcSysSensY = 1
context for device 0:
lcName = 
lcOptions = CXO_SYSTEM CXO_MESSAGES CXO_MARGIN
lcStatus =
lcLocks =
lcMsgBase = 0x7ff0, lcDevice = 0, lcPktRate = 50
lcPktData = PK_CONTEXT PK_CURSOR PK_BUTTONS PK_X PK_Y PK_NORMAL_PRESSURE PK_ORIENTATION
lcPktMode =
lcMoveMask = PK_CONTEXT PK_CURSOR PK_BUTTONS PK_X PK_Y PK_NORMAL_PRESSURE PK_ORIENTATION
lcBtnDnMask = 0xffffffff, lcBtnUpMask = 0xffffffff
lcInOrgX = 0, lcInOrgY = 0, lcInOrgZ = 0
lcInExtX = 14760, lcInExtY = 9225, lcInExtZ = 0
lcOutOrgX = 0, lcOutOrgY = 0, lcOutOrgZ = 0
lcOutExtX = 14759, lcOutExtY = -9224, lcOutExtZ = 0
lcSensX = 1, lcSensY = 1, lcSensZ = 1
lcSysMode = 0
lcSysOrgX = -800, lcSysOrgY = 0
lcSysExtX = 2080, lcSysExtY = 960
lcSysSensX = 1, lcSysSensY = 1
opened Wintab device 0 00000804
context for device 0 after WTOpen:
lcName = 
lcOptions = CXO_SYSTEM CXO_MESSAGES CXO_MARGIN
lcStatus =
lcLocks =
lcMsgBase = 0x7ff0, lcDevice = 0, lcPktRate = 50
lcPktData = PK_CONTEXT PK_CURSOR PK_BUTTONS PK_X PK_Y PK_NORMAL_PRESSURE PK_ORIENTATION
lcPktMode =
lcMoveMask = PK_CONTEXT PK_CURSOR PK_BUTTONS PK_X PK_Y PK_NORMAL_PRESSURE PK_ORIENTATION
lcBtnDnMask = 0xffffffff, lcBtnUpMask = 0xffffffff
lcInOrgX = 0, lcInOrgY = 0, lcInOrgZ = 0
lcInExtX = 14760, lcInExtY = 9225, lcInExtZ = 0
lcOutOrgX = 0, lcOutOrgY = 0, lcOutOrgZ = 0
lcOutExtX = 14759, lcOutExtY = -9224, lcOutExtZ = 0
lcSensX = 1, lcSensY = 1, lcSensZ = 1
lcSysMode = 0
lcSysOrgX = -800, lcSysOrgY = 0
lcSysExtX = 2080, lcSysExtY = 960
lcSysSensX = 1, lcSysSensY = 1
Attempting to increase queue size
Queue size set to 32
Cursor 0:
NAME: 
ACTIVE: YES
PKTDATA: 0x1e80780: X Y Z NORMAL_PRESSURE
BUTTONS: 0
BUTTONBITS: 5
BTNNAMES: x x
BUTTONMAP:
SYSBTNMAP:
NPBUTTON: 182
NPBTNMARKS: 2357608 1671788497
NPRESPONSE:
TPBUTTON: 0
TPBTNMARKS: 28004408 1707348579
TPRESPONSE:
PHYSID: 0x1
CAPABILITIES: 0:
device: (0) WACOM Tablet m‘|˜V«8V« V«	 v axes: 0
Cursor 1:
NAME: Pressure Stylus
ACTIVE: YES
PKTDATA: 0x15ff: CONTEXT STATUS TIME CHANGED SERIAL_NUMBER BUTTONS X Y NORMAL_PRESSURE ORIENTATION
BUTTONS: 3
BUTTONBITS: 3
BTNNAMES: tip barrel barrel2
BUTTONMAP: 0 1 2
SYSBTNMAP: 1 0 4
NPBUTTON: 0
NPBTNMARKS: 0 1
NPRESPONSE: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 4 6 9 11 13 16 18 20 23 25 27 30 32 35 37 40 42 45 47 49 52 54 57 59 62 64 67 69 71 73 76 78 80 82 85 87 89 92 94 97 99 101 104 106 108 110 113 115 117 120 122 124 127 129 132 134 137 139 141 143 146 148 150 153 155 158 160 163 165 168 170 172 174 176 178 181 183 185 188 190 192 195 197 199 201 203 205 208 210 212 215 217 220 222 224 226 228 230 233 235 237 239 241 244 246 248 250 252 254 257 259 261 263 265 268 270 272 274 276 278 281 283 285 287 289 291 293 295 297 299 301 303 306 308 310 312 314 316 319 321 323 325 327 329 331 333 335 337 339 341 343 345 347 349 351 353 355 357 360 362 364 366 368 370 372 374 376 378 380 382 384 386 388 390 392 394 396 398 400 402 404 406 408 410 412 414 416 418 420 422 424 426 428 430 432 434 436 438 440 442 444 446 448 450 452 454 456 458 460 462 464 466 468 470 472 474 476 478 480 482 484 486 488 490 492 494 496 498 500 502 504 506 508 510
TPBUTTON: 0
TPBTNMARKS: 28004408 1707348579
TPRESPONSE:
PHYSID: 0x1
CAPABILITIES: 0x1: MULTIMODE
MODE: 0
device: (1) WACOM Tablet Pressure Stylus axes: 3
... axis 0: 0--14759@1000
... axis 1: 0--9224@1000
... axis 2: 0--1023@0
Cursor 2:
NAME: Eraser  
ACTIVE: YES
PKTDATA: 0x15ff: CONTEXT STATUS TIME CHANGED SERIAL_NUMBER BUTTONS X Y NORMAL_PRESSURE ORIENTATION
BUTTONS: 1
BUTTONBITS: 3
BTNNAMES: eraser
BUTTONMAP: 0
SYSBTNMAP: 1
NPBUTTON: 0
NPBTNMARKS: 0 1
NPRESPONSE: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 4 6 9 11 13 16 18 20 23 25 27 30 32 35 37 40 42 45 47 49 52 54 57 59 62 64 67 69 71 73 76 78 80 82 85 87 89 92 94 97 99 101 104 106 108 110 113 115 117 120 122 124 127 129 132 134 137 139 141 143 146 148 150 153 155 158 160 163 165 168 170 172 174 176 178 181 183 185 188 190 192 195 197 199 201 203 205 208 210 212 215 217 220 222 224 226 228 230 233 235 237 239 241 244 246 248 250 252 254 257 259 261 263 265 268 270 272 274 276 278 281 283 285 287 289 291 293 295 297 299 301 303 306 308 310 312 314 316 319 321 323 325 327 329 331 333 335 337 339 341 343 345 347 349 351 353 355 357 360 362 364 366 368 370 372 374 376 378 380 382 384 386 388 390 392 394 396 398 400 402 404 406 408 410 412 414 416 418 420 422 424 426 428 430 432 434 436 438 440 442 444 446 448 450 452 454 456 458 460 462 464 466 468 470 472 474 476 478 480 482 484 486 488 490 492 494 496 498 500 502 504 506 508 510
TPBUTTON: 0
TPBTNMARKS: 28004408 1707348579
TPRESPONSE:
PHYSID: 0x1
CAPABILITIES: 0x5: MULTIMODE INVERT
MODE: 1
device: (2) WACOM Tablet Eraser   axes: 3
... axis 0: 0--14759@1000
... axis 1: 0--9224@1000
... axis 2: 0--1023@0
Cursor 3:
NAME: x
ACTIVE: YES
PKTDATA: 0x15ff: CONTEXT STATUS TIME CHANGED SERIAL_NUMBER BUTTONS X Y NORMAL_PRESSURE ORIENTATION
BUTTONS: 1
BUTTONBITS: 5
BTNNAMES: x x
BUTTONMAP: 0
SYSBTNMAP: 1
NPBUTTON: 0
NPBTNMARKS: 0 1
NPRESPONSE:
TPBUTTON: 0
TPBTNMARKS: 28004408 1707348579
TPRESPONSE:
PHYSID: 0x1
CAPABILITIES: 0:
device: (3) WACOM Tablet Eraser   axes: 0
Cursor 4:
NAME: x
ACTIVE: YES
PKTDATA: 0x15ff: CONTEXT STATUS TIME CHANGED SERIAL_NUMBER BUTTONS X Y NORMAL_PRESSURE ORIENTATION
BUTTONS: 1
BUTTONBITS: 3
BTNNAMES: x x
BUTTONMAP: 0
SYSBTNMAP: 1
NPBUTTON: 0
NPBTNMARKS: 0 1
NPRESPONSE:
TPBUTTON: 0
TPBTNMARKS: 28004408 1707348579
TPRESPONSE:
PHYSID: 0x1
CAPABILITIES: 0x1: MULTIMODE
MODE: 0
device: (4) WACOM Tablet Eraser   axes: 0
Cursor 5:
NAME: Eraser  
ACTIVE: YES
PKTDATA: 0x15ff: CONTEXT STATUS TIME CHANGED SERIAL_NUMBER BUTTONS X Y NORMAL_PRESSURE ORIENTATION
BUTTONS: 1
BUTTONBITS: 3
BTNNAMES: x x
BUTTONMAP: 0
SYSBTNMAP: 1
NPBUTTON: 0
NPBTNMARKS: 0 1
NPRESPONSE:
TPBUTTON: 0
TPBTNMARKS: 28004408 1707348579
TPRESPONSE:
PHYSID: 0x1
CAPABILITIES: 0x5: MULTIMODE INVERT
MODE: 1
device: (5) WACOM Tablet Eraser   axes: 0
Comment 20 Martin Damboldt 2008-04-03 07:59:35 UTC
Just a small hint:
I'm using the Wacom Bamboo together with Gimp since December 2007. Initially it was working fine, no freezes and no bumping as described in this issue. Unfortunatly after some Gimp and GTK updates I was running into the same issue as others described here. Sad but true I was not able yet to figure out which old Gimp and GTK release was the combination which was working fine. But I would swear that an old release was working fine.
Comment 21 RZ 2008-04-05 20:32:28 UTC
Hello

FYI:
dia 0.96 has no obvious problem (but don't need presures etc.)

tried old driver PenTablet_497-6 (recommand by wacon forum) 
with no great sucess.
(Current driver is 505-7)


Comment 22 RZ 2008-04-06 00:26:22 UTC
Gimp 2.4.5 
Windows XP fully patched
Synapatic touch (Notebook)
PS/2 Logitech Wheel Mouse via USB adapther
2 Screens 1024x768 (One via USB2VGA)

drawing with gimp worked fine for several hundert strokes.
Sometimes it freeses, but melted again after approx. 5sec.
Suddenly, while opening the combo box for a new document 
the cusor freezes too. I could open and close
the format list but can't scroll down.
I had enabled "click sound" and the click
still occurs with every touch of the panel.
Somestimes it helps to move the cursor outside (using the mouse)
but after a while (5 minutes) that does not help any more.

The guy in the wacom form states, thatthey don't have any problems
Too he stats that it might be an USB problem or interference between
the mouses...it can't be an USB problem as the pen worked flawlessly outside
and the click is still generated.

Comment 23 Thomas Bleeker 2008-05-09 08:10:30 UTC
Created attachment 110624 [details] [review]
Wintab packet rate bugfix proposal

From http://www.wacomeng.com/devsupport/ibmpc/wacomwindevfaq.html:

"The lcPcktRate field is not functional in the non-Wacom Wintab which shipped with older Wacom tablets. The Wacom Wintab currently doesn't support lcPktRate either. In both Wintabs, lcPktRate is reported as 100, but the tablet will actually be sending data at the highest rate possible for whatever mode in which the tablet is set."

Setting this field to zero seems to solve quirky behaviour of Wacom tablets with GTK apps such as Inkscape and GIMP.
Comment 24 Thomas Bleeker 2008-05-09 08:11:36 UTC
Details for the attachment I just added:

I have the same problem but managed to patch the program so that it works correctly again, at least for me (I haven't tested it yet on other computers).

OS: Vista 32-bit + SP1, English
Tablet: Wacom Grapphire 4, latest drivers installed

My problem was with Inkscape but I tested GIMP and it has the same problem, like veryone describes here, the cursor freezes on certain proximity events.

I looked around in the relevant source file (gdkinput-win32.c) and after some testing I found out the packet rate setting causes the problem:

(lc is the LOGCONTEXT structure)
lc.lcPktRate = 50;

However, the Wacom Windows Developer FAQ (http://www.wacomeng.com/devsupport/ibmpc/wacomwindevfaq.html) states:

"The lcPcktRate field is not functional in the non-Wacom Wintab which shipped with older Wacom tablets. The Wacom Wintab currently doesn't support lcPktRate either. In both Wintabs, lcPktRate is reported as 100, but the tablet will actually be sending data at the highest rate possible for whatever mode in which the tablet is set."

I tried setting this value to just zero and all problems disappeared. Both Inkscape and GIMP work as expected, including pressure and tool switching.

Since I didn't feel like compiling all the necessary libraries again I just binary patched the GDK DLL for Inkscape and GIMP, but I have attached a source code patch for GTK that should produce the same result.

I hope this fix will work on other systems as well, if you want to quickly check if this fix works for Inkscape or GIMP then you can apply the binary patch. For this you need these specific versions (which are the latest at the moment of writing)

Inkscape: 0.46
GIMP: 2.4.5 i686

You will also need a hex editor, I use HxD (http://mh-nexus.de/hxd/), description below is for that tool.

Install as usual, then run HxD (be sure to run it as administrator if you use Vista with UAC and installed in program files!!). For inkscape, in HxD open libgdk-win32-2.0-0.dll (this file should be 639270 bytes). When patching GIMP, open the same file from the bin directory inside the GIMP directory, this version of the DLL should be 617992 bytes.

Menu search, goto (or press alt+g).
Offset: 39030 for Inkscape, 39180 for GIMP
Select 'hex', relative to 'begin' and press OK. 

Your cursor should now be at the hexadecimal offset you've entered, you should see this sequence of bytes:
  
  32 00 00 00 8B 4D 88 89 85 E4 FD FF FF B8 E1 15

Type 00 to overwrite the 32 at the start with 00. It will become red. Save the file, close HxD and try the program again.



Comment 25 Jon Colverson 2008-05-09 13:52:06 UTC
The patch works for me! (patching the source)

Thank you so much for tracking this bug down!
Comment 26 Jose Martins 2008-05-12 07:57:49 UTC
Tried it out, and it works like a charm (Bamboo Fun Small)... Can someone with the required access please make this change in the GTK+ source code repository? As indicated, even Wacom's developer docs say lcPktRate is not functional.

I also think everyone with a tablet will agree that it would be good to see this permanently and officially fixed in the next gimp and inkscape releases. That is my wish anyway.

Thanks everyone :)...
Comment 27 Martin Damboldt 2008-05-12 12:48:29 UTC
Thank you all! The patch works like a charm.
Please commit it into gtk release.

Thanks,
Martin
Comment 28 RZ 2008-05-12 22:58:25 UTC
Very good job! Thank you. 
Hex editing was not dificult and i hope
Windows will not "repair" the now "currupt" dlls from its dll-cache...

It works here with the GIMP flawlessly!
Nice!

In Inkscape the drawing first occurs at the most 
left side of the frame the sheet.
If i draw the pen arround the sheet the resulting square
has approx. quarter the size: lineas have only half the
length to those actually drawn.

When i select "screen" instwad of "window" in the input device 
dialog it works in inkscape too like expected!

In GIMP and inscape the razor end of the pen seems 
not to work as "razor" but like just an other pencil.

 

I wonder why in wacom forum the Wacom developer claimed 
he could reproduce the problem, when it was never supposed
to work and why that problem was not obvious while checking
pen functions in GTK+

Is an gtk++ developer reading here to change that in the next release?
I see this bug still has none assigned
and Priority: is stil "Normal", not "high",
despite a drawing programm not working with a wacom pen is
severe broken and it's not "neglectable". Too there is no "workarround".






 
Comment 29 Tor Lillqvist 2008-05-13 08:49:41 UTC
Yes, there are GTK+ developers reading bugzilla. The Priority and Severity fields are mostly pointless here in GNOME Bugzilla as bug reporters (users) can set them, and of course every bug reporter think *his* bug is the most important ever.

Has anybody checked if this change affects the behaviour of older Wacom tablets? (Yeah, I could do that myself, I have an ArtPadII collecting dust somewhere...)

And what about other manufacturer's tablets? Ones that still provide a Wintab interface, don't know if any such are actually available on the market nowadays, but maybe old ones? Oh well, my feeling has always been that (old) Wacom tablets are the only ones known to work to some extent with GTK+ on Windows, anyway. So if this patch now means that also newer Wacom models work, I don't think there is much risk in committing this.

Patch committed to trunk and gtk-2-12:

2008-05-13  Tor Lillqvist  <tml@novell.com>

	Bug 496958 - Wacom Bamboo Doesn't Function with GTK apps in Win32

	* gdk/win32/gdkinput-win32.c (_gdk_input_wintab_init_check): Set
	the "packet rate" of devices to zero instead of 50. This is
	reported to help significantly with Wacom tablet behaviour in GIMP
	and Inkscape. Patch from Thomas Bleeker.

Will thus be in GTK+ 2.12.10.
Comment 30 RZ 2008-05-13 18:04:43 UTC
Just just tested more exactly Bamboo:

As harder i press as less(!) color ist used!
I would expect the oposit...
The drawing it self is now absolet stable.


Pen setting:
Pinsel
Modus: Normal
Deckkraft: 100%
Pinsel: Calligrafic Bruh
Skalieren: 6,74
[ ] Verblassen
[ ] Zittern
[ ] Steigend
[ ] Farbe aus Verlauf



The "razor" end does not erase but drawn with a always round pen.


At the same time  i have (re-)connected a Medion MD85637 DIN A 4 tablet.
There is no pressure sensity,  worse:
When i once touch the pad i have to liftof 1cm to stop draring.
It looks like that tablte is running un Mouse mode?
Maybe the drivers are missing.





Wacom Virtual HID Driver Wacom 14.02.2007 2.8.0.0
Wacom HID Digitzer Micorsoft 01.07.2001 5.1.2600.2180
Wacom HID Pen <none available>

HID\VID_04B4&PID_FD13\
HID\VID_056A&PID_0065&COL02\
HID\VID_0711&PID_0260&MI_01&COL02\
HID\VID_0711&PID_0260&MI_01&COL03\
HID\VID_172F&PID_0031&COL02\
HID\WACOMVIRTUALHID&COL04\
USB\VID_056A&PID_0065\
USB\VID_0711&PID_0260&MI_00\
USB\VID_0711&PID_0260&MI_01\
USB\VID_172F&PID_0031\

056a:0065 Wacom 
0711:0260 Magic Control Technology Corp
172f:0031










Comment 31 Tor Lillqvist 2008-05-13 21:34:13 UTC
As far as I know there can be only one Wintab device attached to a machine at a time, as the wintab driver is specific to the tablet type. Or am I mistaken? Anyway, are you sure this Medion tablet even provides a Wintab interface? If not, it indeed will work like a mouse only. And in any case, that problem belongs to a separate bug report then.

As for the Bamboo's pressure being "reverse", can this perhaps be tweaked by some setting in the Wacom applet in the Control Panel?
Comment 32 Martin Damboldt 2008-05-14 07:30:41 UTC
(In reply to comment #30)
> Just just tested more exactly Bamboo:
> 
> As harder i press as less(!) color ist used!
> I would expect the oposit...
> 

I can't confirm this. My Bamboo is working fine with the fix mentioned above. Also the pressure sensitivity is working fine. I'm using Gimp 2.4.5 with the patched libgdk-win32-2.0-0.dll as described above. The system is running on Vista SP1 using Wacom Driver 5.05-07_int.

Wacom Virtual HID Driver Wacom 14.02.2007 2.8.0.0
Wacom HID Digitzer Micorsoft 21.06.2006 6.0.6001.18000
Wacom HID Pen 21.06.2006 6.0.6001.18000
Comment 33 Jose Martins 2008-05-14 08:03:30 UTC
RZ: In relation to "The 'razor' end does not erase but drawn with a always round pen." <--- this issue is nothing new, it has been like that forever and is an entirely different issue altogether. It has nothing to do with the fix provided.

In regards to the Midion tablet... did you actually fully test it WITHOUT the patch applied? And then with the patch in place? I don't mean to offend you, but since you mentioned the eraser issue without knowing it was always like this, it makes me wonder whether you truly tested things properly before and after applying the patch before making the post.

As for the reversed pressure detection, this can be caused by a great number of things, make absolutely sure the sensitivity works correctly in other software (photoshop if you have it would be the best). If it is not a global issue, check your gimp preferences carefully to make sure everything is configured correctly there. Lastly, try reversing the patch and testing it again, but since the patch seems to work correctly for everyone else I doubt that is the cause.

Sorry I can't be much help, but we need more information, like, is the Midion issue caused by the patch here or was it always like that, like the eraser issue? Gimp has a reputation for having bad support for non-wacom tablets, so it would not surprise me if it does have issues with your other tablet...

Please double check these things and let us know how it goes.
Comment 34 Tor Lillqvist 2008-05-14 08:35:35 UTC
Guys, please file a separate bug for the Midion issue. (It's fine to add *one* comment here pointing to that bug report once it has been filed, though.)
Comment 35 RZ 2008-05-14 18:44:04 UTC
Yes, id don't know if there is an issue with that tablet.
Anyway to make the report complete:

The Medion MD85637 DIN A 4 tablet is deliverable
with serval names

Often named "Slim tablet"

At least these are the same:
http://www.waltop.com/product.htm
http://www.odys.de/web_lan_de_hmp_1_mp_7_an_X100001_sw_ja.html
http://www.aiptek.eu/index.php?option=com_product&task=view&productid=135&Itemid=223

Comment 36 RZ 2008-05-14 19:09:24 UTC
Is there a "test bed" for (GIMP) tablets?
I currently have the feeling of attempting instrument 
landing without view AND instruments...
So that "this can be caused by a great number of things," can't occure?
(I reseted every single Gimp parameter to "default" in the hope
to reduce the "numer of things". Did not help.
To proof such trival things: "Is there the required interface at all"
Which USB Vendor IDs are involved, which driver/OS version etc.
 

Comment 37 RZ 2008-05-14 19:13:18 UTC
to get the 
Reverse "pressure" problem:

Pen setting:
Pinsel
Modus: Normal
Deckkraft: 100%
Pinsel: Calligrafic Bruh
Skalieren: 6,74
Druckempfindlichkeit:
[ ]Deckkraft  []Härte [ ]Grösse [x]Farbe  
[ ] Verblassen
[ ] Zittern
[ ] Steigend
[ ] Farbe aus Verlauf

IOW:
Only if "Farbe" is selected the "effect" occurs.
I assume that's a PBCK.

Is there a way to simply save entire gimp settings
to make the problem reproducible?
Comment 38 Jose Martins 2008-05-14 19:44:37 UTC
Is there a way to simply save entire gimp settings
to make the problem reproducible? <--- I don't think so... Other than that, can you check what happens with the patch reversed?
Comment 39 Zidy 2008-05-16 19:29:51 UTC
(In reply to comment #37)
> Reverse "pressure" problem:

Sorry for my English, but i think that it is not a bug, but a feature.
If is pen pressure sensitivity set to "color" the pressure changes the color from primary to secondary selected color. Default it is from black to white on white background (and that means that smallest pressure will give you primary - black color), so if you switch the colors (shortcut - x) the "pressure" will be "ok" - just try with different colors than black and white....
Tested on patched/unpatched version and work similar in both.


And before this patch i have described problems with Wacom Graphire 4 XL.
After this "patch" Gimp works perfect without freeze. Driver version 5.08-2

Comment 40 RZ 2008-05-16 22:53:05 UTC
You wrote:
>And before this patch i have described problems with Wacom Graphire 4 XL.
>After this "patch" Gimp works perfect without freeze. Driver version 5.08-2

I would say:
Before that patch i never saw wacom working in gimp/inkscape at all!
After that patch i never again saw that freeze or errorous drawing in GIMP.
IOW:
Previously/without the patch testing had no sense.

I still have problems "drawing with a offset" in inkscape:
Presure seems not to work, but worse:
Once a line is started i can lift off the pen 2..3cm and
the line is still drawn!
 
But that might not _caused_ by that patch, it 
ws previously simple not visible, as it was impossible
for me to use the tab in inkscape at all. 

With the mouse i have the similar effect in inkscape:
First left click: drawing starts (left switch must not be pressed)
Second click: drawing stops.
That make sense in draw with a mouse but not with a tablet.

But the mouse do not behave always this way.
The pen under inkscape always continous drawing 2.3com above the
pad and there seems to be no pressure

Menu: Datei: Eingabe geräte.. says: Input: "No extended input devices."
That's the same GIMP 2 says in Datei:Einstellungen:Eingabegeraete:
So the pressure sensity is disabled to day...
But i see all Wacom HID (Digi,Pen,Virt Hid) and Mouse drivers are loaded
WhatÄs going on?
If i detach the pad from USB, only "Wacom Mouse" becomes gray in
device manager...
Comment 41 Jose Martins 2008-05-18 02:31:11 UTC
RZ, looking at your last post, I would say the patch works perfectly and this bug is fixed then. Please log separate bugs for the other issues you encountered - and log them for the appropriate product (gimp/inkscape/gtk+). This bug was logged because Wacom tablets were completely broken on GTK+ applications... I believe this has now been fixed.

Any other issues, especially ones related to how other applications use this functionality should be logged against the appropriate product and fixed there. By listing all of the existing issues that gimp and inkscape has with tablets, all you're doing is casting doubts over whether this patch can safely be applied in the next release of gtk+ or not.

Reading through the posts here, it seems like there isn't any confirmed negative side-effects caused by applying the patch... I've tested the patch extensively myself, and the bug is fixed, we also have confirmations from several other users so definitely keep the patch applied. Just in case it may cause issues with other Tablets, just add in a comment saying why the rate has been changed to 0...
Comment 42 Grant_M 2008-05-19 04:12:03 UTC
I can also confirm this fix to be a working solution for this gtk bug.

Thank you so much Thomas Bleeker for solving this problem. It is really excellent to be able to use Inkscape & Gimp as they were intended....finally!

Grant Morrison

Windows XP Home sp2

Wacom Graphire4 4X5 driver version 5.08-6

Gimp 2.4.5 i686

Inkscape .46
Comment 43 Stuart Rendall 2008-06-13 14:49:40 UTC
Wow this is really fab! 

Unfortunately, I thought I would wait until release 2.4.6 thinking that the patch would be incorporated (which it wasn't) but it turned out to be really easy to do and my tablet now works superbly.

So, your fix works in GIMP 2.4.6 as well.

Thanks very much.
Comment 44 Frederic Da Vitoria 2008-06-17 14:50:12 UTC
Gimp 2.4.6 / XP SP3: it works almost perfectly. There is a strange latency in some tools: in Heal and especially in Foreground Select. It is visible when doing fast movements. I checked other tools but I didn't see it anywhere else.
Comment 45 Anthony Lim 2008-07-22 04:36:14 UTC
Sorry for adding to the already "resolved problem," I just bought my Bamboo fun today and had the same problem.  I found the fix for Gimp which I use a whole bunch; however, I was wondering if anyone could find a patch for Gimp Portable 2.4.5 from portable apps.  The 'libgdk-win32-2.0-0.dll' seems to be considerably smaller in byte-size and I cannot find the right offset.  Just a quick question because I've use portable up until now.  I have currently converted to the full version for the time being and I adore it!  Thanks Thomas!
Comment 46 Thomas Bleeker 2008-07-22 19:18:43 UTC
The DLL in the portable version is packed with UPX. I suspect the DLL is exactly the same version as with the standard GIMP so try overwriting the DLL with the patched DLL from the standard version. 

Alternatively, download UPX (http://upx.sourceforge.net/download/upx303w.zip), unpack the dll (upx.exe -d libgdk-win32-2.0-0.dll) and you will find the bytes to be patched at exactly the original offset (39180 hex). You can compress the DLL again as well if you wish.
Comment 47 Han 2008-08-06 23:42:55 UTC
Thanks for the method to patch this (Thomas Bleeker)! However, my computer isn't giving me permission to re-write the file. I can get everything else done, apart from replace the 32 with 00. Does anyone have a solution?- It's a little annoying when you finally get a tablet and you can't use it!
Thanks again!
Comment 48 Thomas Bleeker 2008-08-07 08:54:39 UTC
Are you running Vista with UAC by any chance? If so make sure that you run HxD with administrative rights (right click executable, run as administrator). If that doesn't help make sure you don't have any software running that uses GTK.