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

[Henrik Sandklef]

Thanks a lot. That clarified it :)

Xnee can now record the device events from Xinput. Some work remains 
though with the non device events. A basic replay (XTest) of multiple 
pointers seems to be working as well.

.. and about implementing XI2 in RECORD. I'd love to do it, but as most 
of us currently (or constantly) I am lacking the time to do it. But some 
fine day.

/hesa

On 05/25/2010 04:21 AM, Peter Hutterer wrote:
> 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
> _______________________________________________
> xorg at lists.freedesktop.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: http://lists.freedesktop.org/mailman/listinfo/xorg
> Your subscription address: hesa at sandklef.com
>