Problem with RECORD, XInput(2) (and Xnee)

[Peter Hutterer]

On Tue, May 25, 2010 at 12:36:38AM +0200, Henrik Sandklef wrote:
> hi
> 
>  I am currently implementing support for XInput(2) devices in GNU
> Xnee, starting out with recording events.
> 
>  Xnee gets copies of events from the X Server (using the RECORD
> extension). It seems to be a problem in the RECORD extension
> regarding XI (or XI(2)), but I am not sure and it would be great to
> get feedback.
> 
>  I'll try to describe the problem as good as I can.
> 
>  ---
> 
>  When reading the XInput spec and the corresponding source code I
> understand it as one XI2 event is packed into two "normal" events. I
> started by implementing support for MotionEvents. This worked out
> rather well. Xnee receives four "normal" events and packs them into
> two XI2 events (one from the master and one from the slave) and
> prints them out.

I think you may be mixing up XI2 and XI 1.x here.
XI 1.x does indeed that. The limitations on event size to 32 bits means only
some valuators fit into the first event a flag (highest bit in device-id) in
the first event specifies if there are more to come (the others are of type
DeviceValuator). Xlib packs those together into one event.

XI2 uses GenericEvents exclusively which work very different, all of type 35
and you need to watch the extension field and -more importantly- the lenght
field because you may need to pull down more data. See the event cookie
mechanisms in Xlib.
Having said that, I don't think RECORD writes XI2 events onto the wire at
the moment, so that point is moot.

>  When moving a pointer one pixel Xnee gets (event, detail):
>    83 detail=0
>    78 detail=9
>    83 detail=0
>    78 detail=13
>  The event base for XI is 78, so it looks ok to me. The detail is
> set to the deviceid of the input device (when not 0).

83 is the motion event then, 78 is the DeviceValuator event, the above are
two separate motion events. Look up the protocol spec for DeviceValuator,
IIRC it's described there how the events are squashed together.  if you have
a large number of valuators, you'd get 83 78 78 78 83 78 78 78, etc.

>  But when adding support for ButtonPress and ButtonRelease I don't
> get the 4 events for every press (or release). And the detail is
> always set to the number of the button pressed.
> 
>  When pressing a button Xnee gets (event, detail):
>     81 detail=1
>     81 detail=1
>     82 detail=2
>     82 detail=2

two button presses, two button releases. Likely because you're seeing the
master and the slave device events - they should have different deviceids.
we don't send valuators down after those events because the drivers usually
send motion events before the button events, so the actual button events
don't contain valuator data and hence no trailing DeviceValuators.

>  When reading the source code of XInputWireToEvent
> (libXi/src/XExtInt.c) it looks as if the client side of XI does pack
> two events together to one.
> 
>   Since RECORD doesn't give Xnee normal client side events (as
> normal apps get from client libs) but rather "limited" copies
> directly from the server, it seems to be something odd in the RECORD
> extension (or with my code).
> 
>  Most of my tests are done using swinput (Linux module) with support
> for 8 input devices, but I've tested with real devices as well.

you can freely use software-emulated devices, there's no difference at this
level anymore.

so yeah, you're close but you need to distinguish between master and slave
devices (or not, depending on what's needed). And as I said above, you're
working against XI 1.5 here. Though updating RECORD to transmit XI2 events
as well wouldn't be a bad project if you're interested.

Cheers,
  Peter