XI2 relative motion events documentation

[Peter Hutterer]

On Wed, Oct 20, 2010 at 03:13:08PM -0500, Rendaw wrote:
>  On 10/19/2010 05:41 PM, Peter Hutterer wrote:
> >http://cgit.freedesktop.org/xorg/proto/inputproto/tree/XI2proto.txt#n1557
> >
> >"A RawEvent provides the information provided by the driver to the client.
> >RawEvent provides both the raw data as supplied by the driver and
> >transformed data as used in the server. Transformations include, but
> >are not limited to, axis clipping and acceleration.  Transformed
> >valuator data may be equivalent to raw data. In this case, both raw and
> >transformed valuator data is provided.
> >RawEvents are sent exclusively to all root windows or to the client that
> >grabbed the device only."
> Okay, thanks.  I sort of thought, since it was a RawEvent, it was
> some unaccelerated, intermediate form, but that helps a lot!  I
> might also have been dropping some RawEvents, which I think I've
> fixed now.  I ended up not looking at the spec when I started
> noticing inconsistencies between that and the implementation on my
> system, but I guess I should have persevered a bit longer.

yeah, please look at the protocol spec, it is the authoritative source on it
and I've tried my best to explain every request and event.

> >all valuator data is always in device coordinates, so as Daniel said you
> >need XIQueryDevice to get the axis ranges and then scale appropriately
> I'm not sure how axis ranges are useful.  Other than clipping, a
> maximum and minimum relative motion value doesn't make a lot of
> sense to me conceptually, but looking at the data might help.

"An axis in Relative mode may specify min and max as a hint to the
 client. If no min and max information is available, both must be 0."

for absolute axes, the axis range is quite important. for relative ones, as
said above it's just a hint that can be interpreted but doesn't have to be.

> One last question, semi-relevant.  Can I rely on the ordering of
> events to link the RawEvents to the MotionEvents?

in the current implementation, that's the case but there's nothing in the
protocol requiring it. so relying on it may break in the future.

Cheers,
  Peter