[RFC evemu] Record active slots in syn report comments

[Peter Hutterer]

Sorry for they delay, I was on vacation.

On Tue, Sep 22, 2015 at 11:25:04AM -0400, Benjamin Tissoires wrote:
> Hi Daniel,
> 
> On Tue, Sep 22, 2015 at 5:28 AM, Daniel Martin <consume.noise at gmail.com> wrote:
> > Hi,
> >
> > I've hacked up a patch for evemu to print the active slots in addition
> > to the syn report. I did this to see ghost reports much more easy.
> > Scrolling through the report log was to error prone for me. It basicly
> > looks like:
> >     E: 12.345678 0000 0000 0000 # ------------ SYN_REPORT (0)
> > ---------- 1234ms 0[12] 3[45]
> > Here slot 0 (tracking id 12) and slot 3 (tracking id 45) are active.
> 
> I am not particularly a big fan of this. Especially because it feels
> like opening a can of worms. People will also want to have a full
> state of the buttons for instance. In addition, the syntax is not that
> easy to follow and I feel like it will just confuse users.

I agree with Benjamin here. Tracking the state of a device is a bit more
context-specific than I'd like evemu to be, staying simple here is a lot
better.

> For debugging multitouch devices (and stuck fingers), I just use
> mtdiag-qt (https://github.com/bentiss/mtdiag-qt). If there is a ghost
> dot, mtdiag-qt will show it (though you won't have the tracking id
> here).
> 
> Also, for debugging your specific ghosts, I think a simple python
> script with the python evemu interface should be enough.

https://github.com/whot/input-data-analysis/tree/master/per-slot-deltas
is probably a good start

> >
> > Atm. evemu is agnostic to any state, adding this would change this.
> > But, imho it's a nice debugging feature. Would this be acceptable?
> > Then I'll try to make the patch pretty and send it.
> >
> 
> Sorry, but that's a NACK from me. I'd prefer having no state in evemu,
> or we will end up in having a libinput like tool and the evemu-record
> will not make any sense at all (I mean, we won't be able to trust it
> as the output that is coming out of the kernel).
> But if others really want it, I can always change my mind.

NAK++ :)

sorry

Cheers,
   Peter