[PATCH xorg-gtest 0/5] Build system improvements and uTouch-Evemu support

[Chase Douglas]

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