Re: [gimp-devel] Thanks for Tablet Testing
Garry R. Osgood ([EMAIL PROTECTED]) wrote: > Simon Budig wrote: > > I wrote a small program to monitor the extended XInput-Events, it is > > attached. > > I've not had much time to investigate further on , but these are some trial > runs I get Built and run on ALICE, an SGI Indigo R4000, using MIPS 6.2 > compiler ALICE 35% xinputev --display harriet:0 (An SGI O2 Xsgi X-window > server Wacom 4.4.0 device driver) > Enabling No. 2: "wacom" (Type: 1) > Enabling No. 3: "mouse" (Type: 1) > Enabling No. 65244: "Core Pointer" (Type: 0) > button_press : device 3 pressure 0.500 button 2 > button_release: device 3 pressure 0.500 button -2 [...] > button_press : device 3 pressure 0.500 button 2 > button_release: device 3 pressure 0.500 button -2 > > In this configuration, button 3 release is consumed before > it reaches your code when using the mouse. My guess is, that the release events simply go to the menu when the mouse pointer is over it at this time. There seems to be a problem: [from http://www106.pair.com/rhp/sample_chapters.html ] : The X server automatically causes a pointer grab when a button is : pressed, and releases it when it is released. This means that the : button release event always goes to the same window that received the : button press event. Xlib allows you to change this behavior, but GDK : does not. (In the Xlib documentation, this automatic grab is referred : to as a "passive" grab. It's distinct from an "active" grab initiated : with gdk_pointer_grab(), described in Section 10.6.2.) Have a look also at http://ftp.x.org/pub/R6.4/xc/doc/specs/X11/CH12 . IIRC this only applies when the event mask contains both the GDK_BUTTON_PRESS_MASK and GDK_BUTTON_RELEASE_MASK. However, there seems to be a problem: Obviously this does not work with XInput-Devices. (Maybe they are "traditionally" something fundamental different than the "Core Pointer" and all higher level event processing is left to the application, and the "AlwaysCore"-mode does not respect this) So a solution might be: * when someone presses the button down, grab the pointer until the release event occurs (should be done on GDK-Level?) * prevent the invokation of the menu when the first button is pressed down (ugly!). Maybe this is also related to Bug #6901, "Can not continually move a floating selection with a pressure sensitive pointer."? Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: [gimp-devel] Thanks for tablet Testing [Re: Tablet Testing Needed]
On Tue, 14 Nov 2000, Simon Budig <[EMAIL PROTECTED]> wrote:
> Garry R. Osgood ([EMAIL PROTECTED]) 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
Re: [gimp-devel] Thanks for Tablet Testing
Hi Simon, Raphael... Simon Budig wrote: > > I wrote a small program to monitor the extended XInput-Events, it is > attached. I've not had much time to investigate further on , but these are some trial runs I get Built and run on ALICE, an SGI Indigo R4000, using MIPS 6.2 compiler ALICE 35% xinputev --display harriet:0 (An SGI O2 Xsgi X-window server Wacom 4.4.0 device driver) Enabling No. 2: "wacom" (Type: 1) Enabling No. 3: "mouse" (Type: 1) Enabling No. 65244: "Core Pointer" (Type: 0) button_press : device 3 pressure 0.500 button 3 button_press : device 3 pressure 0.500 button 2 button_release: device 3 pressure 0.500 button -2 button_press : device 3 pressure 0.500 button 2 button_release: device 3 pressure 0.500 button -2 button_press : device 3 pressure 0.500 button 3 button_press : device 3 pressure 0.500 button 3 button_press : device 3 pressure 0.500 button 3 button_press : device 3 pressure 0.500 button 3 button_press : device 3 pressure 0.500 button 3 button_press : device 3 pressure 0.500 button 3 button_release: device 3 pressure 0.500 button -1 button_press : device 3 pressure 0.500 button 1 button_release: device 3 pressure 0.500 button -1 button_press : device 3 pressure 0.500 button 1 button_release: device 3 pressure 0.500 button -1 button_press : device 3 pressure 0.500 button 1 button_release: device 3 pressure 0.500 button -1 button_press : device 3 pressure 0.500 button 2 button_release: device 3 pressure 0.500 button -2 button_press : device 3 pressure 0.500 button 2 button_release: device 3 pressure 0.500 button -2 button_press : device 3 pressure 0.500 button 2 button_release: device 3 pressure 0.500 button -2 button_press : device 3 pressure 0.500 button 2 button_release: device 3 pressure 0.500 button -2 button_press : device 3 pressure 0.500 button 2 button_release: device 3 pressure 0.500 button -2 In this configuration, button 3 release is consumed before it reaches your code when using the mouse. Now the Wacom Intuos tablet. The button on the barrel is a vertically-oriented rocker switch: the downward side is button 3, the upward side is button 2. button_press : device 2 pressure 0.001 button 1 button_release: device 2 pressure 0.000 button -1 button_press : device 2 pressure 0.091 button 1 button_release: device 2 pressure 0.000 button -1 button_press : device 2 pressure 0.008 button 1 button_release: device 2 pressure 0.000 button -1 button_press : device 2 pressure 0.340 button 1 button_release: device 2 pressure 0.000 button -1 button_press : device 2 pressure 0.001 button 1 button_release: device 2 pressure 0.000 button -1 button_press : device 2 pressure 0.001 button 1 button_press : device 2 pressure 0.094 button 3 button_press : device 2 pressure 0.000 button 3 button_press : device 2 pressure 0.000 button 3 button_press : device 2 pressure 0.000 button 3 button_press : device 2 pressure 0.000 button 3 button_press : device 2 pressure 0.000 button 2 button_release: device 2 pressure 0.000 button -2 button_press : device 2 pressure 0.000 button 2 button_release: device 2 pressure 0.000 button -2 button_press : device 2 pressure 0.000 button 2 button_release: device 2 pressure 0.000 button -2 button_press : device 2 pressure 0.000 button 2 button_release: device 2 pressure 0.000 button -2 button_press : device 2 pressure 0.269 button 1 button_release: device 2 pressure 0.000 button -1 button_press : device 2 pressure 0.442 button 1 button_release: device 2 pressure 0.000 button -1 button_press : device 2 pressure 0.595 button 1 button_release: device 2 pressure 0.000 button -1 Button 3 is still consumed. Now, pressing down on the pen and manipulating the rocker switch button_press : device 2 pressure 0.024 button 1 button_press : device 2 pressure 0.949 button 3 button_press : device 2 pressure 0.941 button 3 button_press : device 2 pressure 1.000 button 3 button_press : device 2 pressure 1.000 button 3 button_press : device 2 pressure 1.000 button 3 button_press : device 2 pressure 1.000 button 3 button_press : device 2 pressure 0.791 button 3 button_press : device 2 pressure 1.000 button 2 button_release: device 2 pressure 1.000 button -2 button_press : device 2 pressure 1.000 button 2 button_release: device 2 pressure 1.000 button -2 button_press : device 2 pressure 1.000 button 2 button_release: device 2 pressure 1.000 button -2 button_release: d
Re: [gimp-devel] Thanks for tablet Testing [Re: Tablet Testing Needed]
Garry R. Osgood ([EMAIL PROTECTED]) wrote:
> Simon wrote:
> > When selecting something (e.g. tearing the menu off) the marching ants die.
> > When opening a new image they are alive for the new image.
>
> I Confirm this as well. Excellent, Simon, for you have brought forth
> the work-around to the problem for the poor Gimp user until this is
> resolved: When Marching Ants Die, Cntl-D for a New Image (I suppose
> saving the image first won't be such a bad idea). This creates a new
> Selection object for that image without an unbalanced pause count.
Heh - I didn't realize this... :-)
[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?
My demo program is simply compiled with
gcc -o xinputev xinputev.c `gtk-config --libs --cflags`
When invoked with an additional argument it does report the motion
events too. When you press the right button it invokes a
submenu without any function. You can see, that under certain
circumstances the release events for the buttons 1/3 dont reach the
main window.
Bye,
Simon
--
[EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
/* XInputEV -- a program for monitoring XInput-Events
* Copyright (C) 2000 Simon Budig <[EMAIL PROTECTED]>
*
* Distributed under the terms of the GNU GPL.
*
* compile with
* gcc -o xinputev xinputev.c `gtk-config --libs --cflags`
*/
#include
#include
#include
#define EVENT_MASK ( GDK_PROXIMITY_IN_MASK | \
GDK_PROXIMITY_OUT_MASK | \
GDK_BUTTON_PRESS_MASK | \
GDK_BUTTON_RELEASE_MASK | \
GDK_POINTER_MOTION_MASK )
GtkMenu *menu = NULL;
GtkWidget *menupoint = NULL;
/* Event-Handler */
gboolean
printevent (GtkWidget *widget, GdkEvent *ev, gpointer user_data)
{
GdkEventButton *bev=NULL;
GdkEventMotion *mev=NULL;
GdkEventProximity *pev=NULL;
GtkWidget *win = NULL;
switch (ev->type)
{
case GDK_BUTTON_PRESS:
bev = (GdkEventButton *) ev;
g_printerr ("button_press ");
if (bev->button == 3)
gtk_menu_popup (menu, NULL, NULL, NULL, NULL, 3, GDK_CURRENT_TIME);
break;
case GDK_2BUTTON_PRESS:
bev = (GdkEventButton *) ev;
g_printerr ("button2_press ");
break;
case GDK_3BUTTON_PRESS:
bev = (GdkEventButton *) ev;
g_printerr ("button3_press ");
break;
case GDK_BUTTON_RELEASE:
bev = (GdkEventButton *) ev;
g_printerr ("button_release");
break;
case GDK_PROXIMITY_IN:
pev = (GdkEventProximity *) ev;
g_printerr ("proximity_in ");
break;
case GDK_PROXIMITY_OUT:
pev = (GdkEventProximity *) ev;
g_printerr ("proximity_out ");
break;
case GDK_MOTION_NOTIFY:
mev = (GdkEventMotion *) ev;
g_printerr ("motion_notify ");
break;
default:
g_printerr ("Unknown Event\n");
}
if (bev)
g_printerr (": device %5d pressure %6.3f button %d\n",
bev->deviceid, bev->pressure,
bev->type == GDK_BUTTON_RELEASE ? bev->button * -1 :
bev->button );
if (pev)
g_printerr (": device %5d\n", pev->deviceid);
if (mev)
g_printerr (": device %5d pressure %6.3f\n",
mev->deviceid, mev->pressure);
return 0;
}
int
main (int argc, char **argv)
{
GList *tmp_list;
GtkWidget *win;
gtk_init (&argc, &argv);
win = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_widget_set_usize (GTK_WIDGET (win), 20
