GNOME Bugzilla – Bug 496958
Wacom Bamboo doesn't function with GTK apps in Win32
Last modified: 2008-08-07 08:54:39 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.
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.
*** Bug 503445 has been marked as a duplicate of this bug. ***
UPDATE: Problem persists on version 2.12.
*** Bug 511104 has been marked as a duplicate of this bug. ***
> 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.
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. ***
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.
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.
My Windows Vista with Wacom Bamboo Fun drivers installed looks like TabletPC Edition.
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
*** Bug 504628 has been marked as a duplicate of this bug. ***
Maybe someone could ask Wacom to explain the "unusual pointer mapping" a bit further?
(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...
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.
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.
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.
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.
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.
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
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.
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)
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.
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.
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.
The patch works for me! (patching the source) Thank you so much for tracking this bug down!
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 :)...
Thank you all! The patch works like a charm. Please commit it into gtk release. Thanks, Martin
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".
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.
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
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?
(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
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.
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.)
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
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.
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?
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?
(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
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...
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...
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
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.
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.
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!
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.
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!
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.