I decided to change the severity of this bug because playing with the tablet and
Gimp furthur, I actually got it to a point where nothing I would do would make
the Gimp turn off the paint tool.  I had to kill the Gimp from a shell as I
could not get into the menus to do anything because it would not come out of
draw mode.  This makes using a the tablet with the Gimp very frustrating and
sometimes impossible.

what version of GTK+ do you use? Could you test with 
  "xinput test -proximity <input device name>"
if there are proximity in *and* out events?

ok. GTK+ version is 2.2.4-10mdk from RPM.

xinput data:
---------------------------------------------------------
[root@localhost derbaff]# xinput test -proximity stylus
proximity in
motion a[0]=0 a[1]=0 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=-24 a[1]=-16 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=-40 a[1]=14 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=-52 a[1]=62 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=-50 a[1]=110 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=58 a[1]=200 a[2]=351 a[3]=1 a[4]=1 a[5]=0
motion a[0]=196 a[1]=325 a[2]=376 a[3]=1 a[4]=1 a[5]=0
motion a[0]=352 a[1]=542 a[2]=330 a[3]=1 a[4]=1 a[5]=0
motion a[0]=533 a[1]=775 a[2]=311 a[3]=1 a[4]=1 a[5]=0
motion a[0]=738 a[1]=1000 a[2]=326 a[3]=1 a[4]=1 a[5]=0
motion a[0]=996 a[1]=1240 a[2]=345 a[3]=1 a[4]=1 a[5]=0
motion a[0]=1319 a[1]=1470 a[2]=370 a[3]=1 a[4]=1 a[5]=0
motion a[0]=1688 a[1]=1717 a[2]=389 a[3]=1 a[4]=1 a[5]=0
motion a[0]=2127 a[1]=1975 a[2]=412 a[3]=1 a[4]=1 a[5]=0
motion a[0]=2655 a[1]=2259 a[2]=432 a[3]=1 a[4]=1 a[5]=0
motion a[0]=3308 a[1]=2610 a[2]=447 a[3]=1 a[4]=1 a[5]=0
motion a[0]=4058 a[1]=2938 a[2]=459 a[3]=1 a[4]=1 a[5]=0
motion a[0]=4877 a[1]=3244 a[2]=465 a[3]=1 a[4]=1 a[5]=0
motion a[0]=5715 a[1]=3501 a[2]=466 a[3]=1 a[4]=1 a[5]=0
motion a[0]=6487 a[1]=3657 a[2]=462 a[3]=1 a[4]=1 a[5]=0
motion a[0]=7153 a[1]=3708 a[2]=421 a[3]=1 a[4]=1 a[5]=0
motion a[0]=7676 a[1]=3626 a[2]=188 a[3]=1 a[4]=1 a[5]=0
motion a[0]=8036 a[1]=3477 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=8278 a[1]=3414 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=8511 a[1]=3459 a[2]=1 a[3]=1 a[4]=1 a[5]=0
proximity out
proximity in
motion a[0]=3018 a[1]=940 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=3088 a[1]=990 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=3193 a[1]=1046 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=3280 a[1]=1131 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=3382 a[1]=1221 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=3488 a[1]=1335 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=3603 a[1]=1420 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=3707 a[1]=1503 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=3841 a[1]=1602 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=3974 a[1]=1717 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=4111 a[1]=1856 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=4272 a[1]=2030 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=4459 a[1]=2212 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=4659 a[1]=2446 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=4884 a[1]=2675 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=5096 a[1]=2869 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=5348 a[1]=3040 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=5574 a[1]=3174 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=5800 a[1]=3252 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=6024 a[1]=3348 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=6272 a[1]=3441 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=6530 a[1]=3519 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=6821 a[1]=3615 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=7205 a[1]=3688 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=7672 a[1]=3762 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=8240 a[1]=3813 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=8894 a[1]=3870 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=9497 a[1]=3889 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=10084 a[1]=3902 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=10549 a[1]=3902 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=10559 a[1]=3825 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=10595 a[1]=3687 a[2]=1 a[3]=1 a[4]=1 a[5]=0
motion a[0]=10621 a[1]=3428 a[2]=1 a[3]=1 a[4]=1 a[5]=0
proximity out
----------------------------------------------------------
It does show "proximity in/out" as you can see.
Also, there are two blocks of data bounded by the proxmity tags.
For the first block of data I pressed the pen to the tablet and swept it across.
For the second block I only hovered over the tablet.

Hope this helps.

Since this bug is almost certainly a problem in GTK+/GDK or in your driver, you
should try if upgrading to GTK+-2.4.3 solves it. There is nothing we can do
about it in GIMP. It seems to work for other people so we have to assume that
GIMP is doing the right thing here.

Setting to NEEDINFO until there's feedback if the problem persists after a GTK+
update. Will reassign it to GTK+ then.

I updated GTK+ and the problem is unchanged.  I can do other desktop functions
such as clicking and dragging icons with the pen with no difficulty, although I
do use KDE, not Gnome.  However, I think that may rule out the issue being the
driver somewhat.  What other information can I proved that will be helpful?

I don't really have an clear idea of what the source of this problem is, but the
pressure field in your data (a[2]) is 1 when there is no pressure, when it
should be 0. This probably doesn't affect most GUI widgets because they don't
use xinput events and there would be a click threshold somewhat higher than 1 in
that case. This may yet be a driver issue - however, I think it's possible that
this is a physical problem with your stylus since the problem seems to have
gotten worse without any software changes; I had a similar problem at one point
where the nib was getting stuck inside the stylus after I applied pressure to
it. The problem went away after I pulled out the nib and put it back in gently.
You might want to try replacing your nib or test with another stylus if you have
access to one.

Marking this NEEDINFO until the reporter responds.

We will have to close this report as INCOMPLETE unless the bug reporter can
provide the info we asked for.

Closing as INCOMPLETE due to lack of response.

Gentoo Linux, AMD64 (occurs both in i386 & x64_64)  
Gimp versions: 2.2.0 & 2.2.3 
GTK version 2.4.13-r1  
   
Problem still exists:  
Somehow the cursor gets stuck for lack of a better word. Gimp doesn't actively  
draw with it, but what it does do, is lock it from accessing anything else.  
(Menus, other apps) And if you do put the stylus back down, it will draw a line 
as if you had drawn a perfectly straight line, from the old pressure setting, 
to the new one.  
 
What breaks it 'out' that I've discovered so far: Killing gimp SIGTERM or 
SIGKILL, Closing gimp via the keyboard, Pulling up a menu in the gimp. I cannot 
switch to another window, using shortcuts.  (Alt-Tab, at least in Kwin, haven't 
tried others, If need be I can try it in Gnome, or possibly others.) I can get 
it to stop after a stroke if I hit say Alt-F Esc after each stroke. 
 
This essentially makes gimp useless for any tablet work at all.  
  
The following was from me, putting the cursor down, then letting it up. Unlike 
the above, there is no problem with a[2] being non-zero. Then 
<snipped>   
motion a[0]=6171 a[1]=223 a[2]=0 a[3]=0 a[4]=0 a[5]=0   
motion a[0]=6171 a[1]=223 a[2]=0 a[3]=0 a[4]=0 a[5]=0   
motion a[0]=6166 a[1]=223 a[2]=94 a[3]=0 a[4]=0 a[5]=0   
button press   1 a[0]=6166 a[1]=223 a[2]=94 a[3]=0 a[4]=0 a[5]=0   
motion a[0]=6166 a[1]=218 a[2]=101 a[3]=0 a[4]=0 a[5]=0   
motion a[0]=6166 a[1]=218 a[2]=122 a[3]=0 a[4]=0 a[5]=0   
motion a[0]=6166 a[1]=218 a[2]=137 a[3]=0 a[4]=0 a[5]=0   
motion a[0]=6166 a[1]=213 a[2]=152 a[3]=0 a[4]=0 a[5]=0   
motion a[0]=6166 a[1]=213 a[2]=164 a[3]=0 a[4]=0 a[5]=0   
motion a[0]=6166 a[1]=213 a[2]=170 a[3]=0 a[4]=0 a[5]=0   
motion a[0]=6166 a[1]=208 a[2]=172 a[3]=0 a[4]=0 a[5]=0   
motion a[0]=6166 a[1]=208 a[2]=173 a[3]=0 a[4]=0 a[5]=0   
motion a[0]=6166 a[1]=208 a[2]=172 a[3]=0 a[4]=0 a[5]=0   
motion a[0]=6161 a[1]=208 a[2]=174 a[3]=0 a[4]=0 a[5]=0   
motion a[0]=6161 a[1]=208 a[2]=170 a[3]=0 a[4]=0 a[5]=0   
motion a[0]=6154 a[1]=208 a[2]=148 a[3]=0 a[4]=0 a[5]=0   
motion a[0]=6148 a[1]=208 a[2]=109 a[3]=0 a[4]=0 a[5]=0   
motion a[0]=6148 a[1]=208 a[2]=23 a[3]=0 a[4]=0 a[5]=0   
motion a[0]=6138 a[1]=214 a[2]=0 a[3]=0 a[4]=0 a[5]=0   
motion a[0]=6133 a[1]=214 a[2]=0 a[3]=0 a[4]=0 a[5]=0   
motion a[0]=6133 a[1]=221 a[2]=0 a[3]=0 a[4]=0 a[5]=0   
motion a[0]=6133 a[1]=221 a[2]=0 a[3]=0 a[4]=0 a[5]=0   
motion a[0]=6133 a[1]=231 a[2]=0 a[3]=0 a[4]=0 a[5]=0   
motion a[0]=6133 a[1]=240 a[2]=0 a[3]=0 a[4]=0 a[5]=0   
<sniped>   
(moved around, only values that change are a[0] and a[1]) 
motion a[0]=6281 a[1]=505 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=6281 a[1]=505 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=6281 a[1]=505 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=6281 a[1]=505 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=6281 a[1]=513 a[2]=60 a[3]=0 a[4]=0 a[5]=0 
button press   1 a[0]=6281 a[1]=513 a[2]=60 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=6281 a[1]=513 a[2]=82 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=6281 a[1]=520 a[2]=109 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=6281 a[1]=520 a[2]=137 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=6281 a[1]=520 a[2]=157 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=6281 a[1]=520 a[2]=168 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=6281 a[1]=520 a[2]=171 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=6281 a[1]=520 a[2]=173 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=6281 a[1]=520 a[2]=169 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=6281 a[1]=520 a[2]=145 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=6281 a[1]=520 a[2]=92 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=6281 a[1]=520 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=6281 a[1]=520 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=6273 a[1]=520 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
<snipped> 
The button press results in a line between the last point and the new one.  

Re-opening this bug because additional info has been provided.

However, I have been using an old serial wacom tablet for quite a while and I
have never experienced similar problems.  Both the reporter (in comment #5)
and James L (in comment #10) mention that they are using KDE.  Could it be
that Kwin is somehow stealing some xinput events and causing these problems?

Setting back to NEEDINFO until someone who is affected by this problem can
report if switching from KDE to another environment (GNOME, XFCE, ROX, ...)
makes any difference.

I've the same probleme with an USB wacom volito
on gnom-2.4 with glib/gtk+ 2.6.1.
I use linuxwacom-0.6.6 with linux-2.6.10 and xorg 6.8.1 (and tryed with xorg
6.8.1.904 (6.8.2 rc))

I tested the tablet with xidump (given with linuxwacom), all the events are well
given by mouse, only really few time (less than 1/50...) the button 1
(corresponding to pressure button, seem to don't release the button. In gimp I
see this probleme very often, and only after a lot of press/release, I obtain
some times to get out of bug.

There is also another bug linked to tablet, typing ctrl-z to undo drawing,
hazardous backround color square box are drawn, sometimes old strokes and
blanking the picture (by ctrl+A + ctrl+.) blank screen well, but drawing on this
 blanked drawing display will draw as baground near the brush old drawing (like
a bug in mask operations???).

Tried to use my tablet with inkscape (not sure that it use release event), to
build shapes and wathever, without any bugs.

After yesterday upgrade of glib/gtk 2.6.2 (from 2.6.1), the pressure isn't
managed at all. like the device doesn't exist, but everything run well, no
drawing bug, no locking interface bug.

I will downgrade to search on gimp and try more tests this evening.

If you upgrade to glib/gtk+ 2.6.2 and build the libraries yourself from sources,
make sure that XInput support is enabled (configure option --with-xinput=yes).
Otherwise, the extended device support (pressure, tilt, etc.) will not work.

Checked, problem occurs with GNOME version 2.8.1 (specifically gentoo's  
2.8.0-r1)   
GTK version is 2.6.2 (using --with-xinput of course, that's not really the 
problem, as pressure sensitivity works.) 
  
(I only tested with 2.2.3 this time.)  
 
 

OK, I really forgotten the xinput option...

Everything seem to be OK, but this could be due to hazardous behaviour of this
bug???

I tested it with gimp-2.2.3 & gimp-cvs from yesterday afternoon.

It looks like we have three different problems here:
1) The reporter (Eric Eubank) shows in comment #3 that the pressure of his
   tablet stays at 1 instead of 0 after releasing the pen.  This could be a
   physical problem with the pen, as suggested in comment #6.  There is not
   much that we can do about this.
2) James L in comment #10 and comment #15 reports a different problem: the
   pressure works and goes back to 0, but it gets "stuck" in the GIMP.
3) popolon in comment #13 and comment #16 had a problem that was apparently
   solved by upgrading GTK+.

So the remaining problem is (2), reported by James L.  I would like to know:
- the exact model of the tablet used
- the version of the driver used
- whether there is any KVM switch or other device used for the keyboard and
  mouse (I have seen once a tablet that appeared to be stuck, but the
  problem was actually caused by a KVM switch that caused some problems with
  the mouse events, which in turn caused interferences with the tablet)

This morning, I tested again, and everything come back bad.
I killed gimp via text console (ctrl+alt+f1), come back in X, tested xidump
launched again gimp. No more problems, everything works well.
Could this be related with some kind of initialisation?

To help on test:
* Do you tried with xidump (bundled with linuxwacom), which behavior for the
stylus with this software? this is an ncurse interface, with progress bar for
pressure, flags for buttons and informations for position.

xinput output, in good bahavior state:
motion a[0]=1269 a[1]=139 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=139 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=133 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=133 a[2]=1 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=133 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=128 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=128 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=128 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=128 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=128 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=128 a[2]=1 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=128 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=128 a[2]=1 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=128 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=128 a[2]=64 a[3]=0 a[4]=0 a[5]=0 
button press   1 a[0]=1269 a[1]=128 a[2]=64 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=128 a[2]=158 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=128 a[2]=227 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=128 a[2]=278 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=128 a[2]=316 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1264 a[1]=128 a[2]=359 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1264 a[1]=128 a[2]=366 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1264 a[1]=123 a[2]=382 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1264 a[1]=123 a[2]=384 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1264 a[1]=123 a[2]=402 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1264 a[1]=123 a[2]=404 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1264 a[1]=123 a[2]=410 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1264 a[1]=123 a[2]=421 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1264 a[1]=123 a[2]=422 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1264 a[1]=123 a[2]=352 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1264 a[1]=123 a[2]=164 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1264 a[1]=123 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
button release 1 a[0]=1264 a[1]=123 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1264 a[1]=123 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1264 a[1]=123 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1264 a[1]=128 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=128 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1276 a[1]=128 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1282 a[1]=128 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1282 a[1]=128 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1290 a[1]=128 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1290 a[1]=128 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1290 a[1]=138 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1281 a[1]=146 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1274 a[1]=156 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1266 a[1]=170 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1258 a[1]=182 a[2]=1 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1249 a[1]=193 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1238 a[1]=203 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1231 a[1]=211 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1221 a[1]=217 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1214 a[1]=223 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1208 a[1]=228 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1202 a[1]=236 a[2]=1 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1196 a[1]=248 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1190 a[1]=263 a[2]=1 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1182 a[1]=279 a[2]=0 a[3]=0 a[4]=0 a[5]=0 

The  release event is welll given, the pressure button oscillate betwen 5 and 0,
even if the stylus don't touch the tablet. In the case of volito, the a[3]=64
when the button is pressed, 0 else (not pressed, already pressed, during depressing)

Tested again this morning, before launchng gimp, the button press/button release
are rarely detected in xinput,

most of the time:

motion a[0]=3671 a[1]=1858 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3651 a[1]=1868 a[2]=1 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3633 a[1]=1875 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3615 a[1]=1881 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3598 a[1]=1889 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3584 a[1]=1889 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3572 a[1]=1898 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3562 a[1]=1903 a[2]=1 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3557 a[1]=1903 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3557 a[1]=1909 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3557 a[1]=1918 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3562 a[1]=1918 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3569 a[1]=1923 a[2]=142 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3576 a[1]=1928 a[2]=240 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3576 a[1]=1928 a[2]=310 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3571 a[1]=1928 a[2]=380 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3562 a[1]=1928 a[2]=450 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3551 a[1]=1928 a[2]=500 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3541 a[1]=1928 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3528 a[1]=1928 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3514 a[1]=1928 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3501 a[1]=1928 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3490 a[1]=1928 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3483 a[1]=1928 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3483 a[1]=1928 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3483 a[1]=1923 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3477 a[1]=1923 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3477 a[1]=1923 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3477 a[1]=1917 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3477 a[1]=1917 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3477 a[1]=1917 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3472 a[1]=1917 a[2]=448 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3472 a[1]=1912 a[2]=72 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3472 a[1]=1912 a[2]=4 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3472 a[1]=1907 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3477 a[1]=1907 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3477 a[1]=1907 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3477 a[1]=1918 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3470 a[1]=1929 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3464 a[1]=1943 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
proximity out a[0]=3464 a[1]=1943 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
proximity in  a[0]=3464 a[1]=1943 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3479 a[1]=1995 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3476 a[1]=1994 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3478 a[1]=1994 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3478 a[1]=1994 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3478 a[1]=2000 a[2]=4 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3478 a[1]=2006 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3484 a[1]=2015 a[2]=5 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3484 a[1]=2022 a[2]=353 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3484 a[1]=2029 a[2]=500 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3474 a[1]=2029 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3462 a[1]=2034 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3452 a[1]=2034 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3442 a[1]=2034 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3435 a[1]=2034 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3426 a[1]=2034 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3419 a[1]=2034 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3419 a[1]=2027 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3411 a[1]=2027 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3411 a[1]=2027 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3411 a[1]=2022 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3411 a[1]=2022 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=3411 a[1]=2022 a[2]=511 a[3]=0 a[4]=0 a[5]=0 

Some time, I've only button press 1 signal, without release signal:

motion a[0]=356 a[1]=2705 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=356 a[1]=2705 a[2]=1 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=365 a[1]=2697 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=379 a[1]=2691 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=395 a[1]=2691 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=411 a[1]=2691 a[2]=31 a[3]=0 a[4]=0 a[5]=0 
button press   1 a[0]=411 a[1]=2691 a[2]=31 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=411 a[1]=2716 a[2]=366 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=399 a[1]=2747 a[2]=495 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=374 a[1]=2786 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=344 a[1]=2821 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=325 a[1]=2848 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=309 a[1]=2867 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=301 a[1]=2878 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=296 a[1]=2883 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=296 a[1]=2883 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=307 a[1]=2883 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=315 a[1]=2883 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=325 a[1]=2883 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=332 a[1]=2883 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=332 a[1]=2877 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=332 a[1]=2877 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=332 a[1]=2866 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=332 a[1]=2855 a[2]=511 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=332 a[1]=2835 a[2]=327 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=332 a[1]=2812 a[2]=19 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=327 a[1]=2796 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=327 a[1]=2783 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=321 a[1]=2783 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=316 a[1]=2783 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=310 a[1]=2783 a[2]=0 a[3]=0 a[4]=0 a[5]=0 



I tried to escape the problem with alt+F + esc, I get out of stick bug, but the
xinput stdout, is the same, and if I draw again in gimp, I've the same bug.

If when I'm stick in gimp, I go to console, kill gimp, everything goes right I
can draw with no more problems, and xinput receive button press/release:

motion a[0]=4704 a[1]=3682 a[2]=1 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=4704 a[1]=3682 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=4704 a[1]=3675 a[2]=2 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=4704 a[1]=3675 a[2]=10 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=4704 a[1]=3675 a[2]=68 a[3]=0 a[4]=0 a[5]=0 
button press   1 a[0]=4704 a[1]=3675 a[2]=68 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=4704 a[1]=3675 a[2]=137 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=4704 a[1]=3669 a[2]=216 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=4704 a[1]=3669 a[2]=277 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=4704 a[1]=3669 a[2]=318 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=4704 a[1]=3669 a[2]=369 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=4704 a[1]=3669 a[2]=408 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=4704 a[1]=3669 a[2]=435 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=4704 a[1]=3669 a[2]=459 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=4704 a[1]=3669 a[2]=470 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=4704 a[1]=3669 a[2]=480 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=4704 a[1]=3669 a[2]=444 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=4704 a[1]=3669 a[2]=262 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=4704 a[1]=3669 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
button release 1 a[0]=4704 a[1]=3669 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=4709 a[1]=3664 a[2]=1 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=4709 a[1]=3664 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=4709 a[1]=3664 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=4709 a[1]=3664 a[2]=0 a[3]=0 a[4]=0 a[5]=0 

This look like the configuration become good only after killing gimp... I will
try to do more test this evening or tomorrow morning.

This morning, I tested again, and everything come back bad.
I killed gimp via text console (ctrl+alt+f1), come back in X, tested xidump
launched again gimp. No more problems, everything works well.
Could this be related with some kind of initialisation?

To help on test:
* Do you tried with xidump (bundled with linuxwacom), which behavior for the
stylus with this software? this is an ncurse interface, with progress bar for
pressure, flags for buttons and informations for position.

xinput output, in good bahavior state:
motion a[0]=1269 a[1]=139 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=139 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=133 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=133 a[2]=1 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=133 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=128 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=128 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=128 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=128 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=128 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=128 a[2]=1 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=128 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=128 a[2]=1 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=128 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=128 a[2]=64 a[3]=0 a[4]=0 a[5]=0 
button press   1 a[0]=1269 a[1]=128 a[2]=64 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=128 a[2]=158 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=128 a[2]=227 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=128 a[2]=278 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=128 a[2]=316 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1264 a[1]=128 a[2]=359 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1264 a[1]=128 a[2]=366 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1264 a[1]=123 a[2]=382 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1264 a[1]=123 a[2]=384 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1264 a[1]=123 a[2]=402 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1264 a[1]=123 a[2]=404 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1264 a[1]=123 a[2]=410 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1264 a[1]=123 a[2]=421 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1264 a[1]=123 a[2]=422 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1264 a[1]=123 a[2]=352 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1264 a[1]=123 a[2]=164 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1264 a[1]=123 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
button release 1 a[0]=1264 a[1]=123 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1264 a[1]=123 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1264 a[1]=123 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1264 a[1]=128 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1269 a[1]=128 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1276 a[1]=128 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1282 a[1]=128 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1282 a[1]=128 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1290 a[1]=128 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1290 a[1]=128 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1290 a[1]=138 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1281 a[1]=146 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1274 a[1]=156 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1266 a[1]=170 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1258 a[1]=182 a[2]=1 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1249 a[1]=193 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1238 a[1]=203 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1231 a[1]=211 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1221 a[1]=217 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1214 a[1]=223 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1208 a[1]=228 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1202 a[1]=236 a[2]=1 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1196 a[1]=248 a[2]=0 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1190 a[1]=263 a[2]=1 a[3]=0 a[4]=0 a[5]=0 
motion a[0]=1182 a[1]=279 a[2]=0 a[3]=0 a[4]=0 a[5]=0 

The  release event is welll given, the pressure button oscillate betwen 5 and 0,
even if the stylus don't touch the tablet. In the case of volito, the a[3]=64
when the button is pressed, 0 else (not pressed, already pressed, during depressing)

I used gimp-cvs from february 06, 2005, to obtain this.

It looks like a bug in driver or xinput, that gimp and/or gtk could help to resolve.

Sorry, buzilla said me that I will overwrite changes I copy/past a part and have
got that????
I only want to said I used gimp-cvs from february 06, 2005, to obtain this.

OK, so the conclusion from both James L and popolon is that your tablet driver
generates a button press event but sometimes "forgets" to generate the button
release event.  As a result, the GIMP becomes unusable.  Also, this event can
also be lost during a pointer grab, which causes the whole X session to be
"locked" (at least the symptoms that you described look very much like some X
pointer grab problem).

I don't think that the GIMP can do much about it, because this is almost
certainly a problem in the tablet driver.  I will re-assign this to GTK+
because this is the only place where a workaround could be implemented.

Note: this seems to be related to bug #143460, which mentions that the wacom
tablet driver can discard packets to get the specified packet rate.  However,
bug #143460 is for Windows so I don't know if this one should be marked as
duplicate.

As I signaled in: 
http://bugzilla.gnome.org/show_bug.cgi?id=145108#c19
I've a mean to resolve the problem in my environement by killing gimp in a
special state. There is certainly something that is done by gtk/gdk at this
step, that is missing in the driver initialisation.

I don't know at all how to invest more in this direction.

If someone, know simple mean to trace the behavior of gtk/xinput it could
resolve the bug or some parts of the bug.

I done more tests to understand what is blocking/deblocking in this situation.

Killing gimp stable (2.2.3) or cvs do the same thing, as it's certainly gdk that
give the signal, ca finish the initialisation of the driver, and unlock cursor.

If gimp is killed out of the 'stick' state, nothing happen, the driver don't
give press/release signal (at least for the xinput-1.2 software), only a kill
during 'stick' give a good state to driver.

If the driver is in good state (give the pres/release signal), and X11 is stoped
then started again, the situation becom again bad, redo the same process of
sticking in gimp, then killing gimp, unblock again definitivly the situation.

I've a Wacom Volito and experienced the same problem with Gimp. I had some  
problems to get Gimp recognize the pressure I'm using while drawing with the  
pen. But when Gimp finally recognized the pressure I often experienced that  
the pen is sticked to the drawing panel of Gimp. Often it helps to click  
outside the panel for some time (up to two minutes!) but sometimes I've to  
kill Gimp from the shell (Alt+F1).  
  
I'm using:  
Gimp 2.2.4-1 (Debian)  
Wacom Volito USB  
Linux 2.6.11rc3  
linuxwacom 0.6.6  
X.org 6.8.1.99  
  
And I'm also using KDE (3.3.2) like others reporting this bug.  
  
Thanks for any advice,  
Johannes  

I just tried drawing with "gsumi" a bit and there I did not experience the 
sticking to the drawing panel. I think this rules out the driver bug. Is it 
possible that I made a fault configuring my pen in Gimp? 

I made some new test, the result looks like a wacom X11 driver bug.
comparing xidump (X11 input event analysis), with wacdump (direct kernel driver
device analysis), by launching the two softwares in // in two xterm, and see
than the button wasn't released only in xidump:

http://popolon.free.fr/problem_driver_X11.png

(reported to linuxwacom project m.l.)

I find a method to use volito until this bug is resolved:

Launch wacomcpl (wacom control panel, distributed with linuxwacom);
 In [tool buttons] options:
button 1-> ignore
button 2-> ignore
button 3-> Left

Then for use it with gimp:
click on side button then press pen on tablet go to drawing mode
rise pen, then click again on side button, release drawing mode.

I then have only one button, but the control is perfect, no hazardous behaviour,
and strangly, gimp ink tool works well, where it was really buggy by using
pressure button as press/release signal in gimp:

http://popolon.free.fr/Precision_ink.png
(in black buggy ink behavior linked to linuxwacom X11 driver bug).

as reported here:
http://bugzilla.gnome.org/show_bug.cgi?id=164272

I have to agree, it does seem to be a Wacom driver bug.   I wouldn't recommend
that the person that wasn't seeing a pressure of 0 go and take apart their
stylus, as the pressure on my Wacom Graphire3 doesn't go to 0 either.   The
wacdump shows "Touch Down" events that are perfectly in sync with the stylus,
however xidump will often get "Stuck" in the down position.

So - its a linuxwacom bug, and I don't know if GTK can work around it.   Has
this been reported to linuxwacom devels?   I'm using 0.6.6 now of linuxwacom and
will go check their bug database.

Please see linuxwacom bug 1166721 here:
http://sourceforge.net/tracker/index.php?func=detail&aid=1166721&group_id=69596&atid=525124

I find the solution after the help of Freon on #inkscape IRC channel.

I think that's the same in most (if not all cases) :
if you have a ps2 mouse don't use psaux devices (caractere, major 10, minor 1):
mknod /dev/psaux c 10 1

use the mouseX device printed in /proc/bus/input/devices

for mouse0:
mknod /dev/mouse0 c 13 32
mouse1 :
mknod /dev/mouse1 c 13 33
mouse2 :
mknod /dev/mouse2 c 13 34
etc...
This resolved the bug in my case

The manual was not enough clear for my little empty head :( :

 http://linuxwacom.sourceforge.net/index.php/howto/mouse1

*** Bug 331849 has been marked as a duplicate of this bug. ***

closing old bugs