This has been reported before but I have no idea what could be causing
this behaviour.

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.

This bug allready exists with the 1.3.16 version.

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.  

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.

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

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.

I can't reproduce this with gentoo linux using gtk+ 2.2.4 and
linuxwacom-0.4.1

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

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

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.

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

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

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

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

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

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.

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.

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.

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?

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

Bumping a bunch of bugs which won't block the 2.0 release to 2.0.1.

Dave.

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

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

Bumping to milestone 2.0.2. This should be fixed but it is not worth to block
the 2.0.1 release for it.

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.

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.

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.

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.

Created attachment 28866 [details] [review]
Patch to avoid unwanted device change in toolbox

Suggested patch.

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.

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

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?

I would like to know why GIMP sees extraneous core pointer events but they don't
show up in testinput.

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.

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)

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.

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.

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.

sorry, "Robert Robert" changed to "Robert"