On Wed, Oct 13, 2010 at 11:21 AM, Henrik Rydberg <rydberg@xxxxxxxxxxx> wrote: > > In the language of ABS_MT, there is a distinction between slot and id. The slot > is the handle used to communicate a unique touch. The id is the identifier of > that touch. The device tells us how many slots we have. The range of ids is in > principle infinite. In practice, it is set to a large number. > > To answer a possible follow-up question: from the tracking id, you can tell if a > contact is present, if it is new, and if it is older than another contact. I see. Somehow I remember tracking ID is the ID from the hardware/firmware. >>> + >>> + input_report_key(input, BTN_LEFT, (data[1] & 0x08) != 0); >>> + input_report_key(input, BTN_FORWARD, (data[1] & 0x04) != 0); >>> + input_report_key(input, BTN_BACK, (data[1] & 0x02) != 0); >>> + input_report_key(input, BTN_RIGHT, (data[1] & 0x01) != 0); >> >> This implementation impairs the value of those buttons since I know a >> lot of users want them configurable. If we can not or do not pass a >> generic set to the userland, we will need to make it configurable in >> the kernel driver as Dmitry suggested (if I remember it correctly). >> Which approach, in the userland or the kernel, do you like, Henrik? > > Perhaps I should not remind you that the current code was your suggestion. ;-) Yes, I remember that. TBH, I did not want to open another can of worms then. And I did not have time to care about where that train went :). > In my mind, these are buttons just like the buttons on any mouse or trackpad. For this particular model, it might be fine. My concern is for the other models. > Regarding remapping, I think it matters if buttons have strong or weak semantics. Supporting button remapping is not a question. It is a decision. The question is how. I hate to open this can of worms even now. But, we do have to face the reality. Currently, I use BTN_TOOL_FINGER to group those buttons together and to pass them to the userland. This has never been an issue before MT became such a hot topic. Now, we need to EITHER choose a new BTN_TOOL_something to pass the poor buttons to the userland OR use the kernel approach that Dmitry suggested. I am open to all suggestions although I feel passing the buttons to the userland is a better/cleaner solution. My goal is to get a consensus so no one can blame me or the maintainer for the decision :). Fair? Ping -- 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
