Rafi Rubin wrote:
[...]

quoted text
>>> 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

--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/