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

[Peter Hutterer <peter.hutterer@who-t.net>]

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