Re: [RFC] Adding BTN_TOOL_TOUCH to input.h

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux