[PATCH libinput] test: add litest helper functions for creating uinput devices

[Peter Hutterer]

On Thu, Mar 27, 2014 at 05:10:34PM +0100, Jonas Ådahl wrote:
> On Thu, Mar 27, 2014 at 08:48:02AM +1000, Peter Hutterer wrote:
> > Both functions accept a series of event types/codes tuples, terminated by -1.
> > For the even type INPUT_PROP_MAX (an invalid type otherwise) the code is used
> > as a property to enable.
> > 
> > The _abs function als takes an array of absinfo, with absinfo.value
> > determining the axis to change. If none are given, abs axes are initialized
> > with default settings.
> > 
> > Both functions abort on failure, so the caller does not need to check the
> > return value.
> > 
> > Example code for creating a rel device:
> > 
> > struct libevdev_uinput *uinput;
> > struct input_id id = { ... };
> > uinput = litest_create_uinput_device("foo", &id,
> >                                      EV_REL, REL_X,
> >                                      EV_REL, REL_Y,
> >                                      EV_KEY, BTN_LEFT,
> > 				     INPUT_PROP_MAX, INPUT_PROP_BUTTONPAD,
> >                                      -1);
> > libevdev_uinput_write_event(uinput, EV_REL, REL_X, -1);
> > libevdev_uinput_write_event(uinput, EV_SYN, SYN_REPORT, 0);
> > ..
> > libevdev_uinput_destroy(uinput);
> 
> The problem with this approach is that its no longer possible to use the
> litest_touch_down, litest_touch_up etc any more. Especially for touch
> events thats an annoyance to reimplement in the test case. We could add
> helpers for that but then we'd have double set of helpers for every kind
> of event we want to test.

how many devices are we talking about here. You're specifically creating a
test device here that has one functionality that matters: a lot of slots.
how many more devices do we expect similar to this?

IMO at least for this case it's worth writing the extra couple of lines to
have a custom device. Once we get past the number of devices we can look
again to see if we have some sort of common denominator.

also, litest_touch_down/up are already problematic. e.g. they don't release
BTN_TOUCH or BTN_TOOL_FINGER because nothing refcounts the touches. they
only solve the minimal test cases so far but the test suite needs a bit more
work to be useful on a more general basis.

> The way I'd want to use something like this is to create a fake device,
> possibly with some special parameters, and then use it in the same way
> I'd use a "normal" test device. I'd rather have a way to somehow create
> a special fake device that can be operated in the same way using the
> same functions as a "normal" fake device.

the problem I see is with the special parameters. by the time you allow for
all of them you end up re-implementing the current uinput API. e.g. your
last device needed lots of slots, but what if the next device needs
special pressure? which is exactly what I expect to be the next problem for
the touchpad tests.

I just start at the device description files and with the patch applied they
are now little more than static descriptions of device capabilities with the
odd for loop to write arrays out. Maybe a solution to this is to make it
static but better exposed that you can literally take a device, adjust a few
nobs in the cabability bits and then create it. Would that help?

Cheers,
   Peter