On 03/05/2012 06:09 PM, Peter Hutterer wrote:
On Mon, Mar 05, 2012 at 11:47:37AM -0800, Chase Douglas wrote:
The first three changes are improvements to the build system. The fourth is a
simple .gitignore update. The fifth is the addition of uTouch-Evemu device
recording playback support.
Unfortunately, the X.org server does not have a suitable mechanism for
generating test input events for all events. The XTest extension relies on a
static pointer and keyboard combination, does not propagate events through the
normal event path in the server, and only supports X core and XInput 1.x events.
I wanted to create a new input module that would instantiate new devices on
demand and send events using the xf86XInput API, but the input device
architecture of the server makes this impossible without a new input module API.
Not quite sure what part is impossible here, can you expand? We do something
like this in the wacom driver, NewInputDeviceRequest is exposed to the
drivers.
It may be possible with NewInputDeviceRequest, but it really would be a
hack job I think. Ideally, I would like to have an input module that
acted like uinput, but at the X level. It would open up a socket (not
necessarily TCP/IP, but why not), listen for connections, and
instantiate new devices and generate events based on a serial protocol
defined by the input module. Without having really attempted this, I
have my doubts that it could be made to work with the current xf86XInput
API.
This is just out of interest, I do think that uinput is the best solution
here anyway.
While I think uinput gets us a lot, there are two problems with it:
1. It's Linux only, so Oracle can't test on SunOS, Apple can't test on
OS X, etc.
2. Test input must be defined in terms of the Linux evdev protocol.
Usually all I want to do is create a device and send one touch event.
The real meat and potatoes of the test is how the server handles that
one event. However, a test writer now has to either record the test,
which may include way more events than we really want for a test, or
they need to hand craft an evdev sequence (probably in utouch-evemu format).
Of course, having uinput support is a huge leap ahead of where we are
today, which is practically no where when it comes to integration
testing. I just think in the long run it would be easier to maintain an
X.org specific, platform independent test device framework.
However, we can get around all this on Linux by using the uinput evdev
subsystem. Any physical device can be recorded and played back as a virtual
device using uinput. uTouch-Evemu is a thin wrapper around uinput that handles
recording to and playing back from files. We use this for utouch-frame,
utouch-grail, and utouch-geis for integration testing. Currently, each has its
own Evemu testing wrapper, but this will help simplify things.
You can find more information on evemu here:
https://wiki.ubuntu.com/Multitouch/Testing/uTouchEvEmu.
Note that uTouch-Evemu is GPLv3 and cannot be relicensed. Support is being added
optionally, and if you don't specify --with-evemu or --without-evemu it should
automatically pick it up if it's already installed. Until we have better X.org
input test frameworks, I believe this is a reasonable first step for testing.
I'm going to claim that given that uinput only exists on Linux, the GPLv3
dependency shouldn't affect us badly (those that can't use GPLv3 don't run
Linux, so...)
That's my thinking too, I just wanted it to be clear to everyone so we
don't have the same licensing surprise that everyone had with xorg-gtest :).
Thanks,
-- Chase
_______________________________________________
[email protected]: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
