Simon Budig wrote:
> Garry R. Osgood ([EMAIL PROTECTED]) wrote:
> > Simon Budig <[EMAIL PROTECTED]>
> >
> > > <snipped...>
> > > BTW: Does somebody use XFree 4.0 with a wacom tablet? Sometimes I
> > > believe, that firm pressing the pen results in no more motion events...
> >
> > Is it "no more motion events", or is it *so many* motion events that
> > the Gimp becomes paralyzed in processing the backlog?
> > And is this problem always observed, or only when the "Perfect but
> > Slow" preference choice is made?
>
> It seems to be "no more events", since lifting the pen and touching
> the tablet again made the pen work again. It only happens, when
> "Perfect but Slow"-tracking is *dis*abled. So I guess, when I press
> harder, more events are generated and Gimp loses some events?
> Motion Buffer is set to 0.
Thank you for the feedback, and 'Hmmmm...' indeed. This much I
know for sure, and I can say 'for sure' because the scope is limited
to the XInput Extension interface and not peculiarities of different
implementations of that interface (which appear not to be uniform).
Enabling your Wacom device and disabling "Perfect but Slow"
tracking invokes the Input Extension macro DevicePointerMotionHint()
[at the GDK level (gdkinputcommon.h gdk_input_common_find_events())]
This macro is used in preparation of calling XSelectExtensionEvent()
and, according to XConsortiums InputEvent Specification, tells the XInput
extension the kinds of events that is to be obtained from devices.
The hint modifier requests that not *all* motion events are to be fed
upstream. They are to be filtered.
How? That's where published XConsortium documentation becomes vague,
and it seems interpretation varies from Xserver to Xserver implementations.
On SGI's, in this mode, *one* motion event occurs after a device button press,
and another after a device button release. No intermediary motion goes
upstream and the pointer behaviour is extremely jerky from pen-down to
pen-up. This is similar to (but not exactly like) how you've described it.
Differences, I surmise, reside in how XFree implements their server.
As an aside, enabling "Perfect but Slow" disables the use of the macro,
and the device sends all motion events upstream -- I find that Gimp bogs
down at this point: It tries to honor and process *all* motion events, and these
arrive at 5 to 7 times the frequency of screen cursor motion events.
Sven -
In separate email you observe that the appropriate level for flow control
of the event stream is in GTK/GDK level, and not at the Gimp
application. If the situation were ideal, I'd agree with you, but the
"flow control" that applications need to manage devices through the
XInput Extension device amount to this almost-all-or-nothing macro.
There may be XFree86-specific remedies, but Gimp runs on boxes
where XFree does not exist.
I'm a member of that last class, and it concerns me. There are a lot
of high-end users using Gimp on SGI's Being unable to get the
tablet to behave properly does not make members of this class
happy.
All -
Are you happy with how Gimp behaves with your Wacom tablets ?
Is this an isolated incident, or is there a general area of difficulty
here? Comments ?
Be good, be well
Garry Osgood
