GNOME Bugzilla – Bug 162334
gtk prevents graphics tablet input
Last modified: 2005-03-05 21:08:22 UTC
Jon Betts - psycop at users dot sf dot net reports that " When Gaim is loaded the system stops responding to the Graphics tablet. No plugins loaded. The interuption begins immediately upon loading Gaim (on the accounts logging in screen). As soon as Gaim is closed normal service resumes. Tablet is Medion MD41217 USB PC Graphics Tablet. A bit odd I know but also quite annoying. Win XP SP2, 512 Mb Ram, Athlon XP 2200+" I had him test this with gimp, and he reports that the same issue is apparent there.
A workaround would be to start gaim and gimp with the --ignore-wintab command- line switch. Then GTK doesn't do anything tablet-specific.
What exactly is meant by "the system stops responding to the Graphics tablet"? Does it stop responding to the tablet - in Gaim? - in other applications that are not tablet aware (most applications)? - in other tablet-aware applications like Photoshop and other drawing programs? The cause of the problem is either a limitation in the tablet driver or in the tablet code in GTK+. If it works in Gaim but stops working in other applications one possible cause is that GTK+ doesn't really manage context overlap order but just does a WTOverlap (.., TRUE) at startup. At least the Wacom tablet drivers don't care about that and handle it themselves, maybe this is not the case for Medion tablets? See http://www.wacomeng.com/devsupport/ibmpc/wacomwindevfaq.html#FAQ1.7 http://www.wacomeng.com/devsupport/ibmpc/wacomwindevfaq.html#FAQ3.4
Knowing nothing about wintab ... perhaps the initialization of winttab should be lazy in the win32 code and not be done until the app actually lists the devices, turns on extended events for a window, etc? That would prevent non-extended-input apps like GAIM from affecting other applications using the tablet.
I have forwarded your questions about when the tablet stops working to the report in our tracker, I will update this report if the submitter does not himself. is gimp tablet aware? he did say it also happens in gimp.
Owen: Yes, that sounds like a good idea. Luke: Yes, GIMP is tablet aware (and until lazy Wintab initialization is implemented every GTK+ application on Win32 that uses a GTK+ built with Wintab support is in some sense tablet aware). It isn't obvious what is meant by "it also happens in gimp". I interpret that as: When GIMP is loaded the system stops responding to the Graphics tablet - which doesn't answer my questions in comment #2.
The tablet can be used generally in windows as a mouse like controller. As soon as Gaim or the Gimp loads the pointer ceases to move about the screen when controlled by the tablet and freezes on the spot. The system generally seems unable to detect any tablet input, so all programs are affected. Including the driver configuration program from the tablet makers.
Thanks for the clarification. It sounds a bit strange that the tablet doesn't even work in Gaim/GIMP. It is tempting to blame this on the drivers for your tablet (have you checked if there are any updated drivers available from the manufacturer?), but maybe there is something that GTK+ could do different. Anyway, I suggest you use the workaround that Tor described in comment #1 for the time being if you haven't already tried that. It is also possible to set the environment variable GDK_IGNORE_WINTAB to 1 (this is done somewhere in the System settings in the Windows control panel if I recall correctly), which will disable tablet support in all GTK+ applications and make the tablet work as a regular mouse.
With GTK+ 2.6.2 this should no longer be an issue for GAIM users since the tablet is now only initialized when necessary (bug #163163). Please test.
several users report this does indeed fix the issue.
Great, let's close this bug report then. If the reporter wants to use GIMP with his tablet and there is still a problem after upgrading to GTK+ 2.6.3 or later, please open a new bug report. (One improvement was added in 2.6.3, see bug #167298) *** This bug has been marked as a duplicate of 163163 ***