Bug 54250 - touching a button on Intuos5 makes a "silent" cursor jump to top-left corner
Summary: touching a button on Intuos5 makes a "silent" cursor jump to top-left corner
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Input/wacom (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Jason Gerecke
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-08-30 08:00 UTC by Timo Aaltonen
Modified: 2012-10-16 05:57 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Timo Aaltonen 2012-08-30 08:00:37 UTC
I get extra lines with gimp leading to the top-left corner when I touch the buttons on my Intuos5 S while drawing. No need to touch the button down, just showing the finger seems to be enough..

Happens with 1.12.99.905 server, kernel 3.5, -wacom 0.16+git9f32b03.
Comment 1 Timo Aaltonen 2012-08-30 08:13:49 UTC
by "silent" I mean the cursor doesn't seem to jump there, but gimp shows these streaks..

xev shows this even when that happens:

KeymapNotify event, serial 42, synthetic NO, window 0x0,
    keys:  4294967235 0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
Comment 2 Timo Aaltonen 2012-09-13 12:36:00 UTC
still the same with kernel 3.6-rc5, -wacom 0.17.
Comment 3 Jason Gerecke 2012-09-13 22:59:04 UTC
After some poking around, I think I've tracked down the cause of this behavior.

When touching (but not pressing) a button, the kernel driver mostly ignores the hardware event it receives. The out-of-prox logic is triggered, and we send an event indicating the pad has left proximity. The problem is that since the pad never *entered* proximity, it can leave the X driver a little confused.

When a new packet comes in from the kernel, the X driver uses the serial number to find the appropriate "channel" to store event data in. It then updates the most-recent information in that channel with the packet data and processes the result as an event. An excess out-of-prox event starts from an empty state, causing the driver to ask the kernel for the tool that is currently in proximity. If it finds something, an empty event is sent for that tool, causing a momentary jump to the top-left corner.

There are two ways I see to fix this bug: a) have the kernel send an (empty) in-prox event for button touches so the X driver doesn't get confused, b) have the X driver ignore out-of-prox events for already out-of-prox tools.
Comment 4 Timo Aaltonen 2012-09-14 04:57:57 UTC
I could certainly use a patch for the X driver, faster to get it accepted as a stable update :) Don't mind if the kernel would get fixed later.
Comment 6 Timo Aaltonen 2012-09-17 18:51:14 UTC
I've tested the X driver patch, and it's working great, thanks. I'll test the kernel one too (without the patched -wacom driver).
Comment 7 Jason Gerecke 2012-10-02 18:23:29 UTC
Patches have been accepted upstream.
Comment 8 Florian Mickler 2012-10-15 20:52:08 UTC
A patch referencing this bug report has been merged in Linux v3.7-rc1:

commit 5e056ef4ddeb6129f6bb170f2c26b8f370bbcda7
Author: Jason Gerecke <killertofu@gmail.com>
Date:   Mon Sep 24 09:21:31 2012 -0700

    Input: wacom - mark Intuos5 pad as in-prox when touching buttons
Comment 9 Peter Hutterer 2012-10-16 05:57:59 UTC
xf86-input-wacom commit: 

commit 0fe7f800295a4b5bf074bca798cf8024fcb174ec
Author: Jason Gerecke <killertofu@gmail.com>
Date:   Thu Sep 13 16:59:01 2012 -0700

    Ignore out-of-prox events from unknown devices already out-of-prox


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.