[RFC] Adding BTN_TOOL_TOUCH to input.h

[RFC] Adding BTN_TOOL_TOUCH to input.h

[Ping Cheng]

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.

Thank you for reading and your timely comments would be greatly appreciated.

Ping

Re: [RFC] Adding BTN_TOOL_TOUCH to input.h

[Dmitry Torokhov]

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?

-- 
Dmitry

Re: [RFC] Adding BTN_TOOL_TOUCH to input.h

[Ping Cheng]

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.

Any more questions ;)?

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

Re: [RFC] Adding BTN_TOOL_TOUCH to input.h

[Dmitry Torokhov]

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.

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Adding BTN_TOOL_TOUCH to input.h

[Chris Bagwell]

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

Re: [RFC] Adding BTN_TOOL_TOUCH to input.h

[Dmitry Torokhov]

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

Re: [RFC] Adding BTN_TOOL_TOUCH to input.h

[Chris Bagwell]

On Wed, Nov 24, 2010 at 2:26 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> 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:
>> >> > 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.

Does this mean BTN_TOUCH is optional for absolute devices (tablets and
touchpads)?  Its not for touchscreens simply because its defacto event
used were other devices use BTN_TOOL_*.

Probably we should document this stuff, similar to how MT did, for
common understanding.  I may be up for that task soon.

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

Agree.  Its important point that happens to be in line with why I like
BTN_TOOL_TOUCH concept.  More below.

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

Let me give an example of drawing program and worst case where all
major device classes are merged in single input device.  The input has
pen/eraser/touchscreen/touchpad/mouse and user expected behavior.
All tools except mouse share ABS_X/Y/PRESSURE and BTN_TOUCH.   Mouse
uses REL_* events.

* BTN_TOOL_PEN - Small point pen with black ink.  Draws upon BTN_TOUCH
or ABS_PRESSURE.
* BTN_TOOL_ERASER - Large point pen with white ink (simple erase
concept).  Draws upon BTN_TOUCH or ABS_PRESSURE.
* BTN_TOOL_TOUCH - Large point pen with black ink.  Draws upon
BTN_TOUCH or ABS_PRESSURE.
* BTN_TOOL_FINGER - Small (maybe) point pen with black ink.  Only
moves cursor with BTN_TOUCH or ABS_PRESSURE.  No drawing unless
BTN_RIGHT clicked.
* BTN_TOOL_MOUSE - Small (maybe) point pen with black ink.  Only moves
cursor on REL_ events.  No drawing unless BTN_RIGHT clicked.  <-- this
is existing wacom example.  If reports ABS_* then it would probably
use BTN_TOOL_FINGER tool even though a mouse puck.

Notice how expected behavior of touchscreen is so close to tablet
tools.  TOUCH is just a complement tablet tool in same way ERASER is
complement to PEN.  Touchpads are so unique in how they behave that I
think they deserve their own tool type.

Your point about only the "how to react" being different between
touchpad and touchscreen is also true for all tools above.  I'm not
sure why your limiting comment and not including tablet and mice
tools.  We could switch to BTN_TOOL_1/2/3/4 and some sort of per tool
hint (BTN_TOOL_CAPABILITIES sent with tool events perhaps?) but I'm
not real excited about work involved in userland for that.

If your still not convinced on BTN_TOOL_TOUCH (I've not really
mentioned much new info) then can you give rough ideas of what flags
interface should look like?

For example, should it be sent as BTN_TOOL_CAPABILITIES event for each
tool change?  Or should it be an ioctl() per BTN_TOOL_*?  The former
is good if we think BTN_TOOL_*'s will use tool ID's and two tools may
have different capabilities.

Once solved for ST, it also needs solution for MT.  For slot based MT,
it may need to be sent as events if we allow tools to float between
slots.

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

Re: [RFC] Adding BTN_TOOL_TOUCH to input.h

[Dmitry Torokhov]

On Wed, Nov 24, 2010 at 04:55:32PM -0600, Chris Bagwell wrote:
> On Wed, Nov 24, 2010 at 2:26 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > 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:
> >> >> > 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.
> 
> Does this mean BTN_TOUCH is optional for absolute devices (tablets and
> touchpads)?  Its not for touchscreens simply because its defacto event
> used were other devices use BTN_TOOL_*.

BTN_TOUCH is not optional in the sense that legacy (or simplest) clients
use it to recoginze the touch. For example mousedev does this, so if you
were to remove BTN_TOUCH from touchpad drivers mousedev (and thus GPM)
would stop working.

> 
> Probably we should document this stuff, similar to how MT did, for
> common understanding.  I may be up for that task soon.

That would be great.


> 
> >
> >>
> >> 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.
> 
> Agree.  Its important point that happens to be in line with why I like
> BTN_TOOL_TOUCH concept.  More below.
> 
> >
> >>
> >> 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).
> >
> 
> Let me give an example of drawing program and worst case where all
> major device classes are merged in single input device.  The input has
> pen/eraser/touchscreen/touchpad/mouse and user expected behavior.

This is a faulty assumption as I do not see how you could come across
such a beast. Touchscreens, tablets and touchpads are different devices
and require different handling:

- touchpads require conversion from absolute to relative movement, and
  movement causes on-screen pointer movement;

- tablets (unless we are talking about wacom mouse tool which is
  special) operate in absolute coordinates but still require on-screen
  pointer movement;

- touchscreens work in absolute coordinates and do not require pointer
  tracking as your tool (finger, stylus) serves as a pointer.

While I can see manufacturers packaging let's say touchscreen and a
touchpad into a single chip solution we should not try to jam them all
together into single logical input device but rather split them
accordingly (based on work surface for example).

Given that you won't ever have to deal with something that is
touchscreen, tabled and touchpad at once the rest of your example is not
interesting.

> All tools except mouse share ABS_X/Y/PRESSURE and BTN_TOUCH.   Mouse
> uses REL_* events.
> 
> * BTN_TOOL_PEN - Small point pen with black ink.  Draws upon BTN_TOUCH
> or ABS_PRESSURE.
> * BTN_TOOL_ERASER - Large point pen with white ink (simple erase
> concept).  Draws upon BTN_TOUCH or ABS_PRESSURE.
> * BTN_TOOL_TOUCH - Large point pen with black ink.  Draws upon
> BTN_TOUCH or ABS_PRESSURE.
> * BTN_TOOL_FINGER - Small (maybe) point pen with black ink.  Only
> moves cursor with BTN_TOUCH or ABS_PRESSURE.  No drawing unless
> BTN_RIGHT clicked.
> * BTN_TOOL_MOUSE - Small (maybe) point pen with black ink.  Only moves
> cursor on REL_ events.  No drawing unless BTN_RIGHT clicked.  <-- this
> is existing wacom example.  If reports ABS_* then it would probably
> use BTN_TOOL_FINGER tool even though a mouse puck.
> 
> Notice how expected behavior of touchscreen is so close to tablet
> tools.  TOUCH is just a complement tablet tool in same way ERASER is
> complement to PEN.  Touchpads are so unique in how they behave that I
> think they deserve their own tool type.

No, they deserve to be handled differently (as I outlined above) but the
tool is still the same. It is your finger. If it was a different tool
that would mean that there could be a device that supports both
BTN_TOOL_FINGER and BTN_TOOL_TOUCH. Now how would you differentiate
between them? When use one and when the other (given that it is
physically the same object touching the device)?

> 
> Your point about only the "how to react" being different between
> touchpad and touchscreen is also true for all tools above.  I'm not
> sure why your limiting comment and not including tablet and mice
> tools.  We could switch to BTN_TOOL_1/2/3/4 and some sort of per tool
> hint (BTN_TOOL_CAPABILITIES sent with tool events perhaps?) but I'm
> not real excited about work involved in userland for that.
> 
> If your still not convinced on BTN_TOOL_TOUCH (I've not really
> mentioned much new info) then can you give rough ideas of what flags
> interface should look like?
> 
> For example, should it be sent as BTN_TOOL_CAPABILITIES event for each
> tool change?  Or should it be an ioctl() per BTN_TOOL_*?  The former
> is good if we think BTN_TOOL_*'s will use tool ID's and two tools may
> have different capabilities.

No, the hint or flags or type is per device. So you'd do:

	ioctl(fd, EVIOCGDEVTYPE, &type);

when you notified about a new device and it would return a bitmap of all
that it could be, like INPUT_TYPE_TOUCHSCREEN or INPUT_TYPE_TABLET. And
then you'd know how to deal with that device.

> 
> Once solved for ST, it also needs solution for MT.  For slot based MT,
> it may need to be sent as events if we allow tools to float between
> slots.
> 

I do not see how that involves ST vs MT at all.

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

Re: [RFC] Adding BTN_TOOL_TOUCH to input.h

[Henrik Rydberg]

Hi,

Reading through this thread, I think Dmitry's EVIOCGDEVTYPE is a great way to
resolve this. We should expect some changes in userland to correctly interpret
direct/indirect devices, and this seems a good way to go. The physical size of
the surface would also be great to retrieve this way. The recent resolution
addition is semantically odd, since we have only one physical surface, not one
per axes.

In short, my suggestion is to build a struct for device properties, like this:

struct input_devinfo {
	__u32	type;			/* bitmask of possible dev types */
	__u32	capabilities;		/* bitmask of special device caps */
	__u32	phys_abs_width;		/* physical width of surface (mm) */
	__u32	phys_abs_height;	/* physical height of surface (mm) */
};

Adding more stuff here seems plausible. For instance, special devices like
clickpads or integrated buttons would fit nicely in capabilities. The call would
be very similar, like

	ioctl(fd, EVIOCGDEVINFO, &info);

What do you think?

Cheers,
Henrik

Re: [RFC] Adding BTN_TOOL_TOUCH to input.h

[Nikolai Kondrashov]

On 11/25/2010 05:05 PM, Henrik Rydberg wrote:
> 	__u32	phys_abs_width;		/* physical width of surface (mm) */
> 	__u32	phys_abs_height;	/* physical height of surface (mm) */
This is better and is already covered by input_absinfo.
You could calculate it with (maximum - minimum) / resolution.

Sincerely,
Nick

Re: [RFC] Adding BTN_TOOL_TOUCH to input.h

[Chris Bagwell]

On Wed, Nov 24, 2010 at 7:31 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Wed, Nov 24, 2010 at 04:55:32PM -0600, Chris Bagwell wrote:
>> >
>> >>
>> >> 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.
>>
>> Agree.  Its important point that happens to be in line with why I like
>> BTN_TOOL_TOUCH concept.  More below.
>>
>> >
>> >>
>> >> 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).
>> >
>>
>> Let me give an example of drawing program and worst case where all
>> major device classes are merged in single input device.  The input has
>> pen/eraser/touchscreen/touchpad/mouse and user expected behavior.
>
> This is a faulty assumption as I do not see how you could come across
> such a beast. Touchscreens, tablets and touchpads are different devices
> and require different handling:
>
> - touchpads require conversion from absolute to relative movement, and
>  movement causes on-screen pointer movement;
>
> - tablets (unless we are talking about wacom mouse tool which is
>  special) operate in absolute coordinates but still require on-screen
>  pointer movement;
>
> - touchscreens work in absolute coordinates and do not require pointer
>  tracking as your tool (finger, stylus) serves as a pointer.
>
> While I can see manufacturers packaging let's say touchscreen and a
> touchpad into a single chip solution we should not try to jam them all
> together into single logical input device but rather split them
> accordingly (based on work surface for example).
>
> Given that you won't ever have to deal with something that is
> touchscreen, tabled and touchpad at once the rest of your example is not
> interesting.

Hmmm.  Let me start of easy part.  Having touchpad+touchscreen on
single input doesn't make sense even though it was in my example.  I
agree with that.  The rest are valid examples that exist today.

touchscreen/wacom_w8001.c is example of serial device (1 input device
to user) that has tablet features (BTN_TOOL_PEN and BTN_TOOL_FINGER)
and touchscreen touch.  Today its playing some games and not sending
BTN_TOOL_FINGER events to prevent device from being directed to
xf86-input-synaptics.  This can be fixed after thread is finalized.

We have Wacom Bamboo's (tablet/wacom_wac.c) that have tablet features
(BTN_TOOL_PEN and BTN_TOOL_ERASER) on 1 input device and touchpad
feature (BTN_TOOL_FINGER) on another input device.  On another thread,
we talked about merging these into 1 logical input device because it
eases filtering those BTN_TOOL_FINGER events while user is using
stylus and resting hand on tablet.

Also, Wacom Tablet PC's (tablet/wacom_wac.c) and hid-ntrig.c have
tablet (BTN_TOOL_PEN and BTN_TOOL_ERASER) and touchscreen (BTN_TOUCH).
  These could be combined and the Wacom Tablet PC's events should be
modified to look closer to hid-ntrig.c... although hid-ntrig.c also
isn't sending BTN_TOOL_FINGER for xf86-input-synaptics reasons.
.
>
>> All tools except mouse share ABS_X/Y/PRESSURE and BTN_TOUCH.   Mouse
>> uses REL_* events.
>>
>> * BTN_TOOL_PEN - Small point pen with black ink.  Draws upon BTN_TOUCH
>> or ABS_PRESSURE.
>> * BTN_TOOL_ERASER - Large point pen with white ink (simple erase
>> concept).  Draws upon BTN_TOUCH or ABS_PRESSURE.
>> * BTN_TOOL_TOUCH - Large point pen with black ink.  Draws upon
>> BTN_TOUCH or ABS_PRESSURE.
>> * BTN_TOOL_FINGER - Small (maybe) point pen with black ink.  Only
>> moves cursor with BTN_TOUCH or ABS_PRESSURE.  No drawing unless
>> BTN_RIGHT clicked.
>> * BTN_TOOL_MOUSE - Small (maybe) point pen with black ink.  Only moves
>> cursor on REL_ events.  No drawing unless BTN_RIGHT clicked.  <-- this
>> is existing wacom example.  If reports ABS_* then it would probably
>> use BTN_TOOL_FINGER tool even though a mouse puck.
>>
>> Notice how expected behavior of touchscreen is so close to tablet
>> tools.  TOUCH is just a complement tablet tool in same way ERASER is
>> complement to PEN.  Touchpads are so unique in how they behave that I
>> think they deserve their own tool type.
>
> No, they deserve to be handled differently (as I outlined above) but the
> tool is still the same. It is your finger. If it was a different tool
> that would mean that there could be a device that supports both
> BTN_TOOL_FINGER and BTN_TOOL_TOUCH. Now how would you differentiate
> between them? When use one and when the other (given that it is
> physically the same object touching the device)?
>

I now see I had flawed outlook because I was stuck on udev and
xf86-input-evdev logic to much.  I wanted to send something along with
each tool that said how to treat in terms of historical device
classes.  As example, I wanted to say "Use BTN_TOOL_PEN with logic you
used to use for Tablets." and "Use BTN_TOOL_FINGER with logic you used
to use for touchscreens".  BTN_TOOL_TOUCH was just way of encoding
that extra info without new interface.

Thats why I mentioned per-tool a few times.  Your examples show its
better to say "use this BTN_TOOL_* in whatever way makes sense with
Touchscreen (or whatever physical attribute of HW is)."

Both viewpoints come to same answer in the end but yours is best.  Its
basically 1 value per input device; as you show below.

It doesn't quite work if we have combined touchscreen+touchpad but I
agree that case is probably best to break into 2 input devices.

>>
>> Your point about only the "how to react" being different between
>> touchpad and touchscreen is also true for all tools above.  I'm not
>> sure why your limiting comment and not including tablet and mice
>> tools.  We could switch to BTN_TOOL_1/2/3/4 and some sort of per tool
>> hint (BTN_TOOL_CAPABILITIES sent with tool events perhaps?) but I'm
>> not real excited about work involved in userland for that.
>>
>> If your still not convinced on BTN_TOOL_TOUCH (I've not really
>> mentioned much new info) then can you give rough ideas of what flags
>> interface should look like?
>>
>> For example, should it be sent as BTN_TOOL_CAPABILITIES event for each
>> tool change?  Or should it be an ioctl() per BTN_TOOL_*?  The former
>> is good if we think BTN_TOOL_*'s will use tool ID's and two tools may
>> have different capabilities.
>
> No, the hint or flags or type is per device. So you'd do:
>
>        ioctl(fd, EVIOCGDEVTYPE, &type);
>
> when you notified about a new device and it would return a bitmap of all
> that it could be, like INPUT_TYPE_TOUCHSCREEN or INPUT_TYPE_TABLET. And
> then you'd know how to deal with that device.

Thanks for example.  That cleared up some things in my mind on how you see it.

Chris

>
>>
>> Once solved for ST, it also needs solution for MT.  For slot based MT,
>> it may need to be sent as events if we allow tools to float between
>> slots.
>>
>
> I do not see how that involves ST vs MT at all.
>
> --
> 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

Re: [RFC] Adding BTN_TOOL_TOUCH to input.h

[Chris Bagwell]

On Thu, Nov 25, 2010 at 8:12 AM, Nikolai Kondrashov <spbnick@gmail.com> wrote:
> On 11/25/2010 05:05 PM, Henrik Rydberg wrote:
>>
>>        __u32   phys_abs_width;         /* physical width of surface (mm)
>> */
>>        __u32   phys_abs_height;        /* physical height of surface (mm)
>> */
>
> This is better and is already covered by input_absinfo.
> You could calculate it with (maximum - minimum) / resolution.

On this topic.  I'd like to start reporting resolution for a few wacom
devices.

When I looked at input_absinfo.resolution, I see only synaptics.c is
using it right now and it is defined using units/mm.  Currently, this
makes it up to xf86-input-synaptics were X is fed this value after
converting to units/meter.  Thats my intended usage as well.

I'm more used to values in inches (lpi) or at least something higher
then mm.  If I converted my lpi to mm for resolution I'd lose some
accuracy.

We could solve that a few ways.  Provide units in input_absinfo,
convert to units/inch, units/cm or even units/meter, or define
physical size in mm.

Any preferences?

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

Re: [RFC] Adding BTN_TOOL_TOUCH to input.h

[Dmitry Torokhov]

On Fri, Nov 26, 2010 at 05:02:05PM -0600, Chris Bagwell wrote:
> On Thu, Nov 25, 2010 at 8:12 AM, Nikolai Kondrashov <spbnick@gmail.com> wrote:
> > On 11/25/2010 05:05 PM, Henrik Rydberg wrote:
> >>
> >>        __u32   phys_abs_width;         /* physical width of surface (mm)
> >> */
> >>        __u32   phys_abs_height;        /* physical height of surface (mm)
> >> */
> >
> > This is better and is already covered by input_absinfo.
> > You could calculate it with (maximum - minimum) / resolution.
> 
> On this topic.  I'd like to start reporting resolution for a few wacom
> devices.
> 
> When I looked at input_absinfo.resolution, I see only synaptics.c is
> using it right now and it is defined using units/mm.  Currently, this
> makes it up to xf86-input-synaptics were X is fed this value after
> converting to units/meter.  Thats my intended usage as well.
> 
> I'm more used to values in inches (lpi) or at least something higher
> then mm.  If I converted my lpi to mm for resolution I'd lose some
> accuracy.

Right, with devices that have low accuracy you'd be losing accuracy here
too.

> 
> We could solve that a few ways.  Provide units in input_absinfo,
> convert to units/inch, units/cm or even units/meter, or define
> physical size in mm.

How big is the error and how important is it if we go with option 4 (do
nothing)?

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

Re: [RFC] Adding BTN_TOOL_TOUCH to input.h

[Dmitry Torokhov]

On Fri, Nov 26, 2010 at 04:48:32PM -0600, Chris Bagwell wrote:
> On Wed, Nov 24, 2010 at 7:31 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > On Wed, Nov 24, 2010 at 04:55:32PM -0600, Chris Bagwell wrote:
> >> >
> >> >>
> >> >> 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.
> >>
> >> Agree.  Its important point that happens to be in line with why I like
> >> BTN_TOOL_TOUCH concept.  More below.
> >>
> >> >
> >> >>
> >> >> 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).
> >> >
> >>
> >> Let me give an example of drawing program and worst case where all
> >> major device classes are merged in single input device.  The input has
> >> pen/eraser/touchscreen/touchpad/mouse and user expected behavior.
> >
> > This is a faulty assumption as I do not see how you could come across
> > such a beast. Touchscreens, tablets and touchpads are different devices
> > and require different handling:
> >
> > - touchpads require conversion from absolute to relative movement, and
> >  movement causes on-screen pointer movement;
> >
> > - tablets (unless we are talking about wacom mouse tool which is
> >  special) operate in absolute coordinates but still require on-screen
> >  pointer movement;
> >
> > - touchscreens work in absolute coordinates and do not require pointer
> >  tracking as your tool (finger, stylus) serves as a pointer.
> >
> > While I can see manufacturers packaging let's say touchscreen and a
> > touchpad into a single chip solution we should not try to jam them all
> > together into single logical input device but rather split them
> > accordingly (based on work surface for example).
> >
> > Given that you won't ever have to deal with something that is
> > touchscreen, tabled and touchpad at once the rest of your example is not
> > interesting.
> 
> Hmmm.  Let me start of easy part.  Having touchpad+touchscreen on
> single input doesn't make sense even though it was in my example.  I
> agree with that.  The rest are valid examples that exist today.
> 
> touchscreen/wacom_w8001.c is example of serial device (1 input device
> to user) that has tablet features (BTN_TOOL_PEN and BTN_TOOL_FINGER)
> and touchscreen touch.  Today its playing some games and not sending
> BTN_TOOL_FINGER events to prevent device from being directed to
> xf86-input-synaptics.  This can be fixed after thread is finalized.

*nod*

> 
> We have Wacom Bamboo's (tablet/wacom_wac.c) that have tablet features
> (BTN_TOOL_PEN and BTN_TOOL_ERASER) on 1 input device and touchpad
> feature (BTN_TOOL_FINGER) on another input device.  On another thread,
> we talked about merging these into 1 logical input device because it
> eases filtering those BTN_TOOL_FINGER events while user is using
> stylus and resting hand on tablet.

Is the Bamboo intended to be used as a big touchpad? Or is it still the
tablet that is touch-sensitive? I'd say the 2nd so we should not say
that it has "touchpad feature on the 2nd device". While userspace (and
parts of kernel space) use BTN_TOOL_FINGER to decide that the device
should be treated as touchpad is is simply heuristic.

> Also, Wacom Tablet PC's (tablet/wacom_wac.c) and hid-ntrig.c have
> tablet (BTN_TOOL_PEN and BTN_TOOL_ERASER) and touchscreen (BTN_TOUCH).
>   These could be combined and the Wacom Tablet PC's events should be
> modified to look closer to hid-ntrig.c... although hid-ntrig.c also
> isn't sending BTN_TOOL_FINGER for xf86-input-synaptics reasons.

I see...

> .
> >
> >> All tools except mouse share ABS_X/Y/PRESSURE and BTN_TOUCH.   Mouse
> >> uses REL_* events.
> >>
> >> * BTN_TOOL_PEN - Small point pen with black ink.  Draws upon BTN_TOUCH
> >> or ABS_PRESSURE.
> >> * BTN_TOOL_ERASER - Large point pen with white ink (simple erase
> >> concept).  Draws upon BTN_TOUCH or ABS_PRESSURE.
> >> * BTN_TOOL_TOUCH - Large point pen with black ink.  Draws upon
> >> BTN_TOUCH or ABS_PRESSURE.
> >> * BTN_TOOL_FINGER - Small (maybe) point pen with black ink.  Only
> >> moves cursor with BTN_TOUCH or ABS_PRESSURE.  No drawing unless
> >> BTN_RIGHT clicked.
> >> * BTN_TOOL_MOUSE - Small (maybe) point pen with black ink.  Only moves
> >> cursor on REL_ events.  No drawing unless BTN_RIGHT clicked.  <-- this
> >> is existing wacom example.  If reports ABS_* then it would probably
> >> use BTN_TOOL_FINGER tool even though a mouse puck.
> >>
> >> Notice how expected behavior of touchscreen is so close to tablet
> >> tools.  TOUCH is just a complement tablet tool in same way ERASER is
> >> complement to PEN.  Touchpads are so unique in how they behave that I
> >> think they deserve their own tool type.
> >
> > No, they deserve to be handled differently (as I outlined above) but the
> > tool is still the same. It is your finger. If it was a different tool
> > that would mean that there could be a device that supports both
> > BTN_TOOL_FINGER and BTN_TOOL_TOUCH. Now how would you differentiate
> > between them? When use one and when the other (given that it is
> > physically the same object touching the device)?
> >
> 
> I now see I had flawed outlook because I was stuck on udev and
> xf86-input-evdev logic to much.  I wanted to send something along with
> each tool that said how to treat in terms of historical device
> classes.  As example, I wanted to say "Use BTN_TOOL_PEN with logic you
> used to use for Tablets." and "Use BTN_TOOL_FINGER with logic you used
> to use for touchscreens".  BTN_TOOL_TOUCH was just way of encoding
> that extra info without new interface.
> 
> Thats why I mentioned per-tool a few times.  Your examples show its
> better to say "use this BTN_TOOL_* in whatever way makes sense with
> Touchscreen (or whatever physical attribute of HW is)."
> 
> Both viewpoints come to same answer in the end but yours is best.  Its
> basically 1 value per input device; as you show below.
> 
> It doesn't quite work if we have combined touchscreen+touchpad but I
> agree that case is probably best to break into 2 input devices.

I am glad I'm winning you over ;)

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

Re: [RFC] Adding BTN_TOOL_TOUCH to input.h

[Nikolai Kondrashov]

On 11/27/2010 02:02 AM, Chris Bagwell wrote:
> When I looked at input_absinfo.resolution, I see only synaptics.c is
> using it right now and it is defined using units/mm.
I'm not sure if it matters a lot, but Jiri has accepted my resolution
calculation patch to hid-input.c [1] which does it in *units/inch* for
generic HID devices, which choose to provide correct information in their
report descriptors.

Sincerely,
Nick

[1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;f=drivers/hid/hid-input.c;h=8e733b6eae27587366c138187e59119b2b49ec35;hp=6c03dcc5760a277097bb17d866cc33aa17db484a;hb=4ea6e4ffb4acdaaf9ba7687dbd84ae36e26cef9e;hpb=b6dc79929fa18a97bbc08400db72405ad835622f

Re: [RFC] Adding BTN_TOOL_TOUCH to input.h

[Dmitry Torokhov]

On Thu, Nov 25, 2010 at 03:05:30PM +0100, Henrik Rydberg wrote:
> Hi,
> 
> Reading through this thread, I think Dmitry's EVIOCGDEVTYPE is a great way to
> resolve this. We should expect some changes in userland to correctly interpret
> direct/indirect devices, and this seems a good way to go. The physical size of
> the surface would also be great to retrieve this way. The recent resolution
> addition is semantically odd, since we have only one physical surface, not one
> per axes.

1 for each of 2 major axes, at least. We might need resolution for
pressure/distance as well, although it certainly won't be unit/mm ;)

> 
> In short, my suggestion is to build a struct for device properties, like this:
> 
> struct input_devinfo {
> 	__u32	type;			/* bitmask of possible dev types */
> 	__u32	capabilities;		/* bitmask of special device caps */
> 	__u32	phys_abs_width;		/* physical width of surface (mm) */
> 	__u32	phys_abs_height;	/* physical height of surface (mm) */
> };
> 
> Adding more stuff here seems plausible. For instance, special devices like
> clickpads or integrated buttons would fit nicely in capabilities. The call would
> be very similar, like
> 
> 	ioctl(fd, EVIOCGDEVINFO, &info);
> 

Yep, should work, although the dimensions could be retrieved from
absinfo.

-- 
Dmitry

Re: [RFC] Adding BTN_TOOL_TOUCH to input.h

[Dmitry Torokhov]

On Sat, Nov 27, 2010 at 11:06:43AM +0300, Nikolai Kondrashov wrote:
> On 11/27/2010 02:02 AM, Chris Bagwell wrote:
> >When I looked at input_absinfo.resolution, I see only synaptics.c is
> >using it right now and it is defined using units/mm.
> I'm not sure if it matters a lot, but Jiri has accepted my resolution
> calculation patch to hid-input.c [1] which does it in *units/inch* for
> generic HID devices, which choose to provide correct information in their
> report descriptors.
> 

OUCH. We need to fix this _now_. We can not allow reporting resolutions
in random units. Since we started with unit/mm we have to keep it and
if it gives issues we can think about adding other units later on, but
for everyone.

-- 
Dmitry

Re: [RFC] Adding BTN_TOOL_TOUCH to input.h

[Nikolai Kondrashov]

On 11/27/2010 11:32 AM, Dmitry Torokhov wrote:
> OUCH. We need to fix this _now_. We can not allow reporting resolutions
> in random units. Since we started with unit/mm we have to keep it and
> if it gives issues we can think about adding other units later on, but
> for everyone.
I understand your concerns, but this will make this feature useless for the
8 tablet models I was aiming it at. Most of them have 2000 LPI resolution.

The thing is, I suspect, there is basicly very little to none real devices
correctly specifying their resolution in the report descriptors. Plus almost
no one uses the resolution field in input_absinfo currently and especially
for generic processing (as opposed to working with a specific device). Even
more, I have failed to find any noticeable amount of device drivers filling
it in, but it could be my fault of course.

So, I think, now is the best time to standardize on this and do real
changes.

Sincerely,
Nick

Re: [RFC] Adding BTN_TOOL_TOUCH to input.h

[Nikolai Kondrashov]

On 11/27/2010 12:15 PM, Dmitry Torokhov wrote:
> 2000LPI == about 79 l/mm. How is it not useable?
TBH, I didn't make any real calculations.
The introduced error isn't very high, indeed. The vertical size of 4x3 inch
tablet becomes 75 mm instead of 76 mm. So maybe it's alright.

> In mainline synaptics is the only one that does this. We do not know how
> many drivers in vendor trees fill and use this data nor we do not know
> about userspace. The fact that we were not able to locate them does not
> mean they do not exist. The units/mm are part of input ABI now.
Well, I can't argue with you here.
I didn't think about 3rd party drivers, TBH.

> Right, standarize on existing UOM (which are per/mm) and then implement
> other UOM if theya re really needed.
Will this fix qualify for inclusion into 2.6.37?
Also, what do you think about units per radians for rotational axis?

Thanks :)

Sincerely,
Nick

Re: [RFC] Adding BTN_TOOL_TOUCH to input.h

[Henrik Rydberg]

On 11/27/2010 09:15 AM, Dmitry Torokhov wrote:

> On Thu, Nov 25, 2010 at 03:05:30PM +0100, Henrik Rydberg wrote:
>> Hi,
>>
>> Reading through this thread, I think Dmitry's EVIOCGDEVTYPE is a great way to
>> resolve this. We should expect some changes in userland to correctly interpret
>> direct/indirect devices, and this seems a good way to go. The physical size of
>> the surface would also be great to retrieve this way. The recent resolution
>> addition is semantically odd, since we have only one physical surface, not one
>> per axes.
> 
> 1 for each of 2 major axes, at least. We might need resolution for
> pressure/distance as well, although it certainly won't be unit/mm ;)


Alright, neither abstraction is perfect, but I agree the resolution has its
virtues. :-)

>>
>> In short, my suggestion is to build a struct for device properties, like this:
>>
>> struct input_devinfo {
>> 	__u32	type;			/* bitmask of possible dev types */
>> 	__u32	capabilities;		/* bitmask of special device caps */
>> 	__u32	phys_abs_width;		/* physical width of surface (mm) */
>> 	__u32	phys_abs_height;	/* physical height of surface (mm) */
>> };
>>
>> Adding more stuff here seems plausible. For instance, special devices like
>> clickpads or integrated buttons would fit nicely in capabilities. The call would
>> be very similar, like
>>
>> 	ioctl(fd, EVIOCGDEVINFO, &info);
>>
> 
> Yep, should work, although the dimensions could be retrieved from
> absinfo.
> 


I'll see if I can fit that (minus physical dimensions) into the upcoming patch sets.

Cheers,
Henrik

Re: [RFC] Adding BTN_TOOL_TOUCH to input.h

[Chris Bagwell]

On Sat, Nov 27, 2010 at 3:46 AM, Nikolai Kondrashov <spbnick@gmail.com> wrote:
> On 11/27/2010 12:15 PM, Dmitry Torokhov wrote:
>>
>> 2000LPI == about 79 l/mm. How is it not useable?
>
> TBH, I didn't make any real calculations.
> The introduced error isn't very high, indeed. The vertical size of 4x3 inch
> tablet becomes 75 mm instead of 76 mm. So maybe it's alright.

The wacom's I'm inteterested in have lots of different resolutions
(0.5k to 5k) and different sizes.  I've only calculated a few to see
error but seems no more then a few mm in the ones I chose as well.

It works for me... that is to use units/mm for now and if that ever
shows to be an issue we can move to new units in future.

Thanks all for feedback,
Chris

Re: [RFC] Adding BTN_TOOL_TOUCH to input.h

[Chris Bagwell]

On Sat, Nov 27, 2010 at 11:04 AM, Henrik Rydberg <rydberg@euromail.se> wrote:
> On 11/27/2010 09:15 AM, Dmitry Torokhov wrote:
>
>> On Thu, Nov 25, 2010 at 03:05:30PM +0100, Henrik Rydberg wrote:
>
>>>
>>> In short, my suggestion is to build a struct for device properties, like this:
>>>
>>> struct input_devinfo {
>>>      __u32   type;                   /* bitmask of possible dev types */
>>>      __u32   capabilities;           /* bitmask of special device caps */
>>>      __u32   phys_abs_width;         /* physical width of surface (mm) */
>>>      __u32   phys_abs_height;        /* physical height of surface (mm) */
>>> };
>>>
>>> Adding more stuff here seems plausible. For instance, special devices like
>>> clickpads or integrated buttons would fit nicely in capabilities. The call would
>>> be very similar, like
>>>
>>>      ioctl(fd, EVIOCGDEVINFO, &info);
>>>
>>
>> Yep, should work, although the dimensions could be retrieved from
>> absinfo.
>>
>
>
> I'll see if I can fit that (minus physical dimensions) into the upcoming patch sets.
>

Thanks, Henrik.  That will help move things along for up coming wacom
changes needed.

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

Re: [RFC] Adding BTN_TOOL_TOUCH to input.h

[Dmitry Torokhov]

On Sat, Nov 27, 2010 at 12:46:03PM +0300, Nikolai Kondrashov wrote:
> On 11/27/2010 12:15 PM, Dmitry Torokhov wrote:
> >2000LPI == about 79 l/mm. How is it not useable?
> TBH, I didn't make any real calculations.
> The introduced error isn't very high, indeed. The vertical size of 4x3 inch
> tablet becomes 75 mm instead of 76 mm. So maybe it's alright.
> 
> >In mainline synaptics is the only one that does this. We do not know how
> >many drivers in vendor trees fill and use this data nor we do not know
> >about userspace. The fact that we were not able to locate them does not
> >mean they do not exist. The units/mm are part of input ABI now.
> Well, I can't argue with you here.
> I didn't think about 3rd party drivers, TBH.
> 
> >Right, standarize on existing UOM (which are per/mm) and then implement
> >other UOM if theya re really needed.
> Will this fix qualify for inclusion into 2.6.37?

Yes, I believe it does.

> Also, what do you think about units per radians for rotational axis?

Works for me.

-- 
Dmitry

Re: [RFC] Adding BTN_TOOL_TOUCH to input.h

[Dmitry Torokhov]

On Sat, Nov 27, 2010 at 03:39:02PM -0800, Dmitry Torokhov wrote:
> On Sat, Nov 27, 2010 at 12:46:03PM +0300, Nikolai Kondrashov wrote:
> > On 11/27/2010 12:15 PM, Dmitry Torokhov wrote:
> > >2000LPI == about 79 l/mm. How is it not useable?
> > TBH, I didn't make any real calculations.
> > The introduced error isn't very high, indeed. The vertical size of 4x3 inch
> > tablet becomes 75 mm instead of 76 mm. So maybe it's alright.
> > 
> > >In mainline synaptics is the only one that does this. We do not know how
> > >many drivers in vendor trees fill and use this data nor we do not know
> > >about userspace. The fact that we were not able to locate them does not
> > >mean they do not exist. The units/mm are part of input ABI now.
> > Well, I can't argue with you here.
> > I didn't think about 3rd party drivers, TBH.
> > 
> > >Right, standarize on existing UOM (which are per/mm) and then implement
> > >other UOM if theya re really needed.
> > Will this fix qualify for inclusion into 2.6.37?
> 
> Yes, I believe it does.
> 

Does the following work by any chance?

Thanks.

-- 
Dmitry


HID: length resolution should be reported units/mm

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>

Input ABI requires reporting resolution on main axes in units per
millimeter, not units per inch, so we need to convert accordingly.

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
---

 drivers/hid/hid-input.c |   19 +++++++++++--------
 1 files changed, 11 insertions(+), 8 deletions(-)


diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index c9c90de..5cde845 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -203,8 +203,8 @@ static int hidinput_setkeycode(struct input_dev *dev,
  *
  * as seen in the HID specification v1.11 6.2.2.7 Global Items.
  *
- * Only exponent 1 length units are processed. Centimeters are converted to
- * inches. Degrees are converted to radians.
+ * Only exponent 1 length units are processed. Centimeters and inches are
+ * converted to millimeters. Degrees are converted to radians.
  */
 static __s32 hidinput_calc_abs_res(const struct hid_field *field, __u16 code)
 {
@@ -225,13 +225,16 @@ static __s32 hidinput_calc_abs_res(const struct hid_field *field, __u16 code)
 	 */
 	if (code == ABS_X || code == ABS_Y || code == ABS_Z) {
 		if (field->unit == 0x11) {		/* If centimeters */
-			/* Convert to inches */
-			prev = logical_extents;
-			logical_extents *= 254;
-			if (logical_extents < prev)
+			/* Convert to millimeters */
+			unit_exponent += 1;
+		} else if (field->unit == 0x13) {	/* If inches */
+			/* Convert to millimeters */
+			prev = physical_extents;
+			physical_extents *= 254;
+			if (physical_extents < prev)
 				return 0;
-			unit_exponent += 2;
-		} else if (field->unit != 0x13) {	/* If not inches */
+			unit_exponent -= 1;
+		} else {
 			return 0;
 		}
 	} else if (code == ABS_RX || code == ABS_RY || code == ABS_RZ) {

Re: [RFC] Adding BTN_TOOL_TOUCH to input.h

[Dmitry Torokhov]

On Sat, Nov 27, 2010 at 03:39:02PM -0800, Dmitry Torokhov wrote:
> On Sat, Nov 27, 2010 at 12:46:03PM +0300, Nikolai Kondrashov wrote:
> > On 11/27/2010 12:15 PM, Dmitry Torokhov wrote:
> > >2000LPI == about 79 l/mm. How is it not useable?
> > TBH, I didn't make any real calculations.
> > The introduced error isn't very high, indeed. The vertical size of 4x3 inch
> > tablet becomes 75 mm instead of 76 mm. So maybe it's alright.
> > 
> > >In mainline synaptics is the only one that does this. We do not know how
> > >many drivers in vendor trees fill and use this data nor we do not know
> > >about userspace. The fact that we were not able to locate them does not
> > >mean they do not exist. The units/mm are part of input ABI now.
> > Well, I can't argue with you here.
> > I didn't think about 3rd party drivers, TBH.
> > 
> > >Right, standarize on existing UOM (which are per/mm) and then implement
> > >other UOM if theya re really needed.
> > Will this fix qualify for inclusion into 2.6.37?
> 
> Yes, I believe it does.
> 
> > Also, what do you think about units per radians for rotational axis?
> 

How about the following?

-- 
Dmitry


Input: document struct input_absinfo

Add documentation for struct input_absinfo that is used in EVIOCGABS
and EVIOCSABS ioctl and specify units of measure used for reporting
resolution for an axis.

Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
---

 include/linux/input.h |   21 ++++++++++++++++++++-
 1 files changed, 20 insertions(+), 1 deletions(-)


diff --git a/include/linux/input.h b/include/linux/input.h
index a50046f..a8af21d 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -47,6 +47,25 @@ struct input_id {
 	__u16 version;
 };
 
+/**
+ * struct input_absinfo - used by EVIOCGABS/EVIOCSABS ioctls
+ * @value: latest reported value for the axis.
+ * @minimum: specifies minimum value for the axis.
+ * @maximum: specifies maximum value for the axis.
+ * @fuzz: specifies fuzz value that is used to filter noise from
+ *	the event stream.
+ * @flat: values that are within this value will be discarded by
+ *	joydev interface and reported as 0 instead.
+ * @resolution: specifies resolution for the values reported for
+ *	the axis.
+ *
+ * Note that input core does not clamp reported values to the
+ * [minimum, maximum] limits, such task is left to userspace.
+ *
+ * Resolution for main axes (ABS_X, ABS_Y, ABS_Z) is reported in
+ * units per millimeter (units/mm), resolution for rotational axes
+ * (ABS_RX, ABS_RY, ABS_RZ) is reported in units per radian.
+ */
 struct input_absinfo {
 	__s32 value;
 	__s32 minimum;
@@ -1134,7 +1153,7 @@ struct input_mt_slot {
  *	of tracked contacts
  * @mtsize: number of MT slots the device uses
  * @slot: MT slot currently being transmitted
- * @absinfo: array of &struct absinfo elements holding information
+ * @absinfo: array of &struct input_absinfo elements holding information
  *	about absolute axes (current value, min, max, flat, fuzz,
  *	resolution)
  * @key: reflects current state of device's keys/buttons

Re: [RFC] Adding BTN_TOOL_TOUCH to input.h

[Henrik Rydberg]

>

> How about the following?
> 

>
> Input: document struct input_absinfo
>
> Add documentation for struct input_absinfo that is used in EVIOCGABS
> and EVIOCSABS ioctl and specify units of measure used for reporting
> resolution for an axis.
>
> Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
> ---

Very nice, thank you.

Acked-by: Henrik Rydberg <rydberg@euromail.se>

Re: [RFC] Adding BTN_TOOL_TOUCH to input.h

[Nikolai Kondrashov]

On 11/28/2010 11:01 AM, Dmitry Torokhov wrote:
> How about the following?
Very good, thanks :)

Re: [RFC] Adding BTN_TOOL_TOUCH to input.h

[Nikolai Kondrashov]

On 11/28/2010 10:22 AM, Dmitry Torokhov wrote:
> Does the following work by any chance?
Yes, works perfectly.
Thanks for fixing it for me.
I understand I was too slow :)

FWIW,
Tested-by: Nikolai Kondrashov <spbnick@gmail.com>
Acked-by: Nikolai Kondrashov <spbnick@gmail.com>

Sincerely,
Nick

Re: [RFC] Adding BTN_TOOL_TOUCH to input.h

[Dmitry Torokhov]

On Sun, Nov 28, 2010 at 05:57:44PM +0300, Nikolai Kondrashov wrote:
> On 11/28/2010 10:22 AM, Dmitry Torokhov wrote:
> >Does the following work by any chance?
> Yes, works perfectly.
> Thanks for fixing it for me.
> I understand I was too slow :)
> 
> FWIW,
> Tested-by: Nikolai Kondrashov <spbnick@gmail.com>
> Acked-by: Nikolai Kondrashov <spbnick@gmail.com>
> 

Great, thanks for testing.

Jiri, will you pick it up for 2.6.37?

-- 
Dmitry

Re: [RFC] Adding BTN_TOOL_TOUCH to input.h

[Nikolai Kondrashov]

On 11/29/2010 12:47 AM, Dmitry Torokhov wrote:
> Jiri, will you pick it up for 2.6.37?
Just to finish the thread:
I see this patch applied in both Jiri's and Linus' trees now.

Thanks everyone :)

Sincerely,
Nick