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