Re: [RFC] Adding BTN_TOOL_TOUCH to input.h

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Tue, Nov 23, 2010 at 10:55:56PM -0600, Chris Bagwell wrote:
> 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

BTN_TOUCH means something (we do not specify what) touches working
surface.

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

In Synaptics BTN_TOUCH was used for legacy clients not understanding
BTN_TOOL_FINGER/ABS_PRESSURE (read: mousedev) and had arbitrary pressure
thresholds.

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

And the expected action when you actually using the tool.

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

Huh? I want to reiterate that I do not see any difference between
proposed BTN_TOOL_TOUCH and existing BTN_TOOL_FINGER - both indicate
that a finger either touches or is in proximity of the working surface.

The only difference between tablet, touchcsreen and touchpad is how we
react to the same data (i.e. relative/absolute movement; pointer
tracking or not, etc).

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

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