Mixed "pen" and multitouch input devices

Mixed "pen" and multitouch input devices

[Thorsten Wissmann]

Hi,

we are working on already existing multitouch driver for a Promethean
ActivBoard, which supports both multiple fingers and pens. The pens
behave Wacom-like, i.e. the device actually can tell a cursor position
without a button action.

Because of the (up to 4) fingers, we use the input_mt_* functions. Is it
possible to just update the cursor position without a button action? (As
it is can be done with plain input_* functions?) Or do we have to create
two input devices? (one with multitouch input_mt_* and one for the pens?)

Information about our context: We took the partial working and GPL
licensed driver code out of /usr/src/ of [3] and enabled the multitouch
parts of it.

    Thorsten

[1] http://git.cs.fau.de/?p=re06huxa/promethean-activboard
[2] git clone git://git.cs.fau.de/re06huxa/promethean-activboard/
[3] http://activsoftware.co.uk/linux/repos/debian/pool/oss/a/activdriver/activdriver_5.7.23-2~debian~squeeze_amd64.deb

Re: Mixed "pen" and multitouch input devices

[Chris Bagwell]

2012/3/15 Thorsten Wissmann <re06huxa@stud.informatik.uni-erlangen.de>:
> Hi,
>
> we are working on already existing multitouch driver for a Promethean
> ActivBoard, which supports both multiple fingers and pens. The pens
> behave Wacom-like, i.e. the device actually can tell a cursor position
> without a button action.
>
> Because of the (up to 4) fingers, we use the input_mt_* functions. Is it
> possible to just update the cursor position without a button action? (As
> it is can be done with plain input_* functions?) Or do we have to create
> two input devices? (one with multitouch input_mt_* and one for the pens?)
>
> Information about our context: We took the partial working and GPL
> licensed driver code out of /usr/src/ of [3] and enabled the multitouch
> parts of it.
>

I'm not quite sure what you mean by updating cursor position without a
button action.  By button action, do you mean BTN_TOOL_*?  It is true
you need to set correct BTN_TOOL_* before updating any X/Y coordinates
so user land knows that X/Y maps to.

Its also true that sharing ABS_X/Y events between both a BTN_TOOL_PEN
and a BTN_TOOL_FINGER will confuse most user land apps (they think
only touchpads can declare BTN_TOOL_FINGER's but this is a
touchscreen) and it also has bad side affects to the kernel's MT
pointer emulation functions.

You can look at kernel drivers/input/touchscreen/wacom_w8001.c for an
example touchscreen that supports pen and at least 2 MT touches on a
single /dev/input device (because HW packets come over single serial
interface).  It does not declare a BTN_TOOL_FINGER nor use pointer
emulation to overcome issues I mentioned and xf86-input-wacom
understands how to handle this device.

If you want to work with other unmodified user land apps (perhaps
xf86-input-evdev for touches) then its probably easiest to split pen
and touch to separate input devices.  drivers/input/tablet/wacom_wac.c
shows some examples of that approach but that driver doesn't have to
work to hard to split in to 2 input devices because the USB device
already puts the events on separate USB  interfaces.

Chris

Re: Mixed "pen" and multitouch input devices

[Thorsten Wissmann]

Thank You for your quick answer!

On Thu, Mar 15, 2012 at 12:27:22PM -0500, Chris Bagwell wrote:
> 2012/3/15 Thorsten Wissmann <re06huxa@stud.informatik.uni-erlangen.de>:
> > we are working on already existing multitouch driver for a Promethean
> > ActivBoard, which supports both multiple fingers and pens. The pens
> > behave Wacom-like, i.e. the device actually can tell a cursor position
> > without a button action.
> >
> > Because of the (up to 4) fingers, we use the input_mt_* functions. Is it
> > possible to just update the cursor position without a button action? (As
> > it is can be done with plain input_* functions?) Or do we have to create
> > two input devices? (one with multitouch input_mt_* and one for the pens?)
> 
> I'm not quite sure what you mean by updating cursor position without a
> button action.  By button action, do you mean BTN_TOOL_*?  It is true
> you need to set correct BTN_TOOL_* before updating any X/Y coordinates
> so user land knows that X/Y maps to.

With "updating cursor position without a button action" we meant
something like moving a "normal" mouse without pressing any button.
(Which generates just mouse motion events for X applications)

> Its also true that sharing ABS_X/Y events between both a BTN_TOOL_PEN
> and a BTN_TOOL_FINGER will confuse most user land apps (they think
> only touchpads can declare BTN_TOOL_FINGER's but this is a
> touchscreen) and it also has bad side affects to the kernel's MT
> pointer emulation functions.
> 
> You can look at kernel drivers/input/touchscreen/wacom_w8001.c for an
> example touchscreen that supports pen and at least 2 MT touches on a
> single /dev/input device (because HW packets come over single serial
> interface).  It does not declare a BTN_TOOL_FINGER nor use pointer
> emulation to overcome issues I mentioned and xf86-input-wacom
> understands how to handle this device.
> 
> If you want to work with other unmodified user land apps (perhaps
> xf86-input-evdev for touches) then its probably easiest to split pen
> and touch to separate input devices.  drivers/input/tablet/wacom_wac.c
> shows some examples of that approach but that driver doesn't have to
> work to hard to split in to 2 input devices because the USB device
> already puts the events on separate USB  interfaces.

OK. We want the device to work with the xf86-input-evdev driver. So we
will split it into two devices.

    Thorsten

Re: Mixed "pen" and multitouch input devices

[Chase Douglas]

On 03/15/2012 10:56 AM, Thorsten Wissmann wrote:
> On Thu, Mar 15, 2012 at 12:27:22PM -0500, Chris Bagwell wrote:
>> Its also true that sharing ABS_X/Y events between both a BTN_TOOL_PEN
>> and a BTN_TOOL_FINGER will confuse most user land apps (they think
>> only touchpads can declare BTN_TOOL_FINGER's but this is a
>> touchscreen) and it also has bad side affects to the kernel's MT
>> pointer emulation functions.
>>
>> You can look at kernel drivers/input/touchscreen/wacom_w8001.c for an
>> example touchscreen that supports pen and at least 2 MT touches on a
>> single /dev/input device (because HW packets come over single serial
>> interface).  It does not declare a BTN_TOOL_FINGER nor use pointer
>> emulation to overcome issues I mentioned and xf86-input-wacom
>> understands how to handle this device.
>>
>> If you want to work with other unmodified user land apps (perhaps
>> xf86-input-evdev for touches) then its probably easiest to split pen
>> and touch to separate input devices.  drivers/input/tablet/wacom_wac.c
>> shows some examples of that approach but that driver doesn't have to
>> work to hard to split in to 2 input devices because the USB device
>> already puts the events on separate USB  interfaces.
> 
> OK. We want the device to work with the xf86-input-evdev driver. So we
> will split it into two devices.

Or you could teach evdev to know how to handle mixed devices :). I think
that's the "better" approach over all, but it's up to you.

-- Chase

Re: Mixed "pen" and multitouch input devices

[Thorsten Wissmann]

On Thu, Mar 15, 2012 at 11:29:37AM -0700, Chase Douglas wrote:
> On 03/15/2012 10:56 AM, Thorsten Wissmann wrote:
> > On Thu, Mar 15, 2012 at 12:27:22PM -0500, Chris Bagwell wrote:
> >> If you want to work with other unmodified user land apps (perhaps
> >> xf86-input-evdev for touches) then its probably easiest to split pen
> >> and touch to separate input devices.  drivers/input/tablet/wacom_wac.c
> >> shows some examples of that approach but that driver doesn't have to
> >> work to hard to split in to 2 input devices because the USB device
> >> already puts the events on separate USB  interfaces.
> > 
> > OK. We want the device to work with the xf86-input-evdev driver. So we
> > will split it into two devices.
> 
> Or you could teach evdev to know how to handle mixed devices :). I think
> that's the "better" approach over all, but it's up to you.

Thanks! We didn't thought about this. It turned out that the problem
isn't caused by the usage of both BTN_TOOL_PEN and BTN_TOOL_FINGER.

It turned out xf86-input-evdev really discards all non-multitouch events
(especially ABS_X and ABS_Y) events in EvdevProcessAbsoluteMotionEvent()
in evdev.c, if the device is configured as a multitouch device. So there
is a quick fix (or only workaround?), which processes ABS_X and ABS_Y
events even if it is a multitouch device:

diff --git a/src/evdev.c b/src/evdev.c
index d540b87..b857b83 100644
--- a/src/evdev.c
+++ b/src/evdev.c
@@ -832,7 +832,7 @@ EvdevProcessAbsoluteMotionEvent(InputInfoPtr pInfo,
struct input_event *ev)
     if (ev->code >= ABS_MT_SLOT) {
         EvdevProcessTouchEvent(pInfo, ev);
         pEvdev->abs_queued = 1;
-    } else if (!pEvdev->mt_mask) {
+    } else if (!pEvdev->mt_mask || ev->code == ABS_X || ev->code ==
ABS_Y) {
         map = pEvdev->axis_map[ev->code];
         valuator_mask_set(pEvdev->vals, map, value);
         pEvdev->abs_queued = 1;

This patch already is submitted to the xorg bugtracker and can be found
at [1].

The only remaining question is: Does it break other drivers?

    Max and Thorsten

[1] https://bugs.freedesktop.org/show_bug.cgi?id=47382
-- 
1.7.9.3

Re: Mixed "pen" and multitouch input devices

[Chase Douglas]

On 03/15/2012 06:52 PM, Thorsten Wissmann wrote:
> On Thu, Mar 15, 2012 at 11:29:37AM -0700, Chase Douglas wrote:
>> On 03/15/2012 10:56 AM, Thorsten Wissmann wrote:
>>> On Thu, Mar 15, 2012 at 12:27:22PM -0500, Chris Bagwell wrote:
>>>> If you want to work with other unmodified user land apps (perhaps
>>>> xf86-input-evdev for touches) then its probably easiest to split pen
>>>> and touch to separate input devices.  drivers/input/tablet/wacom_wac.c
>>>> shows some examples of that approach but that driver doesn't have to
>>>> work to hard to split in to 2 input devices because the USB device
>>>> already puts the events on separate USB  interfaces.
>>>
>>> OK. We want the device to work with the xf86-input-evdev driver. So we
>>> will split it into two devices.
>>
>> Or you could teach evdev to know how to handle mixed devices :). I think
>> that's the "better" approach over all, but it's up to you.
> 
> Thanks! We didn't thought about this. It turned out that the problem
> isn't caused by the usage of both BTN_TOOL_PEN and BTN_TOOL_FINGER.
> 
> It turned out xf86-input-evdev really discards all non-multitouch events
> (especially ABS_X and ABS_Y) events in EvdevProcessAbsoluteMotionEvent()
> in evdev.c, if the device is configured as a multitouch device. So there
> is a quick fix (or only workaround?), which processes ABS_X and ABS_Y
> events even if it is a multitouch device:
> 
> diff --git a/src/evdev.c b/src/evdev.c
> index d540b87..b857b83 100644
> --- a/src/evdev.c
> +++ b/src/evdev.c
> @@ -832,7 +832,7 @@ EvdevProcessAbsoluteMotionEvent(InputInfoPtr pInfo,
> struct input_event *ev)
>      if (ev->code >= ABS_MT_SLOT) {
>          EvdevProcessTouchEvent(pInfo, ev);
>          pEvdev->abs_queued = 1;
> -    } else if (!pEvdev->mt_mask) {
> +    } else if (!pEvdev->mt_mask || ev->code == ABS_X || ev->code ==
> ABS_Y) {
>          map = pEvdev->axis_map[ev->code];
>          valuator_mask_set(pEvdev->vals, map, value);
>          pEvdev->abs_queued = 1;
> 
> This patch already is submitted to the xorg bugtracker and can be found
> at [1].
> 
> The only remaining question is: Does it break other drivers?
> 
>     Max and Thorsten
> 
> [1] https://bugs.freedesktop.org/show_bug.cgi?id=47382

Great!

I haven't fully thought about it enough to give a reviewed-by, but it
seems sane.

I suggest sending the patch to xorg-devel@lists.x.org. That's where most
patch reviews are handled. You will likely get faster results there.

-- Chase

Re: Mixed "pen" and multitouch input devices

[Thorsten Wissmann]

On Thu, Mar 15, 2012 at 07:03:12PM -0700, Chase Douglas wrote:
> On 03/15/2012 06:52 PM, Thorsten Wissmann wrote:
> > It turned out xf86-input-evdev really discards all non-multitouch events
> > (especially ABS_X and ABS_Y) events in EvdevProcessAbsoluteMotionEvent()
> > in evdev.c, if the device is configured as a multitouch device. So there
> > is a quick fix (or only workaround?), which processes ABS_X and ABS_Y
> > events even if it is a multitouch device:
> > 
> > diff --git a/src/evdev.c b/src/evdev.c
> > index d540b87..b857b83 100644
> > --- a/src/evdev.c
> > +++ b/src/evdev.c
> > @@ -832,7 +832,7 @@ EvdevProcessAbsoluteMotionEvent(InputInfoPtr pInfo,
> > struct input_event *ev)
> >      if (ev->code >= ABS_MT_SLOT) {
> >          EvdevProcessTouchEvent(pInfo, ev);
> >          pEvdev->abs_queued = 1;
> > -    } else if (!pEvdev->mt_mask) {
> > +    } else if (!pEvdev->mt_mask || ev->code == ABS_X || ev->code ==
> > ABS_Y) {
> >          map = pEvdev->axis_map[ev->code];
> >          valuator_mask_set(pEvdev->vals, map, value);
> >          pEvdev->abs_queued = 1;
> > 
> > This patch already is submitted to the xorg bugtracker and can be found
> > at [1].
> > 
> > The only remaining question is: Does it break other drivers?
> > 
> > [1] https://bugs.freedesktop.org/show_bug.cgi?id=47382
> 
> Great!
> 
> I haven't fully thought about it enough to give a reviewed-by, but it
> seems sane.
> 
> I suggest sending the patch to xorg-devel@lists.x.org. That's where most
> patch reviews are handled. You will likely get faster results there.

I have sent it to xorg-devel@lists.x.org. (I haven't noticed it, because
only the web-bugtracker is noted in the README)

Thank you very much

    Max
    Thorsten

Re: Mixed "pen" and multitouch input devices

[Chris Bagwell]

On Thu, Mar 15, 2012 at 9:03 PM, Chase Douglas <chasedouglas@gmail.com> wrote:
> On 03/15/2012 06:52 PM, Thorsten Wissmann wrote:
>> On Thu, Mar 15, 2012 at 11:29:37AM -0700, Chase Douglas wrote:
>>> On 03/15/2012 10:56 AM, Thorsten Wissmann wrote:
>>>> On Thu, Mar 15, 2012 at 12:27:22PM -0500, Chris Bagwell wrote:
>>>>> If you want to work with other unmodified user land apps (perhaps
>>>>> xf86-input-evdev for touches) then its probably easiest to split pen
>>>>> and touch to separate input devices.  drivers/input/tablet/wacom_wac.c
>>>>> shows some examples of that approach but that driver doesn't have to
>>>>> work to hard to split in to 2 input devices because the USB device
>>>>> already puts the events on separate USB  interfaces.
>>>>
>>>> OK. We want the device to work with the xf86-input-evdev driver. So we
>>>> will split it into two devices.
>>>
>>> Or you could teach evdev to know how to handle mixed devices :). I think
>>> that's the "better" approach over all, but it's up to you.
>>
>> Thanks! We didn't thought about this. It turned out that the problem
>> isn't caused by the usage of both BTN_TOOL_PEN and BTN_TOOL_FINGER.
>>
>> It turned out xf86-input-evdev really discards all non-multitouch events
>> (especially ABS_X and ABS_Y) events in EvdevProcessAbsoluteMotionEvent()
>> in evdev.c, if the device is configured as a multitouch device. So there
>> is a quick fix (or only workaround?), which processes ABS_X and ABS_Y
>> events even if it is a multitouch device:
>>
>> diff --git a/src/evdev.c b/src/evdev.c
>> index d540b87..b857b83 100644
>> --- a/src/evdev.c
>> +++ b/src/evdev.c
>> @@ -832,7 +832,7 @@ EvdevProcessAbsoluteMotionEvent(InputInfoPtr pInfo,
>> struct input_event *ev)
>>      if (ev->code >= ABS_MT_SLOT) {
>>          EvdevProcessTouchEvent(pInfo, ev);
>>          pEvdev->abs_queued = 1;
>> -    } else if (!pEvdev->mt_mask) {
>> +    } else if (!pEvdev->mt_mask || ev->code == ABS_X || ev->code ==
>> ABS_Y) {
>>          map = pEvdev->axis_map[ev->code];
>>          valuator_mask_set(pEvdev->vals, map, value);
>>          pEvdev->abs_queued = 1;
>>
>> This patch already is submitted to the xorg bugtracker and can be found
>> at [1].
>>
>> The only remaining question is: Does it break other drivers?
>>
>>     Max and Thorsten
>>
>> [1] https://bugs.freedesktop.org/show_bug.cgi?id=47382
>
> Great!
>
> I haven't fully thought about it enough to give a reviewed-by, but it
> seems sane.
>
> I suggest sending the patch to xorg-devel@lists.x.org. That's where most
> patch reviews are handled. You will likely get faster results there.
>
> -- Chase

Yep, agree thats also a great way to go.

One thing I might suggest is to include with patch your thinking on
how a pen+multitouch device should send events to help in review of
the patch.  Just the basics.  For example, from above patch I have an
assumption that your sending ABS_X/Y only for PEN events and
ABS_MT_POSITION_X/Y only for touch events; but then again I'm not 100%
sure of that .

If ABS_X/Y is only for PEN events, then pEvdev->in_proximity in
xf86-input-evdev may be a less restrictive check to allow even
BTN_STYLUS and ABS_X/Y events to be processed.

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: Mixed "pen" and multitouch input devices

[Thorsten Wissmann]

On Thu, Mar 15, 2012 at 09:57:30PM -0500, Chris Bagwell wrote:
> On Thu, Mar 15, 2012 at 9:03 PM, Chase Douglas <chasedouglas@gmail.com> wrote:
> > On 03/15/2012 06:52 PM, Thorsten Wissmann wrote:
> >> It turned out xf86-input-evdev really discards all non-multitouch events
> >> (especially ABS_X and ABS_Y) events in EvdevProcessAbsoluteMotionEvent()
> >> in evdev.c, if the device is configured as a multitouch device. So there
> >> is a quick fix (or only workaround?), which processes ABS_X and ABS_Y
> >> events even if it is a multitouch device:
> >>
> >> diff --git a/src/evdev.c b/src/evdev.c
> >> index d540b87..b857b83 100644
> >> --- a/src/evdev.c
> >> +++ b/src/evdev.c
> >> @@ -832,7 +832,7 @@ EvdevProcessAbsoluteMotionEvent(InputInfoPtr pInfo,
> >> struct input_event *ev)
> >>      if (ev->code >= ABS_MT_SLOT) {
> >>          EvdevProcessTouchEvent(pInfo, ev);
> >>          pEvdev->abs_queued = 1;
> >> -    } else if (!pEvdev->mt_mask) {
> >> +    } else if (!pEvdev->mt_mask || ev->code == ABS_X || ev->code ==
> >> ABS_Y) {
> >>          map = pEvdev->axis_map[ev->code];
> >>          valuator_mask_set(pEvdev->vals, map, value);
> >>          pEvdev->abs_queued = 1;
> >>
> >> This patch already is submitted to the xorg bugtracker and can be found
> >> at [1].
> >>
> >> The only remaining question is: Does it break other drivers?
> >>
> >> [1] https://bugs.freedesktop.org/show_bug.cgi?id=47382
> >
> > Great!
> >
> > I haven't fully thought about it enough to give a reviewed-by, but it
> > seems sane.
> >
> > I suggest sending the patch to xorg-devel@lists.x.org. That's where most
> > patch reviews are handled. You will likely get faster results there.
> 
> Yep, agree thats also a great way to go.

Thanks!

> One thing I might suggest is to include with patch your thinking on
> how a pen+multitouch device should send events to help in review of
> the patch.  Just the basics.  For example, from above patch I have an
> assumption that your sending ABS_X/Y only for PEN events and
> ABS_MT_POSITION_X/Y only for touch events; but then again I'm not 100%
> sure of that.

That's correct. In our case, it's ABS_X/Y for pen, ABS_MT_* for fingers
(normal touches). But maybe other devices behave different. So we should
send something like this as an addition to the patch on the x.org list?

# finger touch
    ABS_MT_SLOT 0
    ABS_MT_TRACKING_ID 42
    ABS_MT_POSITION_X finger_x
    ABS_MT_POSITION_Y finger_y
    SYN_MT_REPORT
    SYN_REPORT
# finger release
    ABS_MT_SLOT 0
    ABS_MT_TRACKING_ID -1
    SYN_REPORT
# pen motion
    ABS_X pen_x
    ABS_Y pen_y
    SYN_REPORT

> If ABS_X/Y is only for PEN events, then pEvdev->in_proximity in
> xf86-input-evdev may be a less restrictive check to allow even
> BTN_STYLUS and ABS_X/Y events to be processed.

The actual event source (if PEN or STYLUS or ...) shouldn't matter. (Or
I just don't get your point)


    Thorsten
--
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: Mixed "pen" and multitouch input devices

[Chase Douglas]

On 03/16/2012 10:33 AM, Thorsten Wissmann wrote:
> On Thu, Mar 15, 2012 at 09:57:30PM -0500, Chris Bagwell wrote:
>> On Thu, Mar 15, 2012 at 9:03 PM, Chase Douglas <chasedouglas@gmail.com> wrote:
>>> On 03/15/2012 06:52 PM, Thorsten Wissmann wrote:
>>>> It turned out xf86-input-evdev really discards all non-multitouch events
>>>> (especially ABS_X and ABS_Y) events in EvdevProcessAbsoluteMotionEvent()
>>>> in evdev.c, if the device is configured as a multitouch device. So there
>>>> is a quick fix (or only workaround?), which processes ABS_X and ABS_Y
>>>> events even if it is a multitouch device:
>>>>
>>>> diff --git a/src/evdev.c b/src/evdev.c
>>>> index d540b87..b857b83 100644
>>>> --- a/src/evdev.c
>>>> +++ b/src/evdev.c
>>>> @@ -832,7 +832,7 @@ EvdevProcessAbsoluteMotionEvent(InputInfoPtr pInfo,
>>>> struct input_event *ev)
>>>>      if (ev->code >= ABS_MT_SLOT) {
>>>>          EvdevProcessTouchEvent(pInfo, ev);
>>>>          pEvdev->abs_queued = 1;
>>>> -    } else if (!pEvdev->mt_mask) {
>>>> +    } else if (!pEvdev->mt_mask || ev->code == ABS_X || ev->code ==
>>>> ABS_Y) {
>>>>          map = pEvdev->axis_map[ev->code];
>>>>          valuator_mask_set(pEvdev->vals, map, value);
>>>>          pEvdev->abs_queued = 1;
>>>>
>>>> This patch already is submitted to the xorg bugtracker and can be found
>>>> at [1].
>>>>
>>>> The only remaining question is: Does it break other drivers?
>>>>
>>>> [1] https://bugs.freedesktop.org/show_bug.cgi?id=47382
>>>
>>> Great!
>>>
>>> I haven't fully thought about it enough to give a reviewed-by, but it
>>> seems sane.
>>>
>>> I suggest sending the patch to xorg-devel@lists.x.org. That's where most
>>> patch reviews are handled. You will likely get faster results there.
>>
>> Yep, agree thats also a great way to go.
> 
> Thanks!
> 
>> One thing I might suggest is to include with patch your thinking on
>> how a pen+multitouch device should send events to help in review of
>> the patch.  Just the basics.  For example, from above patch I have an
>> assumption that your sending ABS_X/Y only for PEN events and
>> ABS_MT_POSITION_X/Y only for touch events; but then again I'm not 100%
>> sure of that.
> 
> That's correct. In our case, it's ABS_X/Y for pen, ABS_MT_* for fingers
> (normal touches). But maybe other devices behave different. So we should
> send something like this as an addition to the patch on the x.org list?
> 
> # finger touch
>     ABS_MT_SLOT 0
>     ABS_MT_TRACKING_ID 42
>     ABS_MT_POSITION_X finger_x
>     ABS_MT_POSITION_Y finger_y
>     SYN_MT_REPORT
>     SYN_REPORT
> # finger release
>     ABS_MT_SLOT 0
>     ABS_MT_TRACKING_ID -1
>     SYN_REPORT
> # pen motion
>     ABS_X pen_x
>     ABS_Y pen_y
>     SYN_REPORT

The proper way to send events through evdev when there are two different
"tools" (pen and touch) is to use BTN_TOOL_*. In your example above, it
would be:

# finger touch (Note lack of tool, it's assumed to be finger)
    ABS_MT_SLOT 0
    ABS_MT_TRACKING_ID 42
    ABS_MT_POSITION_X finger_x
    ABS_MT_POSITION_Y finger_y
    SYN_MT_REPORT
    ABS_X finger_x
    ABS_Y finger_y
    SYN_REPORT
# finger release
    ABS_MT_SLOT 0
    ABS_MT_TRACKING_ID -1
    SYN_REPORT
# pen motion
    BTN_TOOL_PEN 1
    ABS_X pen_x
    ABS_Y pen_y
    SYN_REPORT
# finger touch begin
    ABS_MT_SLOT 0
    ABS_MT_TRACKING_ID 42
    ABS_MT_POSITION_X finger_x
    ABS_MT_POSITION_Y finger_y
    SYN_MT_REPORT
    BTN_TOOL_PEN 0
    ABS_X finger_x
    ABS_Y finger_y
    SYN_REPORT
etc.

Then, xf86-input-evdev ignores ABS_{X,Y} events when there is no
BTN_TOOL_* active.

-- Chase

Re: Mixed "pen" and multitouch input devices

[Henrik Rydberg]

> The proper way to send events through evdev when there are two different
> "tools" (pen and touch) is to use BTN_TOOL_*. In your example above, it
> would be:
> 
> # finger touch (Note lack of tool, it's assumed to be finger)
>     ABS_MT_SLOT 0
>     ABS_MT_TRACKING_ID 42
>     ABS_MT_POSITION_X finger_x
>     ABS_MT_POSITION_Y finger_y
>     SYN_MT_REPORT
>     ABS_X finger_x
>     ABS_Y finger_y
>     SYN_REPORT
> # finger release
>     ABS_MT_SLOT 0
>     ABS_MT_TRACKING_ID -1
>     SYN_REPORT
> # pen motion
>     BTN_TOOL_PEN 1
>     ABS_X pen_x
>     ABS_Y pen_y
>     SYN_REPORT
> # finger touch begin
>     ABS_MT_SLOT 0
>     ABS_MT_TRACKING_ID 42
>     ABS_MT_POSITION_X finger_x
>     ABS_MT_POSITION_Y finger_y
>     SYN_MT_REPORT
>     BTN_TOOL_PEN 0
>     ABS_X finger_x
>     ABS_Y finger_y
>     SYN_REPORT
> etc.
> 
> Then, xf86-input-evdev ignores ABS_{X,Y} events when there is no
> BTN_TOOL_* active.

On the subject how pen and touch could work going forward, the MT
protocol is prepared to deal with tool type per slot. It makes a lot
of sense to move away from the above example, towards a fully parallel
representation of pen and touch data. Today's multitouch interfaces
are really tremendously restrictive; I am looking forward to the day
when one does not need to worry about touching or resting on a surface
in order to operate it.

In short, why not make xf86-input-evdev aware of MT_TOOL_TYPE?

Thanks,
Henrik

Re: Mixed "pen" and multitouch input devices

[Chase Douglas]

On 03/18/2012 11:39 PM, Henrik Rydberg wrote:
>> The proper way to send events through evdev when there are two different
>> "tools" (pen and touch) is to use BTN_TOOL_*. In your example above, it
>> would be:
>>
>> # finger touch (Note lack of tool, it's assumed to be finger)
>>     ABS_MT_SLOT 0
>>     ABS_MT_TRACKING_ID 42
>>     ABS_MT_POSITION_X finger_x
>>     ABS_MT_POSITION_Y finger_y
>>     SYN_MT_REPORT
>>     ABS_X finger_x
>>     ABS_Y finger_y
>>     SYN_REPORT
>> # finger release
>>     ABS_MT_SLOT 0
>>     ABS_MT_TRACKING_ID -1
>>     SYN_REPORT
>> # pen motion
>>     BTN_TOOL_PEN 1
>>     ABS_X pen_x
>>     ABS_Y pen_y
>>     SYN_REPORT
>> # finger touch begin
>>     ABS_MT_SLOT 0
>>     ABS_MT_TRACKING_ID 42
>>     ABS_MT_POSITION_X finger_x
>>     ABS_MT_POSITION_Y finger_y
>>     SYN_MT_REPORT
>>     BTN_TOOL_PEN 0
>>     ABS_X finger_x
>>     ABS_Y finger_y
>>     SYN_REPORT
>> etc.
>>
>> Then, xf86-input-evdev ignores ABS_{X,Y} events when there is no
>> BTN_TOOL_* active.
> 
> On the subject how pen and touch could work going forward, the MT
> protocol is prepared to deal with tool type per slot. It makes a lot
> of sense to move away from the above example, towards a fully parallel
> representation of pen and touch data. Today's multitouch interfaces
> are really tremendously restrictive; I am looking forward to the day
> when one does not need to worry about touching or resting on a surface
> in order to operate it.
> 
> In short, why not make xf86-input-evdev aware of MT_TOOL_TYPE?

There's no reason it can't be made aware. The question is whether you
want to create separate X input devices, or annotate events with the
tool type. No one has really bothered looking into it outside of wacom
devices, but my understanding is that wacom is a big special cased
situation due to historical reasons anyway.

If we merely annotate events by setting valuator values, that's a
trivial change that may even be already supported out of the box.
Splitting the evdev device into multiple X input devices is also
possible, since xf86-input-wacom does it, but would require a large
refactoring of xf86-input-evdev.

-- Chase

Re: Mixed "pen" and multitouch input devices

[Chris Bagwell]

2012/3/19 Chase Douglas <chasedouglas@gmail.com>:
> On 03/18/2012 11:39 PM, Henrik Rydberg wrote:
>>> The proper way to send events through evdev when there are two different
>>> "tools" (pen and touch) is to use BTN_TOOL_*. In your example above, it
>>> would be:
>>>
>>> # finger touch (Note lack of tool, it's assumed to be finger)
>>>     ABS_MT_SLOT 0
>>>     ABS_MT_TRACKING_ID 42
>>>     ABS_MT_POSITION_X finger_x
>>>     ABS_MT_POSITION_Y finger_y
>>>     SYN_MT_REPORT
>>>     ABS_X finger_x
>>>     ABS_Y finger_y
>>>     SYN_REPORT
>>> # finger release
>>>     ABS_MT_SLOT 0
>>>     ABS_MT_TRACKING_ID -1
>>>     SYN_REPORT
>>> # pen motion
>>>     BTN_TOOL_PEN 1
>>>     ABS_X pen_x
>>>     ABS_Y pen_y
>>>     SYN_REPORT
>>> # finger touch begin
>>>     ABS_MT_SLOT 0
>>>     ABS_MT_TRACKING_ID 42
>>>     ABS_MT_POSITION_X finger_x
>>>     ABS_MT_POSITION_Y finger_y
>>>     SYN_MT_REPORT
>>>     BTN_TOOL_PEN 0
>>>     ABS_X finger_x
>>>     ABS_Y finger_y
>>>     SYN_REPORT
>>> etc.
>>>
>>> Then, xf86-input-evdev ignores ABS_{X,Y} events when there is no
>>> BTN_TOOL_* active.
>>
>> On the subject how pen and touch could work going forward, the MT
>> protocol is prepared to deal with tool type per slot. It makes a lot
>> of sense to move away from the above example, towards a fully parallel
>> representation of pen and touch data. Today's multitouch interfaces
>> are really tremendously restrictive; I am looking forward to the day
>> when one does not need to worry about touching or resting on a surface
>> in order to operate it.
>>
>> In short, why not make xf86-input-evdev aware of MT_TOOL_TYPE?
>
> There's no reason it can't be made aware. The question is whether you
> want to create separate X input devices, or annotate events with the
> tool type. No one has really bothered looking into it outside of wacom
> devices, but my understanding is that wacom is a big special cased
> situation due to historical reasons anyway.
>
> If we merely annotate events by setting valuator values, that's a
> trivial change that may even be already supported out of the box.
> Splitting the evdev device into multiple X input devices is also
> possible, since xf86-input-wacom does it, but would require a large
> refactoring of xf86-input-evdev.
>

FWIW, non-wacom pen+touch devices should work with current
xf86-input-wacom if they use above events.  You will get split devices
as long as you modify xorg.conf.d to route this input.  MT events will
be treated roughly like xf86-input-synaptics would treat DOUBLETAP
though (internal 1 and 2 finger gesture support only).

My plan is to take your xf86-input-evdev/synaptics X Input 2.2 work
and merge it into xf86-input-wacom soon to benefit from those
improvements.  In addition to Wacom MT hardware, I try to occasionally
test xf86-input-wacom with a hid-multitouch touchscreen to verify it
isn't needlessly wacom specific.

Having said that, I think its good to improve multi-tool support in
xf86-input-evdev in parallel to the multi-touch improvements.  In
addition, xf86-input-evdev would be a much better base to start
experimenting with annotating events.

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