[PATCH xorg-gtest 0/5] Build system improvements and uTouch-Evemu support
chase.douglas at canonical.com
Mon Mar 5 21:26:53 PST 2012
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
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
> 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:
>> 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 :).
More information about the xorg-devel