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 115774 - Tablet pointer becames core pointer
Tablet pointer becames core pointer
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: General
1.x
Other All
: Normal normal
: 2.0
Assigned To: GIMP Bugs
GIMP Bugs
: 120133 127680 136790 (view as bug list)
Depends on:
Blocks: 127786
 
 
Reported: 2003-06-23 08:03 UTC by jm
Modified: 2004-07-11 03:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to avoid unwanted device change in toolbox (2.16 KB, patch)
2004-06-19 19:34 UTC, Robert Ögren
none Details | Review
Revised patch for avoiding erroneous switch to core ptr device in toolbox (1.77 KB, patch)
2004-07-10 20:12 UTC, Robert Ögren
none Details | Review

Description jm 2003-06-23 08:03:45 UTC
When I use my wacom tablet (pencil or mouse) with gimp-1.3.15 (window mode)
on the picture window, all is ok. There is also no problem with the others
windows (layers, paths, toll options, ...).
But when the pointer goes to the main window (named "The Gimp"), the used
device becames the core pointer. 




Versions:
Tablet: wacom graphire 2

System:
atk-1.2.4
glib-2.2.2
gtk+-2.2.2
pango-1.2.3
pygtk-1.99.16
XFree-4.3.0
linuxwacom-0.4.1
kernel 2.4.20 (gcc version 3.2.2 (Mandrake Linux 9.1 3.2.2-3mdk))
windowManager: KDE 3.1.0
Comment 1 Sven Neumann 2003-06-23 08:39:27 UTC
This has been reported before but I have no idea what could be causing
this behaviour.
Comment 2 Sven Neumann 2003-07-04 10:28:18 UTC
Please don't change the version information. If you want to indicate
that a particular problem is still present in a newer release, please
add a comment.
Comment 3 jm 2003-07-04 10:30:22 UTC
This bug allready exists with the 1.3.16 version.
Comment 4 Alan Horkan 2003-07-23 18:44:23 UTC
Changes at the request of Dave Neary on the developer mailing list.  
I am changing many of the bugzilla reports that have not specified a target
milestone to Future milestone.  Hope that is acceptable.  
Comment 5 Dave Neary 2003-07-26 20:11:48 UTC
Changing milestone on a bunch of bugs to 2.0 - none of these could be considered
a blocker for a pre-release, IMHO. Many of these have patches or someone working
on them, but they're not urgent.

Dave.
Comment 6 Sven Neumann 2003-08-18 14:33:52 UTC
*** Bug 120133 has been marked as a duplicate of this bug. ***
Comment 7 Ari Pollak 2003-08-30 13:38:51 UTC
From bug submitter:

If I delete the .gimp1.3 directory and I start gimp1.3, all the devices
work as expected. If I quit the session then the problem appears.
Comment 8 Daniel Rogers 2003-11-14 04:57:51 UTC
I can't reproduce this with gentoo linux using gtk+ 2.2.4 and
linuxwacom-0.4.1
Comment 9 Sven Neumann 2003-11-22 18:58:54 UTC
*** Bug 127680 has been marked as a duplicate of this bug. ***
Comment 10 Jean-Luc Coulon 2003-12-01 13:19:20 UTC
Hi,

The stylus / eraser / Pointer dont switch anymore to core pointer with
1.3.22 / 1.3.23 or the cvs version.

But there is a bad behaviour related to these devices.
When the pointer moves on the menu bar of the main window, the tools
dialog and the gradients dialog 'blink'. It seems that they are
switching quickly from a tool to an other one (core pointer to pointer
affected tool?). While doing so, the responsiveness of Gimp is
affected. This problem does not occurs with the core pointer. It does
not occurs neither on the menu bar of an image window.

--
Regards

- Jean-Luc
Comment 11 Shaneyfelt 2003-12-03 01:26:19 UTC
You probably need to change OS to All.

This exact problem happens in Windows 2000 as well.
At home it worked for awhile with a USB WaCom tablet
and broke this week around the time I installed a new
USB hub.  At work I have a serial WaCom tablet that 
has the same problem.  As a workaround, where I loose 
pressure sensitivity, etc. I set the environment variable
GDK_IGNORE_WINTAB to anything as suggested for bug #81663.
Comment 12 Jean-Luc Coulon 2003-12-05 15:48:36 UTC
Hi,

If I open the device status dialog, I can see the black arrow
switching quickly between the core pointer and the active device when
I'm on the menu bar of the main window.

Regards
Comment 13 Jean-Luc Coulon 2003-12-17 16:12:56 UTC
I've compiled the CVS on December 17th, 2003.
With the mouse (pointer), the device switches correctly from pointer
when on the tools dialog to core pointer when on the menu bar.
When doing the same thing with the stylus or the eraser tip, the
previously related problem still occurs (fast switching from core
pointer to stylus/eraser while on the menu bar).

--
Regards
            - Jean-Luc
Comment 14 Niklas Mattisson 2003-12-24 02:00:17 UTC
My tablet Wacom Intuos2 A5 USB works just fine now in 1.3.23. However
I needed to download the 0.5.3-beta package from LinuxWacom to get it
working properly.

Maybe try using the beta driver to see if there is any changes?

My tablet works great now with the beta driver at least. (Don't know
if this helps this problem though. Worth a test at least.)

Regards
Comment 15 Niklas Mattisson 2003-12-25 21:16:34 UTC
I have tried the new Wacom driver now with my tablet.

It seems like the problem still exists....the thing is that I can use
1.3.23 once or twice with the tablet, but after a while it becomes
core pointer again and I need to restart X and get the modules
reloaded to make the tablet work in 1.3.23 again.

I tried to do it the easy way to rmmod the drivers and load them again
instead of exiting X. However this test did not work...something was
using evdev and so I couldn't load the modules all over again. This
makes me wonder if GIMP exits the use of the driver once being exited?
GIMP uses the driver right? So does GIMP exit the driver correctly
like it is doing in 1.2.5? Or how do GIMP use the drivers?

So to summaries this:

* The 0.5.3-beta driver works ok with 1.3.23 (Fixes the main driver
problems for at least my tablet)

* Sometimes however something goes wrong either with the driver or
with GIMP. This means that the tablet goes haywire and starts acting
like some things are core pointer in GIMP while they are not. Though
it selects the stylus device in the device dialog.

* GIMP 1.2.5 handles the devices just fine. However it seems like
something is using the devices in the background. evdev can't be
rmmoded when I tried but wacom module can. Just loading the wacom
module won't make a change for the tablet it freezes and I need to
restart X.

* When I look in the device status dialog I can see only 2 things.
cursor and core pointer. _BUT_ when I see thoose two the tablet works.
Sometimes when I start GIMP I will see all the devices and then the
tablet won't work. So as long as I see 2 devices it works just fine.
Why this happens I don't know. In GIMP 1.2.5 I see one device. Core
Pointer. But the tablet works. Using the stable driver will show the
devices in both 1.3.23 and 1.2.5 though the tablet will only work
properly in 1.2.5

Thats the main things that I have seen for my tablet here. So the
tablet works for a while now, but will in a short time crash and I
need to restart X.

Regards
Comment 16 Jean-Luc Coulon 2003-12-25 21:29:41 UTC
I tried the new driver.
For me, it works like the previous one (fine with gimp 1.2).
-  I can se the four devices (core pointer / pointer / stylus /eraser).
- The correct device is displayed when I'm in a picture or in the
tools window.
- When I'm on the menu bar of the main window, it switches from the
core pointer to the device in use. When doing so, the responsiveness
of the system is affected but everything is workning nevertheless.

--
Regards
Comment 17 Niklas Mattisson 2004-02-10 21:38:27 UTC
Me again....

I saw now that Linuxwacom has released a 0.6.0 driver. You should
really take a look if this driver helps you anything. (That is if it
does any inprovments)

To me it made a big improvement.

* Now working just fine in 2.0pre3 (Some minor things going weird but
nothing big)
* Pressuresensativity is really cool now! :)
* Devices are listed ok now in both 2.0pre3 and 1.2.5

Sometimes the tablet goes weird and I have to move the 2D mouse on the
tablet to be able to use the pen, but that is nothing big IMHO.

Try the 0.6.0 driver to see if there is any difference in performance.
Comment 18 Niklas Mattisson 2004-02-11 00:04:50 UTC
Hi,

I just noticed something trying the drivers a little more and I have
to apologies.

- 1.2.5 does not list the devices, the tablet works fine but the only
thing listed is the "Core Pointer". 2.0-pre3 does list the devices
correct though.

I am so sorry once again. But I really think you should try the 0.6.0
drivers to see what happens.
Comment 19 Niklas Mattisson 2004-02-11 00:15:47 UTC
Okay people,

I have been tired, tired and tired during this hour now. So here goes:

* It works just fine in 1.2.5 _my problem_ was that I didn't have the
devices activated in the Device Input for 1.2.5 which I thought I had
saved since before so they would always be in the status. (Tired)


I really think it is time for me to sleep now.
Comment 20 Simon Budig 2004-03-09 21:17:54 UTC
Ok, I tried to reproduce this with GTK+-2.2.4 and XFree 4.3.99, using
the included wacom driver as well as linuxwacom 0.6.0 and was unable
to reproduce it.

I'd appreciate if people with a tablet could try to reproduce this and
if they manage to reproduce the bug attach a comment to this bug,
mentioning their version of GTK+ and XFree86 and driver used.

Maybe it was a bug in GTK+ or got fixed by accident in the meantime?
Comment 21 Jean-Luc Coulon 2004-03-10 08:15:22 UTC
Hi,

I'm running Debian sid with the following releases of the softwares:

- kernel 2.4.25
- Xfree 4.3.0.1
- linuxwacomm 0.6.1 (xwacom_drv.o from it only, wacom.o and other    
   modules related to input from the kernel)
- gtk+ 2.2.4
- gimp 2.0-pre4 or the latest cvs from 20040309

With this configuration:
- The devices are present and working
- The pressure works

But when I'm on the menu of the main window (and only on it) with the
core pointer, stylus or eraser, In the devices dialog, I can see the
black arrow switching quickly from core pointer to the device in use.

--
Regards

- Jean-Luc
Comment 22 Dave Neary 2004-03-10 10:48:46 UTC
Bumping a bunch of bugs which won't block the 2.0 release to 2.0.1.

Dave.
Comment 23 Jean-Luc Coulon 2004-03-10 11:32:17 UTC
Hi,

I'm just sure I've understood (english language problem). I was just
replying to Simon Budig who was requesting more informations.
This bug is just "annoying"..

--
Regards
 - Jean-Luc
Comment 24 James Bowes 2004-03-11 12:19:59 UTC
I was able to reproduce this but with:
-gimp 2.0pre4
-linuxwacom 0.6.1
-Xfree 4.3.0
-gtk+ 2.3.2 and 2.2.4

I could also get the same switching between pointers to occur when
pressing and holding the stylus over the foreground & background
colors in the toolbox.

James
Comment 25 Sven Neumann 2004-04-10 12:45:42 UTC
Bumping to milestone 2.0.2. This should be fixed but it is not worth to block
the 2.0.1 release for it.
Comment 26 Philip L 2004-05-15 21:17:41 UTC
I also get the same switching when pressing the stylus on the fg/bg color
swatches (as well as when moving it over a movable separator or a menu) but when
the color selector opens it uses the current color from the core pointer rather
than from the stylus, so it is impossible to choose a color relative to the
current color without keeping the selector window open. As well, when I click
cancel it replaces the current stylus color with the core pointer color, so the
color is lost completely.

I am using:
GIMP 2.0.1, 2.6.6 kernel wacom driver and the wacom_drv.o from XFree86 4.4.0,
gtk+ 2.4.1.
Comment 27 Philip L 2004-05-15 21:28:37 UTC
to clarify: I think that during the instant that I'm clicking the color swatch
it switches to the core pointer, then back to the stylus after the selector
dialog opens.
Comment 28 Philip L 2004-05-15 21:44:23 UTC
Sorry for the multiple comments, but I ran across an important detail: the
aforementioned only occurs when the "cursor" type extended input device is
enabled; otherwise it seems to function as it should (but the GIMP has to be
restarted after turning the cursor device off). The core pointer retains its
color/tool settings in either situation.
Comment 29 Robert Ögren 2004-06-19 19:21:33 UTC
I can confirm that similar bugs occur on the Windows platform as well (after my
fixes to the Wintab code in GTK+, see bug #138341 and #142943).

I am using:
- Windows XP SP 1
- A Wacom Graphire 3 tablet with the 4.78-6 driver
- GTK+ compiled from the gtk-2-4 branch in CVS, updated today
- The GIMP compiled from the gimp-2-0 branch in CVS, updated today

If I move the tablet stylus pointer over the main menu bar, GIMP switches to the
Core Pointer device (but without flickering back and forth between the stylus
and the core pointer because of my hackery in the event propagation code in the
Win32 GDK backend, bug #142943).

If I click the color selector using the stylus and then move the stylus slightly
while keeping it pressed, GIMP switches to the Core Pointer device similar to
what is described in comment 24 and 26.
Note that I do not need to move the stylus enough to start a drag, and if I just
click and release on the color selection area without moving the stylus,
everything works well.

I have tried to track down these problems, and the reason that The GIMP switches
to the core pointer device in the second case is that a motion event from the
core pointer device is sent from the toolbox_color_area. I think this is related
to the drag and drop handling, since the color area is a drag source.

Both of the problems occur because some widget wants motion events but not
extension events, and the event is then propagated to the toolbox widget which
just sees that the event is from the core pointer device. The solution as I see
it is to add checks to the toolbox_check_device function in
app/widgets/gimptoolbox.c so that it does not change device if the motion event
is from the main menu or if a pointer button is down.

I have tried to make an implementation of these checks, and they fix my
problems. A suggested patch will be attached shortly.
Comment 30 Robert Ögren 2004-06-19 19:34:17 UTC
Created attachment 28866 [details] [review]
Patch to avoid unwanted device change in toolbox

Suggested patch.
Comment 31 Akkana Peck 2004-06-19 22:07:00 UTC
I'm seeing this with gimp 2.0.1, linux kernel 2.6.6, Debian sid, X 4.3.0.1 (from
sid), libgtk2 2.4.2-1 (also from sid), wacom_drv.o from
inuxwacom-0.6.3/prebuilt/wacom_drv.o_4.3k2.6.  I have the "cursor" device
commented out because lots of people suggested that (and I don't use it anyway).
 testinput shows wacom events, as does wacdump.

With the patch suggested here, the eraser can now pick a tool or a color from
the toolbox; the stylus still can't.  Neither the eraser nor the stylus seem to
do their proper tool action in an image window: e.g. for eraser, the cursor
changes to ink pen or whatever, but nothing is drawn, when I can draw with the
core pointer in the same window.
Comment 32 Sven Neumann 2004-07-04 00:46:42 UTC
*** Bug 136790 has been marked as a duplicate of this bug. ***
Comment 33 Robert Ögren 2004-07-08 19:52:16 UTC
Akkana, my patch only deals with GIMP switching to the core pointer device when
clicking and dragging the stylus or eraser on the fg/bg color swatches, and when
the stylus/eraser is over the main menu, in the main toolbox window. It has
nothing to do with the image windows. Did you check for "Button press 1" events
and nonzero pressure from testinput?

Does anyone else have any comments about my patch?
Comment 34 Philip L 2004-07-09 22:03:11 UTC
I would like to know why GIMP sees extraneous core pointer events but they don't
show up in testinput.
Comment 35 Robert Ögren 2004-07-10 20:09:33 UTC
The toolbox in The GIMP can get some core pointer motion events even when an
extended input device (e.g. stylus) is used, because the event was originally
meant for a widget that wants motion events but has not requested extended input
events and was then propagated to the parent widget because the original widget
did not handle it.

The toolbox (app/widgets/gimptoolbox.c) requests motion events and turns on
extension events for the toolbox widget in gimp_toolbox_new. Most of the widgets
in the toolbox do not request motion events and therefore those motion events
are sent to the toolbox widget. Some widgets such as the menu and the color
swatches (or rather some hidden widget used in drag and drop for the color
swatches) want ordinary motion events but then don't handle them so they are
passed up the widget hierarchy which makes The GIMP incorrectly switch to the
core pointer device.

The problem does not occur in testinput because it listens for motion events
only from the drawing area (with extension events turned on) but the drawing
area does not have any child widgets that want ordinary motion events.

I think the toolbox in The GIMP should be more restrictive about the motion
events it uses to check for a device change. The device should only be
checked/changed if the event originated from a widget that has requested
extension events, because otherwise the event will always be from the core
pointer device which causes these unwanted changes to the core pointer device.

I have simplified my patch, now it just checks that the originator of the motion
event wanted extension events before allowing The GIMP to check for a device
change (in toolbox_check_device). It has been tested on gimp-2-0 and HEAD from
CVS together with gtk-2-4 recently updated from CVS with the system described in
comment 29. I have only tested it on the Win32 platform, so comments from X11
users would be especially welcome.
Comment 36 Robert Ögren 2004-07-10 20:12:25 UTC
Created attachment 29412 [details] [review]
Revised patch for avoiding erroneous switch to core ptr device in toolbox

Revised patch (created using cvs diff -u against gimp-2-0 branch)
Comment 37 Philip L 2004-07-10 22:58:07 UTC
Thanks for your explanation. I can confirm that the revised patch works on X11
(it sounds like a platform-independent problem anyway), and I think it ought to
be applied.

It appears that my earlier solution of disabling the 'cursor' device actually
somehow stopped all device changes from the toolbox. That's a different bug,
though, since it happens with and without the patch.
Comment 38 Philip L 2004-07-10 23:21:28 UTC
Actually this fix seems more appropriately placed in
gimp_devices_check_change(). I will apply it there in a few hours when I get the
time.
Comment 39 Philip L 2004-07-11 03:24:08 UTC
Applied to main and gimp-2-0 branches:

2004-07-11  Philip Lafleur  <plafleur@cvs.gnome.org>

	* app/widgets/gimpdevices.c (gimp_devices_check_change): Applied
	a patch from Robert Robert Ögren, moved here from
	toolbox_check_device() - Only change devices if the event came from
	a widget that accepts extension events. Fixes bug #115774.
Comment 40 Philip L 2004-07-11 03:29:14 UTC
sorry, "Robert Robert" changed to "Robert"