Re: [RFC] Adding BTN_TOOL_TOUCH to input.h

[Chris Bagwell <chris@cnpbagwell.com>]

On Tue, Nov 23, 2010 at 8:52 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Tue, Nov 23, 2010 at 02:40:00PM -0800, Ping Cheng wrote:
>> On Tue, Nov 23, 2010 at 2:30 PM, Dmitry Torokhov
>> <dmitry.torokhov@gmail.com> wrote:
>> > On Tue, Nov 23, 2010 at 12:48:07PM -0800, Ping Cheng wrote:
>> >> Hi all,
>> >>
>> >> I am not going to write a patch for this request before I get the
>> >> permission for the new tool type. It affects all touch screen devices
>> >> (under drivers/input/touchscreen) that support both pen and touch.
>> >>
>> >> Right now, in the user land, BTN_TOUCH is used to indicate a single
>> >> touch events. BTN_TOUCH and !BTN_TOOL_PEN
>> >> (http://udev.sourcearchive.com/documentation/161-1/input__id_8c-source.html)
>> >> are used to determine if the device is a touch screen device or not a
>> >> pen. With both pen and touch on the same logical port (serial touch
>> >> screen with pen and touch enabled, refer to wacom_w8001.c), BTN_TOUCH
>> >> and !BTN_TOOL_PEN will always be false, which indicates a
>> >> non-touchscreen device. That is wrong.
>> >>
>> >> Unless we have other means to tell the user land a device is a
>> >> touchscreen, BTN_TOUCH with !BTN_TOOL_PEN won't do the job for us.
>> >>
>> >> I've already had a value for the new type:
>> >>
>> >> +#define BTN_TOOL_TOUCH       0x149
>> >>
>> >> This new type resolves the confusion we had for the existing serial
>> >> pen and touch enabled touchscreen devices. Considering we are merging
>> >> the two logical ports for USB devices, the new type is required for
>> >> the future USB touchscreen support as well.
>> >
>> > How is BTN_TOOL_TOUCH is different from BTN_TOOL_FINGER?
>>
>> Good question.
>>
>> BTN_TOOL_FINGER is used for touchpad or trackpad, or whichever term
>> that works for you. It indicates a relative cursor movement. The touch
>> screen needs to translate the (x,y) events into absolute movement.
>> That's why none of those touchscreen drivers use BTN_TOOL_FINGER so
>> far.
>>
>
> BTN_TOOL_FINGER and the new BTN_TOOL_TOUCH convey the same data to the
> userspace, namely that there is a finger on the owrking surface, as
> oopsed to pen, mouse, lens or something else. It does not dictate how
> exactly the data should be used, although right now we have heuristic to
> decide the class of the device we are dealing with.

I've a small clarification for readers that might not be aware.  For
BTN_TOOL_FINGER, its still used to mean a kinda of "in proximity of
surface" and BTN_TOUCH is used when actually touching touchpad.  For
touchpad, those two things probably should follow each other... but as
an example the synaptics driver only sets BTN_TOOL_FINGER immediately
but BTN_TOUCH when pressure is over some threshold.  So there is a
time period when they do not match.

Touchscreens today can only send BTN_TOUCH event... which is a little
odd but works.

>
> It looks like that we getting into fuzzy area where it is hard to
> classify the device solely by its capabilities. Maybe it is time we
> revisited the topic of adding "flags" or "hint" to the device to
> describe it's main purpose(s).
>

I think the proposed BTN_TOOL_TOUCH is in the same spirit of most
other BTN_TOOL_*'s.

We seem comfortable that userland wants to know difference between pen
and eraser tools.  The only thing unique they bring to table is a type
of resolution (fine tip vs. blunt tip) as well as an indication of
tool switching.

I'm not sure we needed 8 tools to express resolution concepts or tool
switching concepts but we do have them.

To me, the BTN_TOOL_TOUCH fits in just fine with this.  It says its
low resolution like both BTN_TOOL_ERASER and BTN_TOOL_FINGER say to
different degrees.  But it also says that, unlike BTN_TOOL_FINGER, it
has touchscreen visibility going for it to replace missing
in-proximity concept and effectively increase its resolution... and so
you do not need to revert to relative emulation.

As the udev input-id shows, I think we have pretty firm class of
devices and it seems touchscreens are only ones not cleanly defined.
It does show something is clearly missing from kernel side.

Mice - BTN_TOOL_MOUSE or anything that only has REL_* events.
Touchpads - BTN_TOOL_FINGER
Tablets - BTN_TOOL_PEN
Touchscreens - fall threw case if you don't find above.

it seems BTN_TOOL_TOUCH(screen) is probably only needed/missing value.
 Are there other major classes that are not just combo devices?  I
guess my point is it looks like we will not need to keep extending
BTN_TOOL_ for device classes over time.

Adding a new BTN_TOOL_TOUCH sure is less disrupted to userland  as we
start to expand to support combo pen+touch devices.

If we took the flags/hint approach then BTN_TOOL_FINGER becomes pretty
meaningless for both touchpads and touchscreens.

I do also want to discuss if its OK to send BTN_TOOL_FINGER=1 and
BTN_TOOL_DOUBLETAP/TRIPLETAP=1 at same time and also proper way to
send DOUBLETAP/TRIPLETAP on touchscreens since they can't use
BTN_TOOL_FINGER today... but I'll save that for a new thread. :-)

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