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

[Peter Hutterer]

On Mon, Mar 05, 2012 at 09:26:53PM -0800, Chase Douglas wrote:
> 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.

input ABI 12 fixed a lot of the issues with NIDR that we had previously. if
you look at the udev config backend, it's just a bunch of
input_option_new(), a bunch of strdups/flag settings for the input
attributes and then the call to NIDR.

As long as you don't do it from the signal handler, NIDR can be called from
the input driver. 

Years ago I've had a driver that did just that - listen over the network for
incoming connections and then send events through the server. That was
before git so it's likely gone the way of the dodo. This approach is
possible and not even particularly hard.
 
> >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.

two things here:
I don't think that the evtest protocol is the best protocol, especially when
it comes to touch events. it is extensible though and reasonably easy to
understand once you wrap your head around it. the evdev handling is well
tested with evdev, synaptics and wacom all using it as backend.
so yes, you could add a new protocol for simple testing but sooner or later
you'll likely have to test something more exciting and you end up extending
your protocol. or you just accept evdev as the least of all evils.

as for other platforms: the implementation of uinput is linux only, that
doesn't mean that other tests can't use the same data structures though.

Cheers,
  Peter

> >>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