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@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: h...@sandklef.com
_______________________________________________
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
