Message-ID: <AANLkTimht8osNw=L+1TkhYOW5AafQDPBX64Xa1qBbdfP@mail.gmail.com>
Date:	Tue, 23 Nov 2010 16:12:13 -0800
From:	Ping Cheng <pinglinux@...il.com>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	linux-kernel@...r.kernel.org, jkosina@...e.cz
Subject: Re: [PATCH] Add BTN_TOOL_BUTTONS to input.h

On Tue, Nov 23, 2010 at 2:24 PM, Dmitry Torokhov
<dmitry.torokhov@...il.com> wrote:
>
>> > The BTN_TOOL_* were introduced to indicate to the userspace tool that is
>> > currently touching the surface of the device. Buttons are expected to be
>> > always present and can change their state regardless of what tool is
>> > being used at the moment. I.e. The full hardware state (between
>> > EV_SYN/SYN_REPORT) could be, for example,
>> >
>> > Pen at 10,20, BTN_0, and BTN_2 (ABS_X 10, ABS_Y 20, BTN_TOOL_PEN, BTN_0,
>> > BTN_2) or
>> >
>> > Lens at 20,15 and BTN_1 (ABS_X 20, ABS_Y 15, BTN_TOOL_LENS, BTN_1).
>> >
>> > As you can see BTN_* events can accompany either BTN_TOOL_LENS or
>> > BTN_TOOL_PEN or any other BTN_TOOL_*.
>>
>> You are right. The tablet buttons can go with one of those other
>> BTN_TOOL_s _if_ they do not define the same event types (BTN_s) as the
>> tablet buttons.
>>
>> The new Bamboo MT code sends both BTN_LEFT and BTN_RIGHT events for
>> Tablet Buttons (refer to line 905 and 908 of wacom_wac.c). However,
>> BTN_LEFT and BTN_RIGHT are also sent by BTN_TOOL_MOUSE/LENS tool
>> (refer to wacom_wac.c line 622 to 665).
>>
>> If we remove BTN_TOOL_FINGER without a BTN_TOOL-something to replace
>> it, the two LEFT and RIGHT buttons will have a hard time to tell the
>> user land if they are from the MOUSE/LENS or the Tablet Buttons. The
>> worst case could be the LEFT/RIGHT sent later overwrites the earlier
>> ones.
>>
>> We could do some guesswork in the user land to figure out which
>> LEFT/RIGHT belongs to which BTN_TOOL_ if the above scenario does not
>> happen. But, it would be much cheaper and more reliable if we can tell
>> the user land where those LEFT and RIGHT come from. This is the whole
>> purpose of the kernel driver, isn't it?
>
> What would userspace want to figure what physical button was pressed?
> Input events convey _actions_, i.e. BTN_LEFT means that user pressed
> primary button on the device. It does not matter if it was pressed on
> tablet or the mouse/lens; the response should be the same.

You're right, if the user wants a LEFT click. In a lot of cases, they
want to translate it into something else. LEFT is only a default value
that we give them if they do nothing.

> If you expect different response, depending on which physical button is
> pressed, then they should emit different BTN_* events. If you are
> concerned that some users might want to have the same actions while
> others want different actions - then please implement key remapping in
> the driver.

That is exactly what I am trying to convince you. Without being able
to tell one button event from the other, even just logically, how can
I and other clients remap them?

> If you want to treat touch and pen as completely independent devices -
> we can do that too but as you remember there are some issues with
> "pairing" of the devices.

No, this issue has nothing to do with separating pen and touch
devices. This is for BUTTONS only. Those button events can come from
the physical tools (pen, mouse, lens, etc.) or the tablet itself.
Without knowing that the button events are from the ones that
physically sit on the tablet, it may mess up with the buttons that are
from the physical tools.

You might have mixed my BTN_TOOL_TOUCH request with this patch.

Ping
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists