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