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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
