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.
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
