[PATCH 1/3] Input: wacom - allow both MT and pen data to be reported

[PATCH 1/3] Input: wacom - allow both MT and pen data to be reported

[Ping Cheng]

It was suggested by app and X server developers that both MT and pen data
should be reported to the userland if the data is valid. Bamboo series are
among these devices that both data are valid from the hardware perspective.

Signed-off-by: Ping Cheng <pingc@wacom.com>
---
 drivers/input/tablet/wacom_wac.c |   13 +++++++------
 1 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
index b3252ef..b9534a1 100644
--- a/drivers/input/tablet/wacom_wac.c
+++ b/drivers/input/tablet/wacom_wac.c
@@ -868,13 +868,14 @@ static int wacom_bpt_touch(struct wacom_wac *wacom)
 	for (i = 0; i < 2; i++) {
 		int p = data[9 * i + 2];
 		input_mt_slot(input, i);
-		/*
-		 * Touch events need to be disabled while stylus is
-		 * in proximity because user's hand is resting on touchpad
-		 * and sending unwanted events.  User expects tablet buttons
-		 * to continue working though.
+
+		/* We send touch events even a stylus is in proximity. Apps or
+		 * userland clients have the opportunity to arbitrate these events
+		 * when pen is in proximity.
+		 * Wacom X server driver arbitrates the events for all apps that
+		 * are based on X server.
 		 */
-		if (p && !wacom->shared->stylus_in_proximity) {
+		if (p) {
 			int x = get_unaligned_be16(&data[9 * i + 3]) & 0x7ff;
 			int y = get_unaligned_be16(&data[9 * i + 5]) & 0x7ff;
 			if (features->quirks & WACOM_QUIRK_BBTOUCH_LOWRES) {
-- 
1.7.2.3

Re: [1/3] Input: wacom - allow both MT and pen data to be reported

[Henrik Rydberg]

On 11/03/2010 12:37 AM, Ping Cheng wrote:

> It was suggested by app and X server developers that both MT and pen data
> should be reported to the userland if the data is valid. Bamboo series are
> among these devices that both data are valid from the hardware perspective.
> 
> Signed-off-by: Ping Cheng <pingc@wacom.com>
> 
> ---
> drivers/input/tablet/wacom_wac.c |   13 +++++++------
>  1 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
> index b3252ef..b9534a1 100644
> --- a/drivers/input/tablet/wacom_wac.c
> +++ b/drivers/input/tablet/wacom_wac.c
> @@ -868,13 +868,14 @@ static int wacom_bpt_touch(struct wacom_wac *wacom)
>  	for (i = 0; i < 2; i++) {
>  		int p = data[9 * i + 2];
>  		input_mt_slot(input, i);
> -		/*
> -		 * Touch events need to be disabled while stylus is
> -		 * in proximity because user's hand is resting on touchpad
> -		 * and sending unwanted events.  User expects tablet buttons
> -		 * to continue working though.
> +
> +		/* We send touch events even a stylus is in proximity. Apps or
> +		 * userland clients have the opportunity to arbitrate these events
> +		 * when pen is in proximity.
> +		 * Wacom X server driver arbitrates the events for all apps that
> +		 * are based on X server.
>  		 */
> -		if (p && !wacom->shared->stylus_in_proximity) {
> +		if (p) {
>  			int x = get_unaligned_be16(&data[9 * i + 3]) & 0x7ff;
>  			int y = get_unaligned_be16(&data[9 * i + 5]) & 0x7ff;
>  			if (features->quirks & WACOM_QUIRK_BBTOUCH_LOWRES) {


This seems to be an exact revert of 33d5f713a, minus the comments. Perhaps a
revert with the comment in the commit message instead?

Thanks,
Henrik

Re: [PATCH 1/3] Input: wacom - allow both MT and pen data to be reported

[Chris Bagwell]

On Tue, Nov 2, 2010 at 6:37 PM, Ping Cheng <pinglinux@gmail.com> wrote:
> It was suggested by app and X server developers that both MT and pen data
> should be reported to the userland if the data is valid. Bamboo series are
> among these devices that both data are valid from the hardware perspective.
>
> Signed-off-by: Ping Cheng <pingc@wacom.com>
> ---
>  drivers/input/tablet/wacom_wac.c |   13 +++++++------
>  1 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
> index b3252ef..b9534a1 100644
> --- a/drivers/input/tablet/wacom_wac.c
> +++ b/drivers/input/tablet/wacom_wac.c
> @@ -868,13 +868,14 @@ static int wacom_bpt_touch(struct wacom_wac *wacom)
>        for (i = 0; i < 2; i++) {
>                int p = data[9 * i + 2];
>                input_mt_slot(input, i);
> -               /*
> -                * Touch events need to be disabled while stylus is
> -                * in proximity because user's hand is resting on touchpad
> -                * and sending unwanted events.  User expects tablet buttons
> -                * to continue working though.
> +
> +               /* We send touch events even a stylus is in proximity. Apps or
> +                * userland clients have the opportunity to arbitrate these events
> +                * when pen is in proximity.
> +                * Wacom X server driver arbitrates the events for all apps that
> +                * are based on X server.
>                 */
> -               if (p && !wacom->shared->stylus_in_proximity) {
> +               if (p) {
>                        int x = get_unaligned_be16(&data[9 * i + 3]) & 0x7ff;
>                        int y = get_unaligned_be16(&data[9 * i + 5]) & 0x7ff;
>                        if (features->quirks & WACOM_QUIRK_BBTOUCH_LOWRES) {
> --
> 1.7.2.3

I do not think we can remove this at this time; although I've heard
request before and why the original patch was separate.

The issue is that tablet is isolated on one input device and touchpad
on another.  This means, for example, that tablet can be handled by
xf86-input-wacom and touchpad by xf86-input-synaptics.  There is no
communication between the two apps so that xf86-input-synaptics would
know to disable itself while pen is in proximity.  Reverting the patch
in this combo would cause unwanted cursor movements.

When handled by a new xf86-input-wacom (or similar) then technically
there can be some communication to do masking but today that
communication does not exist across unrelated input devices.
Reverting the patch would also cause unwanted cursor movements in
today's xf86-input-wacom.

One thing that would need to occur first is wacom driver would need to
publish some sort of ID so that user land can tell which two devices
are somehow related; also accounting for 2 wacom devices being plugged
in at same time.  Next, if implemented, I'd make it a sysfs option to
control behavior so user has choice to also use apps like
xf86-input-multitouch which can't do masking.

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: [PATCH 1/3] Input: wacom - allow both MT and pen data to be reported

[Dmitry Torokhov]

On Wed, Nov 03, 2010 at 09:10:28AM -0500, Chris Bagwell wrote:
> On Tue, Nov 2, 2010 at 6:37 PM, Ping Cheng <pinglinux@gmail.com> wrote:
> > It was suggested by app and X server developers that both MT and pen data
> > should be reported to the userland if the data is valid. Bamboo series are
> > among these devices that both data are valid from the hardware perspective.
> >
> > Signed-off-by: Ping Cheng <pingc@wacom.com>
> > ---
> >  drivers/input/tablet/wacom_wac.c |   13 +++++++------
> >  1 files changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
> > index b3252ef..b9534a1 100644
> > --- a/drivers/input/tablet/wacom_wac.c
> > +++ b/drivers/input/tablet/wacom_wac.c
> > @@ -868,13 +868,14 @@ static int wacom_bpt_touch(struct wacom_wac *wacom)
> >        for (i = 0; i < 2; i++) {
> >                int p = data[9 * i + 2];
> >                input_mt_slot(input, i);
> > -               /*
> > -                * Touch events need to be disabled while stylus is
> > -                * in proximity because user's hand is resting on touchpad
> > -                * and sending unwanted events.  User expects tablet buttons
> > -                * to continue working though.
> > +
> > +               /* We send touch events even a stylus is in proximity. Apps or
> > +                * userland clients have the opportunity to arbitrate these events
> > +                * when pen is in proximity.
> > +                * Wacom X server driver arbitrates the events for all apps that
> > +                * are based on X server.
> >                 */
> > -               if (p && !wacom->shared->stylus_in_proximity) {
> > +               if (p) {
> >                        int x = get_unaligned_be16(&data[9 * i + 3]) & 0x7ff;
> >                        int y = get_unaligned_be16(&data[9 * i + 5]) & 0x7ff;
> >                        if (features->quirks & WACOM_QUIRK_BBTOUCH_LOWRES) {
> > --
> > 1.7.2.3
> 
> I do not think we can remove this at this time; although I've heard
> request before and why the original patch was separate.
> 
> The issue is that tablet is isolated on one input device and touchpad
> on another.  This means, for example, that tablet can be handled by
> xf86-input-wacom and touchpad by xf86-input-synaptics.  There is no
> communication between the two apps so that xf86-input-synaptics would
> know to disable itself while pen is in proximity.

Future version of xf86-input-synaptics might be able to open the other
wacom interface and monitor events (just monitor, still letting
xf86-input-wacom to do the main job, and diable touch processing when
stylos is in proximity). Not sure if it the best way or if it is easier
to move everything in xf86-input-wacom.

>  Reverting the patch
> in this combo would cause unwanted cursor movements.
> 
> When handled by a new xf86-input-wacom (or similar) then technically
> there can be some communication to do masking but today that
> communication does not exist across unrelated input devices.
> Reverting the patch would also cause unwanted cursor movements in
> today's xf86-input-wacom.
> 
> One thing that would need to occur first is wacom driver would need to
> publish some sort of ID so that user land can tell which two devices
> are somehow related; also accounting for 2 wacom devices being plugged
> in at same time.

I guess it should be possible to examine 'phys' attribute and see that
both input devices are connected to the same USB parent, although I do
not like this too much.

>  Next, if implemented, I'd make it a sysfs option to
> control behavior so user has choice to also use apps like
> xf86-input-multitouch which can't do masking.

The problem with the options like this is that we assume that they are
the sole "owners" of the datastream. And time and time again there
scenarios where some other application with different requirements might
want to have different behavior than the "main" consumer.

I agree that we should not be breaking the xf86-input-synaptics until it
is ready.

-- 
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: [PATCH 1/3] Input: wacom - allow both MT and pen data to be reported

[Peter Hutterer]

On Wed, Nov 03, 2010 at 09:10:28AM -0500, Chris Bagwell wrote:
> On Tue, Nov 2, 2010 at 6:37 PM, Ping Cheng <pinglinux@gmail.com> wrote:
> > It was suggested by app and X server developers that both MT and pen data
> > should be reported to the userland if the data is valid. Bamboo series are
> > among these devices that both data are valid from the hardware perspective.
> >
> > Signed-off-by: Ping Cheng <pingc@wacom.com>
> > ---
> >  drivers/input/tablet/wacom_wac.c |   13 +++++++------
> >  1 files changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
> > index b3252ef..b9534a1 100644
> > --- a/drivers/input/tablet/wacom_wac.c
> > +++ b/drivers/input/tablet/wacom_wac.c
> > @@ -868,13 +868,14 @@ static int wacom_bpt_touch(struct wacom_wac *wacom)
> >        for (i = 0; i < 2; i++) {
> >                int p = data[9 * i + 2];
> >                input_mt_slot(input, i);
> > -               /*
> > -                * Touch events need to be disabled while stylus is
> > -                * in proximity because user's hand is resting on touchpad
> > -                * and sending unwanted events.  User expects tablet buttons
> > -                * to continue working though.
> > +
> > +               /* We send touch events even a stylus is in proximity. Apps or
> > +                * userland clients have the opportunity to arbitrate these events
> > +                * when pen is in proximity.
> > +                * Wacom X server driver arbitrates the events for all apps that
> > +                * are based on X server.
> >                 */
> > -               if (p && !wacom->shared->stylus_in_proximity) {
> > +               if (p) {
> >                        int x = get_unaligned_be16(&data[9 * i + 3]) & 0x7ff;
> >                        int y = get_unaligned_be16(&data[9 * i + 5]) & 0x7ff;
> >                        if (features->quirks & WACOM_QUIRK_BBTOUCH_LOWRES) {
> > --
> > 1.7.2.3
> 
> I do not think we can remove this at this time; although I've heard
> request before and why the original patch was separate.
> 
> The issue is that tablet is isolated on one input device and touchpad
> on another.  This means, for example, that tablet can be handled by
> xf86-input-wacom and touchpad by xf86-input-synaptics.  There is no
> communication between the two apps so that xf86-input-synaptics would
> know to disable itself while pen is in proximity.  Reverting the patch
> in this combo would cause unwanted cursor movements.

note that we have a similar tool in place for keyboards and touchpads with
syndaemon. again, there is no communication between the drivers, it's purely
client-side, monitoring the keyboard and flipping the property to disable
the driver as required. not perfect, but it does the job.

for the touchpad, you could monitor DeviceProximity events on the tablet and
then do the same thing. of course, we should have some way of matching the
input devices that belong to the same physical tablet. syndaemon has an easy
job here, usually we only have one touchpad on a laptop.

Cheers,
  Peter

 
> When handled by a new xf86-input-wacom (or similar) then technically
> there can be some communication to do masking but today that
> communication does not exist across unrelated input devices.
> Reverting the patch would also cause unwanted cursor movements in
> today's xf86-input-wacom.
> 
> One thing that would need to occur first is wacom driver would need to
> publish some sort of ID so that user land can tell which two devices
> are somehow related; also accounting for 2 wacom devices being plugged
> in at same time.  Next, if implemented, I'd make it a sysfs option to
> control behavior so user has choice to also use apps like
> xf86-input-multitouch which can't do masking.
> 
> 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: [PATCH 1/3] Input: wacom - allow both MT and pen data to be reported

[Chris Bagwell]

On Thu, Nov 4, 2010 at 12:46 AM, Peter Hutterer
<peter.hutterer@who-t.net> wrote:
> On Wed, Nov 03, 2010 at 09:10:28AM -0500, Chris Bagwell wrote:
>> On Tue, Nov 2, 2010 at 6:37 PM, Ping Cheng <pinglinux@gmail.com> wrote:
>> > It was suggested by app and X server developers that both MT and pen data
>> > should be reported to the userland if the data is valid. Bamboo series are
>> > among these devices that both data are valid from the hardware perspective.
>> >
>> > Signed-off-by: Ping Cheng <pingc@wacom.com>
>> > ---
>> >  drivers/input/tablet/wacom_wac.c |   13 +++++++------
>> >  1 files changed, 7 insertions(+), 6 deletions(-)
>> >
>> > diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
>> > index b3252ef..b9534a1 100644
>> > --- a/drivers/input/tablet/wacom_wac.c
>> > +++ b/drivers/input/tablet/wacom_wac.c
>> > @@ -868,13 +868,14 @@ static int wacom_bpt_touch(struct wacom_wac *wacom)
>> >        for (i = 0; i < 2; i++) {
>> >                int p = data[9 * i + 2];
>> >                input_mt_slot(input, i);
>> > -               /*
>> > -                * Touch events need to be disabled while stylus is
>> > -                * in proximity because user's hand is resting on touchpad
>> > -                * and sending unwanted events.  User expects tablet buttons
>> > -                * to continue working though.
>> > +
>> > +               /* We send touch events even a stylus is in proximity. Apps or
>> > +                * userland clients have the opportunity to arbitrate these events
>> > +                * when pen is in proximity.
>> > +                * Wacom X server driver arbitrates the events for all apps that
>> > +                * are based on X server.
>> >                 */
>> > -               if (p && !wacom->shared->stylus_in_proximity) {
>> > +               if (p) {
>> >                        int x = get_unaligned_be16(&data[9 * i + 3]) & 0x7ff;
>> >                        int y = get_unaligned_be16(&data[9 * i + 5]) & 0x7ff;
>> >                        if (features->quirks & WACOM_QUIRK_BBTOUCH_LOWRES) {
>> > --
>> > 1.7.2.3
>>
>> I do not think we can remove this at this time; although I've heard
>> request before and why the original patch was separate.
>>
>> The issue is that tablet is isolated on one input device and touchpad
>> on another.  This means, for example, that tablet can be handled by
>> xf86-input-wacom and touchpad by xf86-input-synaptics.  There is no
>> communication between the two apps so that xf86-input-synaptics would
>> know to disable itself while pen is in proximity.  Reverting the patch
>> in this combo would cause unwanted cursor movements.
>
> note that we have a similar tool in place for keyboards and touchpads with
> syndaemon. again, there is no communication between the drivers, it's purely
> client-side, monitoring the keyboard and flipping the property to disable
> the driver as required. not perfect, but it does the job.
>
> for the touchpad, you could monitor DeviceProximity events on the tablet and
> then do the same thing. of course, we should have some way of matching the
> input devices that belong to the same physical tablet. syndaemon has an easy
> job here, usually we only have one touchpad on a laptop.

Matching problem is really the only technical issue with removing it.
Can we propose a way of ID'ing two related devices?

If we can bound the problem by saying 2 related inputs will always be
controlled by a single kernel driver then its easy to create a unique
ID at plugin.

If we tack the ID on to the device name, then it would already make it
to xinput and similar items so even user can also see associations.
Ping has implemented a version of this in the past.

Are there any better ideas?

Chris

>
> Cheers,
>  Peter
>
>
>> When handled by a new xf86-input-wacom (or similar) then technically
>> there can be some communication to do masking but today that
>> communication does not exist across unrelated input devices.
>> Reverting the patch would also cause unwanted cursor movements in
>> today's xf86-input-wacom.
>>
>> One thing that would need to occur first is wacom driver would need to
>> publish some sort of ID so that user land can tell which two devices
>> are somehow related; also accounting for 2 wacom devices being plugged
>> in at same time.  Next, if implemented, I'd make it a sysfs option to
>> control behavior so user has choice to also use apps like
>> xf86-input-multitouch which can't do masking.
>>
>> 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: [PATCH 1/3] Input: wacom - allow both MT and pen data to be reported

[Peter Hutterer]

On Thu, Nov 04, 2010 at 08:08:29AM -0500, Chris Bagwell wrote:
> On Thu, Nov 4, 2010 at 12:46 AM, Peter Hutterer
> <peter.hutterer@who-t.net> wrote:
> > On Wed, Nov 03, 2010 at 09:10:28AM -0500, Chris Bagwell wrote:
> >> On Tue, Nov 2, 2010 at 6:37 PM, Ping Cheng <pinglinux@gmail.com> wrote:
> >> > It was suggested by app and X server developers that both MT and pen data
> >> > should be reported to the userland if the data is valid. Bamboo series are
> >> > among these devices that both data are valid from the hardware perspective.
> >> >
> >> > Signed-off-by: Ping Cheng <pingc@wacom.com>
> >> > ---
> >> >  drivers/input/tablet/wacom_wac.c |   13 +++++++------
> >> >  1 files changed, 7 insertions(+), 6 deletions(-)
> >> >
> >> > diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
> >> > index b3252ef..b9534a1 100644
> >> > --- a/drivers/input/tablet/wacom_wac.c
> >> > +++ b/drivers/input/tablet/wacom_wac.c
> >> > @@ -868,13 +868,14 @@ static int wacom_bpt_touch(struct wacom_wac *wacom)
> >> >        for (i = 0; i < 2; i++) {
> >> >                int p = data[9 * i + 2];
> >> >                input_mt_slot(input, i);
> >> > -               /*
> >> > -                * Touch events need to be disabled while stylus is
> >> > -                * in proximity because user's hand is resting on touchpad
> >> > -                * and sending unwanted events.  User expects tablet buttons
> >> > -                * to continue working though.
> >> > +
> >> > +               /* We send touch events even a stylus is in proximity. Apps or
> >> > +                * userland clients have the opportunity to arbitrate these events
> >> > +                * when pen is in proximity.
> >> > +                * Wacom X server driver arbitrates the events for all apps that
> >> > +                * are based on X server.
> >> >                 */
> >> > -               if (p && !wacom->shared->stylus_in_proximity) {
> >> > +               if (p) {
> >> >                        int x = get_unaligned_be16(&data[9 * i + 3]) & 0x7ff;
> >> >                        int y = get_unaligned_be16(&data[9 * i + 5]) & 0x7ff;
> >> >                        if (features->quirks & WACOM_QUIRK_BBTOUCH_LOWRES) {
> >> > --
> >> > 1.7.2.3
> >>
> >> I do not think we can remove this at this time; although I've heard
> >> request before and why the original patch was separate.
> >>
> >> The issue is that tablet is isolated on one input device and touchpad
> >> on another.  This means, for example, that tablet can be handled by
> >> xf86-input-wacom and touchpad by xf86-input-synaptics.  There is no
> >> communication between the two apps so that xf86-input-synaptics would
> >> know to disable itself while pen is in proximity.  Reverting the patch
> >> in this combo would cause unwanted cursor movements.
> >
> > note that we have a similar tool in place for keyboards and touchpads with
> > syndaemon. again, there is no communication between the drivers, it's purely
> > client-side, monitoring the keyboard and flipping the property to disable
> > the driver as required. not perfect, but it does the job.
> >
> > for the touchpad, you could monitor DeviceProximity events on the tablet and
> > then do the same thing. of course, we should have some way of matching the
> > input devices that belong to the same physical tablet. syndaemon has an easy
> > job here, usually we only have one touchpad on a laptop.
> 
> Matching problem is really the only technical issue with removing it.
> Can we propose a way of ID'ing two related devices?
> 
> If we can bound the problem by saying 2 related inputs will always be
> controlled by a single kernel driver then its easy to create a unique
> ID at plugin.
> 
> If we tack the ID on to the device name, then it would already make it
> to xinput and similar items so even user can also see associations.
> Ping has implemented a version of this in the past.
> 
> Are there any better ideas?

we already have a serial ID property or so in the X driver, it's easy enough
to tack another ID on that's generated for the first device and handed down
to the hotplugged dependent ones.
I strongly suggest _not_ using IDs in names, they're just not reliable.

Can't comment on the ID coming out of the kernel, I don't know the kernel
well enough.

Cheers,
  Peter
--
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