[RFC libinput] tools: add a tool for GUI-based debugging

[Peter Hutterer]

On 27/05/2014 18:09 , Jonas Ådahl wrote:
> On Tue, May 27, 2014 at 04:45:42PM +1000, Peter Hutterer wrote:
>> Looking at debugging output is nice but not useful when testing for the feel
>> of a device. Add a tool that presents a canvas and draws the various events
>> onto it.
>> ---
>> Still a bit rough and doesn't handle button/key events yet but it makes
>> testing changes a lot easier (especially for pointer motion and scrolling).
>> I take suggestions for a less silly name.
>>
>> To quit, hit escape.
>
> I don't have much opinion about adding a tool like this, but for the
> record, the tools I use to debug "the feel" of the device is weston +
> weston-clickdot. What it does is more or less draw a line for every
> motion vector, and a little circle cross thingy where you clicked last.
> This way you get to see the movement you made, which has been quite
> helpful, and actually testing it through a real use case (via a Wayland
> compositor for example) might be more accurate.

I've been testing with the xorg libinput driver which is just a thin 
shell around libinput. the problem is though that especially for 
tweaking parameters restarting the session all the time is painful and 
unnecessary. And I want the information that comes out of libinput 
directly to make sure the compositor/xorg/toolkit doesn't modify or drop 
anything.

it doesn't replace real testing of course.

> I don't know about it being 'auto', as I have a vague memory of
> packagers not really appreciating less deterministic building,
> especially when it means extra dependencies. It might not be an issue at
> all, just wanted to point it out.

it can be enabled/disabled on demand if you want predictable building. I 
just didn't think requiring cairo and xlib for libinput is necessary and 
I don't want to go through the hassle of running configure twice every 
time because I forget to enable it myself.

> Another comment is, it looks quite X11:y. Why not just use a toolkit
> abstracting away that layer, so that using it from within a Wayland
> compositor would mean less porting?

I'll look into that. I had most of this already lying around so 90% of 
the work was hooking it up to libinput. This patch is less than 2 hours 
work I think.

Cheers,
   Peter