Messages in this thread | | | Date | Fri, 09 Apr 2010 00:12:49 +0200 | From | Henrik Rydberg <> | Subject | Re: [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
| |