On Wed, Oct 13, 2010 at 3:15 PM, Ping Cheng <pinglinux@xxxxxxxxx> wrote: > On Wed, Oct 13, 2010 at 11:21 AM, Henrik Rydberg <rydberg@xxxxxxxxxxx> wrote: >> 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? > Let me first throw out that I think the kernel side solution can be complementary to user side solutions as well. We may wish to do it in both places. I plan to have some patches to xf86-input-wacom in next week or so related to this topic. One thing on kernel side is we should try to keep two set classes of buttons and not mix their meanings to help out user land. 1) Those buttons that are known to be located on a stylus (BTN_STYLUS and BTN_STYLUS2) 2) Those buttons that are part of a tablet/touchpad (BTN_LEFT/BTN_RIGHT/etc). For class #1, there is an implied meaning that when tool goes out of proximity that its buttons also go out of proximity (user land is required to do button releases for some known cases the kernel driver doesn't clear class #1 buttons). For class #2, they are just always there and have valid meaning. So my point is keep in mind to not use, for example, BTN_STYLUS for buttons that should always work. For Bamboo Touch, I think we chose class #2 BTN_* for tablet buttons which will help us in user land. My basic plan for xf86-input-wacom is to decide on a per event which tracking buffer to store event in instead of deciding per sync window as its done today. For class #1 events, it will be stored like today. For class #2 buttons/events, it will be stored in buttons buffer (which happens to already exists) as if BTN_TOOL_FINGER was sent. Then 1 or 2 buffers are posted each sync window depending on which were updated. Its my same basic plan for 2nd finger of MT as well which means between 1 and 3 buffers will be posted each sync window. If this approach is accepted then you get normal xf86-input-wacom button remapping features. Chris -- 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
