On Wed, Oct 13, 2010 at 1:50 PM, Chris Bagwell [off-list ref] wrote:

On Wed, Oct 13, 2010 at 3:15 PM, Ping Cheng [off-list ref] wrote:

quoted

On Wed, Oct 13, 2010 at 11:21 AM, Henrik Rydberg [off-list ref] wrote:

quoted

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.

quoted

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html