On Tue, 14 Nov 2000, Simon Budig <Simon.Budig@xxxxxxxxxxxxxxxxxxxxx> wrote:
> Garry R. Osgood (gosgood@xxxxxxx) wrote:
> [does GTK handle the XInput-devices and the "normal mouse" in the same way?]
> > At present, we know that is not entirely true in two mixes of hardware.
> > However, the manner in which they are untrue appears essentially the same.
>
> > I have, however, just read Raphael's well-documented response, and he
> > is seeing quite different things. I need more time to reflect on his
> > mail, but his results suggest that 10498 does have hardware
> > dependencies. I think a sensible fix is not immediately forthcoming.
>
> I wrote a small program to monitor the extended XInput-Events, it is
> attached. For my Artpad II it shows a strange thing: If I press the "right"
> Pen-Button when pressing the Pen on the tablet, each motion event is
> surrounded by proximity in and proximity out events for the
> eraser side of the pen. This is probably a bug in the XFree-driver
> or a bad tablet-protocol. There is a strange comment in the Driver
> source (The Artpad II speaks the Wacom 4 protocol, Intuos Wacom 5:
>
> if (common->wcmProtocolLevel == 4 &&
> !(common->wcmFlags & GRAPHIRE_FLAG)) {
> /* The stylus reports button 4 for the second side
> * switch and button 4/5 for the eraser tip. We know
> * how to choose when we come in proximity for the
> * first time. If we are in proximity and button 4 then
> * we have the eraser else we have the second side
> * switch.
> */
>
> Maybe there is a bug in the XFree86 driver with this assumption?
I haven't tried the test program yet (I will try this evening), but
this assumption in the driver looks suspicious.
This special case for the ArtPad II would explain why the problems
seen in the Gimp are hardware-dependent. I think that #10498 occurs
because of a combination of two things:
- A bug in GTK+ (in the interaction between XInput and the core
pointer) breaks the semantics of the pointer grab, so the
application (Gimp) receives some events that should never occur
while the pointer is grabbed.
- For the ArtPad II under XFree86, another bug in XFree shadows the
GTK+ bug and causes other strange things to happen.
If this theory is correct, then the Gimp 1.2 should require a new
release of GTK+. :-(
Some code in GDK could check if the pointer is grabbed and ignore the
XInput events that should be masked during that time. Or maybe it
should put these events in a special stack or update an internal
button mask, in order to avoid spurious events later (getting a
GDK_BUTTON_RELEASE for a button that was ignored while the pointer was
grabbed). I haven't checked the code, so I don't know if this is easy
to do or not (I don't even know if the bug is really there).
The XInput-related bugs can be more serious than what is reported in
#10498. I wrote yesterday that I never saw the marching ants problem
with my ArtPad II, but that I would test what happens when the stylus
and eraser and mapped to different tools. Well... the results are not
pretty. I mapped the stylus to the rectangular selection tool, and
the eraser to the clone tool. Then I started dragging the selection
with the pen and I pressed the button on the side of the pen. The
current device switched to the eraser (oops!) and the current tool
switched to the clone tool (double oops!) although the Gimp had
probably not received a BUTTON_RELEASE. Even worse, moving the pen
with the button pressed caused the tool options dialog to flicker
quickly, meaning that it was constantly switching between the two
tools (probably once for each motion event). During all that time,
the pen (button 1) was pressed.
I repeated this test a couple of times (also with other tools) and it
did not take long before I got an assertion failed in the undo code
and all undo info for my image was lost. I did not write down the
error message, but this is probably irrelevant because the fix must be
introduced in other parts of the code (maybe in GTK+) before it has a
chance to affect the undo stack.
There is a workaround for the disappearing marching ants (duplicate
the image) but there is probably no workaround for a broken undo
stack. Until the bug is fixed, the only solution is to be very
careful and to avoid pressing the pen button while you are dragging a
selection or doing anything else that involves a pointer grab. Yuck!
-Raphael
