Re: input: mt: Software finger tracking in the kernel?

[Henrik Rydberg <rydberg@euromail.se>]

Dmitry Torokhov wrote:
> Hi Henrik
[...]
> I am not sure if input core itself is the proper place to do such
> thing, I'd envisioned something more like a library providing common
> code that drivers could opt in to use, like we hane ff-memless for
> memory-less force-feedback devices.
> 
> Does it make any sense? I guess post the skeleton of the code and we can
> discuss further.

Yes, input core as in input*.c might be wrong. The big thing is that the events
most likely have to be deferred to the bottom half. Otherwise, the scheme would
have fit rather nicely on top of the current filtering in input_device. The
ideas I am currently looking at are:

1. Expand on the new event filtering mechanism, providing a sort of rewrite
functionality which can schedule events for later injection into the event stream.

2. Add additional logic to evdev so that it buffers MT events and flushes the
reworked events directly onto the clients.

3. Add a new multitouch handler, mtdev, which by default does event deferral,
only emitting events by scheduling them upon SYN_REPORT requests.

To my untrained eye, all three options could be made to work with acceptable
latency. Number three probably means applications (read X) have to keep open
both evdev and mtdev, which might be confusing. Number one is quite general, but
probably contains hidden (to me) difficulties. Number two sounds pretty
straight-forward, although tapping into the code somewhat through the back door.

Henrik