Message-ID: <20101123222458.GB20283@core.coreip.homeip.net>
Date:	Tue, 23 Nov 2010 14:24:59 -0800
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Ping Cheng <pinglinux@...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 09:40:19AM -0800, Ping Cheng wrote:
> On Sun, Nov 21, 2010 at 11:55 PM, Dmitry Torokhov
> <dmitry.torokhov@...il.com> wrote:
> > Hi Ping,
> >
> > On Thu, Nov 18, 2010 at 04:25:35PM -0800, Ping Cheng wrote:
> >> We "borrowed" BTN_TOOL_FINGER from input/mouse to pass tablet
> >> buttons to the user land. This has not been an issue since
> >> tablet was not considered as a mouse replacement. With the
> >> introduction of hybrid digitizer and touch devices, the tool
> >> type is causing confusion. A new tool type is due for the
> >> well-being of future input device drivers.
> >>
> >
> > I am sorry but I do not understand the reasoning behind
> > BTN_TOOL_BUTTONS.
> 
> Don't be sorry, Dmitry. Your statement is fair since:
> 
> 1.  I did not explain it clearly;
> 2.  You do not have the physical device (Intuos series) to test with.
> 
> I'll explain it again by refering back to the code to see if I can
> make it clear or not. The code I am going to refer to is under the
> Linus tree at git.kernel.org.
> 
> > 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.

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.

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.

Thanks.

-- 
Dmitry
--
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