On Wed, Oct 13, 2010 at 1:50 PM, Chris Bagwell <chris@xxxxxxxxxxxxxx> wrote: > 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. You get my vote for both kernel and userland approaches, Chris. > 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. Let's see what the others are thinking.... 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
