lkml.org 
[lkml]   [2010]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: input: mt: Software finger tracking in the kernel?
    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


    \
     
     \ /
      Last update: 2010-03-20 23:01    [W:2.595 / U:0.400 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site