lkml.org 
[lkml]   [2010]   [Apr]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] input: mt: introduce MT event slots
Rafi Rubin wrote:
[...]

>>> Is there any particular downside to defaulting to implicit slot ids?
>> Yes. The device driver should not have to update every slot between
>> synchronizations, or the point would be lost.
>>
>>> For drivers/hardware that don't handle tracking, SYN_MT_REPORT could
>>> just result in dev->slot++ and a SYN_REPORT resets dev->slot to 0;
>> Drivers that do not handle tracking should not use the slots at all. The slot
>> concept requires that whatever gets communicated over it is identifiable, or
>> else it would not be possible to send changes. Drivers without tracking
>> capabilities should stick to the current MT protocol, for which it was designed.
>
> That's unfortunate.
>
> I think tracking upsets are generally quite rare (at least for the n-trig
> hardware), and we would see most of the benefit of jitter and bandwidth
> reduction even if we use contact ordering for slots. Tracking upsets would
> still flow downstream, a large state change should cause the slot to emit the
> new position.
>
> I was also hoping the slotting mechanism might be a good place to inject generic
> tracking support later.

But it is! It was not my intention to discourage the slot protocol for a driver
that *wants* to track contacts, only the ones that do not. As you already
guessed, there is a natural migration path towards using the slot extension and
kernel-provided software finger tracking.

Cheers,
Henrik



\
 
 \ /
  Last update: 2010-04-09 00:15    [W:0.141 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site