GNOME Bugzilla – Bug 83779
Wacom in window mode, crash in ink_pen_ellipse
Last modified: 2003-12-30 23:46:08 UTC
I have a new Wacom Graphire 2 (usb) that I just got working. The three wacom devices are using Absolute coordinates in XF86Config-4 (because the howtos all recommend that setting). If I set all three devices (stylus, eraser and mouse) to Screen mode, then stylus and eraser work (mouse has some problems, maybe contending with the PS2 mouse, but I'll track those down some other time). But since my screen is big and my window may not fill it, I end up having to draw in a tiny postage-stamp area. I'd prefer to use Window mode and have the full area of my tablet correspond to the image window (that is what it's for, right?) If I set any of the three devices to Window mode, and set the stylus drawing tool to the ink pen, then as soon as I touch stylus to tablet, gimp crashes, in ink_pen_ellipse, line 786 of ink.c (the line where it's calling ink_options->function()). It turns out that x_center is nan, though y_center looks more reasonable. We got here via ink_button_press, and it looks like that nan X coordinate came from gdisplay_untransform_coords_f (gdisp, bevent->x, bevent->y, &x, &y, TRUE); I haven't traced it any further than that yet -- had trouble debugging because of the server grab (I have to debug from another machine and my laptop batteries ran out.) Looks like maybe I can just comment out the grabs in ink_button_press if I want to debug this more easily. Let me know if you need more details or further tracing. I also checked 1.3.7, but it looks like 1.3 doesn't handle tablets yet? It has Device Status but doesn't see anything but core pointer, and it doesn't have the Input Devices dialog. Or has that just moved somewhere else?
Oh, good: commenting out those gdk_pointer_grab calls does make it possible to debug on the same machine. Here's the actual gdb stack trace:
+ Trace 23137
*** Bug 83780 has been marked as a duplicate of this bug. ***
*** Bug 83778 has been marked as a duplicate of this bug. ***
I haven't had a chance to look at this but I wanted to pull my Wacom out of the dust this weekend anyway... About the missing tablet support in GIMP-1.3.x: You probably didn't compile GTK+-2.0 with xinput support. As with GTK+-1.2 this has to be explicitely enabled at configure time. Most people don't know since most distributions ship with gtk+ binaries that have xinput enabled, but it's not the default out-of-the-box configuration. The Input Devices dialog in GIMP-1.3 moved to the Preferences Dialog. BTW: Opening three identical bug-reports wasn't really necessary, was it?
This looks very much like a bug in the Wacom driver. The Graphire USB driver is still experimental and I'd say it's delivering out-of-range values.
Sorry about the extra reports. I hit submit on the bug, waited about 7 minutes, no response, finally gave up and clicked stop and hit submit again. That accounts for two, don't know where the third came from. My gtk2 is from rpm, gtk2{,-devel}-2.0.0-2.i386.rpm from RPMfind ("GnomeHide"), but I didn't know to look in the preferences dialog. I should probably update to a newer gtk2 anyway. I have no problem believing there's a bug in the wacom driver (though gimp could guard against the crash by checking its arguments, if that's not too great a performance hit). I'll experiment and see if the input device is actually sending different numbers when gimp is in window mode vs when it's in screen mode (I thought the wacom driver just sent absolute coordinates, and screen vs window just controlled how gimp translated those coordinates to window space?) Sorry, I'm new to this wacom stuff so I'm not clear yet how things are supposed to work.
Sorry, I can not reproduce this running GIMP-1.2.4-pre2 using a serial Wacom Intuos tablet. Looks a lot like a bug in the Wacom driver. Could you perhaps check if a newer version of the driver is available and report back if the problem still persists?
Still happens with the wacom driver in 2.4.20 and 1.2.4-pre2. I agree that the real bug in likely in the usb wacom driver -- it seems to be sending bogus coordinates. OTOH, crashing is probably not the best response to getting bad coordinates, and protecting against the crash might be a good idea for gimp. There are lots of people using the wacom driver and I've seen this problem reported on the gimp mailing lists several times. Perhaps when the blob is created? In 1.2.4-pre2, commenting out the gdk_pointer_grab and gtk_grab_add calls in ink.c don't actually stop the grab, so debugging is a lot harder now. Any suggestions on what new grab call I might be missing? I was curious why I'd be getting into ink.c at all when in my testing, I'm setting the eraser to window mode and setting it to the smudge tool (is smudge also handled by ink.c?)
If you want to get a stack trace from the crash even while there is a pointer grab, you can easily do that by starting the GIMP with the option "--enable-stack-trace always".
Should be fixed in CVS now, please test and report back: 2003-02-03 Michael Natterer <mitch@gimp.org> * app/display/gimpdisplayshell-callbacks.c: fixed the "TAB toggles dialogs" feature. (gimp_display_shell_get_event_coords,device_coords): CLAMP() all extended axes to be safe against crappy XInput drivers and provide default values for not existing axes.
Hi Sven, Are you using the XInput driver supplied with XFree86? If so, can you test it with a newer version from http://linuxwacom.sourceforge.net (either the stable or the developement version) and see if it still works for you? I'm trying to track down where the bug was introduced. Thanks! I don't think the bug is in the driver though - the values of both the X and Y axes are correctly sent, but GIMP cannot receive "both" of them correctly. If I disable either axis in the device dialog, the other one works correctly, and GIMP doesn't crash. This is really weird. I have skimmed through disp_callbacks.c and the problem doesn't seem to be there either. Just guessing here, but it might be possible that the problem is in GTK+? Also, the abovementioned patch doesn't seem to fix the crash. I tried the current CVS version with an USB Intuos2 and it still crashes...:/
Changed target milestone of several bugs to 2.0 - these are not features, and don't look to me like blockers for a pre-release, but they have to be addressed before 2.0. Dave.
Can this bug be reproduced with current CVS HEAD and gtk+-2.2.2 or above?
NaN in mouse coordinates looks suspiciously similar to bug #123546 and I highly suspect that using the patch provided with that bug report, or the very newest tablet drivers, that this bug is fixed. Even before that patch was written, it was known that window mode was broken for all kinds of USB tablets. I am marking this as a duplicate
*** This bug has been marked as a duplicate of 123546 ***