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