Ubuntu

[SRU] Intuos3 Wacom buttons cause mouse to move to upper left corner and click.

Reported by bassam on 2010-04-10
180
This bug affects 34 people
Affects Status Importance Assigned to Milestone
xf86-input-wacom (Ubuntu)
Medium
Unassigned
Lucid
Medium
Unassigned

Bug Description

Since upgrading to Lucid, the buttons both for wacom intous 3 and intous 4 don't work, and cause the cursor to jump to the top-left corner of the screen. I can't change this behavior with xsetwacom. Even he scroll wheel/scroll pad does the same thing. As a result, all buttons/scrolling utilities are rendered unusable.

A newer release of the program fixes the problems that were present. Please consider this as an SRU for Lucid as this bug renders much of a tablet's features useless. The site with the changelog:

http://linuxwacom.git.sourceforge.net/git/gitweb.cgi?p=linuxwacom/xf86-input-wacom;a=commitdiff;h=2038ad187823b770fcb3b5e77dacf4bad27617e6

The diff between versions that fixes the bug:

------------------
--- a/src/wcmValidateDevice.c
+++ b/src/wcmValidateDevice.c
@@ -333,9 +333,9 @@ int wcmParseOptions(LocalDevicePtr local)
                 */
        }
- /* Pad is always in absolute mode. */
+ /* Pad is always in relative mode. */
        if (IsPad(priv))
- priv->flags |= ABSOLUTE_FLAG;
+ priv->flags &= ~ABSOLUTE_FLAG;
        /* Store original local Core flag so it can be changed later */
        if (local->flags & (XI86_ALWAYS_CORE | XI86_CORE_POINTER))
------------------

The reasoning:

"The pad cannot be in absolute mode as it sends the axis values to the
server. Since the pad never gets x/y coordinates from the tablet the server
will fill in the defaults (0/0) for it - even if first_valuator is always >
1. This results in the pointer being reset to the screen origin each time
the pad's scroll strip is used."

------------------

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: xserver-xorg-input-wacom 1:0.10.5-0ubuntu2
ProcVersionSignature: Ubuntu 2.6.32-19.28-generic 2.6.32.10+drm33.1
Uname: Linux 2.6.32-19-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Sat Apr 10 14:05:10 2010
DkmsStatus: nvidia-current, 195.36.15, 2.6.32-19-generic, x86_64: installed
MachineType: LENOVO 8891CTO
PccardctlIdent:
 Socket 0:
   no product info available
PccardctlStatus:
 Socket 0:
   no card
ProcCmdLine: root=UUID=4b2ceea8-7d33-40f0-adb1-0f733a258618 ro quiet splash
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: xf86-input-wacom
system:
 distro: Ubuntu
 codename: lucid
 architecture: x86_64
 kernel: 2.6.32-19-generic

bassam (bkurdali) wrote :

Same problems here.

Changed in xf86-input-wacom (Ubuntu):
status: New → Confirmed
summary: - wacom buttons don't work
+ wacom buttons don't work/cause mouse to move to upper left corner and
+ click.

Have the same problem with my Intuos3 on a Desktop.

peterbiglr (peter-biglr) wrote :

I can confirm the same problem on Wacom Bamboo

peterbiglr (peter-biglr) wrote :

when using any of the buttons or the scrollwheel a LeaveNotify event is generated.

Output using `xev`:

LeaveNotify event, serial 30, synthetic NO, window 0x4000001,
    root 0x10f, subw 0x0, time 4889396, (-59,-639), root:(0,0),
    mode NotifyNormal, detail NotifyNonlinear, same_screen YES,
    focus NO, state 16

Guédon Mickaël (ebrain) wrote :

Same problem here with Wacom Intuos3 A4.

CB (christopherbrailsford) wrote :

Similar problems - tablet constantly clicks if a pen put in movement range on a Wacom Bamboo One (Model CTF-430)

skam (cbissuel) wrote :

Same problem with a Cintiq 21UX

Popolon (popolon) wrote :

there is no more wacdump standard in wacom-tools for debugging purpose in Lucid ?

Wacom-tools package disappear from synaptic but is still referenced as dependency :

sudo apt-get install wacom-tools
Reading package lists... Done
Building dependency tree
Reading state information... Done
Package wacom-tools is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
  xserver-xorg-input-wacom
E: Package wacom-tools has no installation candidate

bassam (bkurdali) wrote :

Some more info:
problem happens on fresh installs as well as upgrades.
problem affects wacom intuos 3, 4 and bamboo tablets
it is possible to use xsetwacom to remap the buttons but the touch strip/scroll remains affected
some old xsetwacom commands that used to work on karmic i.e. to set the button to a numpad key, no longer work.

Johan Lejonborn (soltrumman) wrote :

Hi. This bug affects me too.

After some "digging" i have found out that there is a bug-fix commited upstream for this bug.

http://<email address hidden>/msg00736.html

Upgrading to xf86-input-wacom 0.10.6 should also solve this issue.

http://permalink.gmane.org/gmane.linux.drivers.wacom.devel/870

(Always put pad i relative mode is in the changelog for 0.10.6)

Ryan Wooden (ryan.wooden) wrote :

I can confirm that the latest xf86-input-wacom drivers fix the problem. I installed from source following: http://ubuntuforums.org/showpost.php?p=6546012&postcount=1

I too can confirm that the latest xf86-input-wacom drivers fix the problem, so long as you make sure to keep the original 10-wacom.conf file.

Changed in linuxwacom:
status: New → Fix Committed
description: updated
mr. Ed (mred) wrote :

This bug affect to Wacom series Bamboo Fun

mr. Ed (mred) on 2010-05-11
tags: added: i386 wacom
Kay (noiq) wrote :

Graphire4 (CTE-640) shows the same problem.

Thank you for the help, but the problem has been recognized. No need for any more confirmations :).

Regarding SRU updates, it seems (per the SRU Updates wiki) that what is missing in this report is:

1) A patch with the minimal fix that can fix the current package (i.e. setting to relative mode, none other)
2) An upload of the fixed package to release-proposed, the above patch, and a changelog.

So it is still up to us to help get this going. I cannot write this patch, so the task cannot rely on me.

can someone confirm that the bug described in #577608 is fixed upstream as well?
I have trouble believing that the difference between absolute and relative mode affect the way special keys are addressed, yet it is marked as duplicate.
some of the affected keys are: "core key +", "... -", ',' , '.' ... basically every special key

Milan Knizek (knizek) wrote :

I tried to apply the patch mentioned in #11:
http://<email address hidden>/msg00736.html
to the current version of linuxwaxom in Lucid and recompiled the deb package.

The buttons on my Intuos3 work, but the left and right touchpad not - nothing happens and keys assigned by xsetwacom for the touchpads are ignored.

(Compiling from current git resulted in even worse behaviour - apart from the touchpads, also the press of a button lead to positioning of the cursor to left-top corner of the screen.)

ManDay (manday) wrote :

I have the same problem and came to the same conclusion trying things out with xinput. Then I thought setting the tablet to relative would help it because that would mean a relative movement of 0 but there are two problems with that. The major one being:

xinput set-mode 8 RELATIVE
X Error of failed request: XI_BadMode (invalid Mode parameter)
  Major opcode of failed request: 143 (XInputExtension)
  Minor opcode of failed request: 5 (X_SetDeviceMode)
  Mode id in failed request: 0x17
  Serial number of failed request: 17
  Current serial number in output stream: 17

Works fine for the stylus but the pad does not know relative mode at all. Great...

The second problem being that relative is not necessarily what I want. Although less noticeable the same problem exists for the stylus in vice versa - which resets the touchring to 0! and here RELATIVE is NOT an option. Then, the touchring might be preferred to be absolute anyway.

That's very bad. Maybe someone has an idea on how to merge the data from the stylus and that from the tablet into one motion-positional tuple so no values overwrite the others!?

ManDay (manday) wrote :

Latest xf86 modules solve that.

nh2 (nh2) wrote :

Confirmed in 10.04, seems to be fixed in 10.10.

Guédon Mickaël (ebrain) wrote :

It's DEFINITELY NOT TOTALLY FIXED in Ubuntu Maverick.

Yes, it does work with the buttons on the pad, but the strips are still out !
I'm using an Intuos3, Maverick x86-64.

As a graphic artist, I would use them very often, so please fix this.
Thank you.

summary: - wacom buttons don't work/cause mouse to move to upper left corner and
- click.
+ [SRU] Wacom buttons cause mouse to move to upper left corner and click.
description: updated

Looking at the git commit showed that there was another section that needed to be edited for setting the mode.

I have created a branch that applied the patch - I have also updated the description with the diff. Would be helpful if someone could confirm that this fixes the issue.

mr. Ed (mred) wrote :

The error in Maverick Ubunutu 10.10 is fixed.

The error in Ubuntu Lucid 10.04 still persists.

mr. Ed (mred) wrote :

The error in Maverick Ubunutu 10.10 is fixed.

The error in Ubuntu Lucid 10.04 still persists.

Bryce Harrington (bryce) wrote :

Needs commit 2038ad187823b770fcb3b5e77dacf4bad27617e6 and perhaps 5f4bc4d43bce84dd84192d3cc9fb7a9ad5b1031d.

Bryce Harrington (bryce) wrote :

This patch seems to be related (and dependent on) the first one. Don't know if only the first patch is good enough as a fix or if we really want both... this should be reviewed.

Changed in xf86-input-wacom (Ubuntu Lucid):
status: New → Triaged
importance: Undecided → Medium
Changed in xf86-input-wacom (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Triaged

Still broken in Natty:
- if stylus is held on the tablet while pressing a button or using touch ring then mouse cursor will flicker rapidly between the upper left corner and the original location repeatedly

- if stylus is not on the tablet while pressing a button or using touch ring then mouse cursor will jump to the upper left corner permanently

Kay (noiq) wrote :

For me the buttons of the tablet show similar problems:
- at the beginning of a clean session, without having used the stylus at all, I get the same result as klerfayt with the stylus not on the tablet

- the first time I use stylus (continuously), to position the curser correctly, the scroll wheel and the buttons seem to work correctly, i.e. no flickering for me

- after having lifted the stylus (the first time after login), the buttons and the scroll wheel stop working completely

I am using a graphire4 (CTE-640)

Favux (favux-is) wrote :

Kay,

The Graphire issue has been addressed. A kernel patch that fixes it, graphire.diff, has been posted. See 782756: https://bugs.launchpad.net/ubuntu/+source/xf86-input-wacom/+bug/782756

azathothgr (azathothgr) wrote :

Can confirm broken in Natty : xf86-input-wacom : 0.10.11

I tried to apply the always relative patch manually to wcmXCommand.c and wcmValidateDevice.c, but the second file seems to have changed.
I've changed line 516 and following as such, which seems equivalent:
 if (IsPad(priv))
 {
  priv->wheelup = 4;
  priv->wheeldn = 5;
  /* set_absolute(pInfo, TRUE); */
  set_absolute(pInfo, FALSE);
 }

The pad still starts in absolute mode, though it can be set to Relative with XSetWacom. After that it can't be set back to absolute, which is expected.
However, the problem still persists even when xsetwacom reports the pad as being in relative mode, so I'm guessing the above is not quite right ..

What would be the correct way to set the pad in relative mode by default?

azathothgr (azathothgr) wrote :

Can confirm broken in Natty :
xf86-input-wacom : 0.10.11

I tried to apply the always relative patch manually to wcmXCommand.c and wcmValidateDevice.c, but the second file seems to have changed.
I've changed line 516 and following as such, which seems equivalent:
 if (IsPad(priv))
 {
  priv->wheelup = 4;
  priv->wheeldn = 5;
  /* set_absolute(pInfo, TRUE); */
  set_absolute(pInfo, FALSE);
 }

The pad still starts in absolute mode, though it can be set to Relative with XSetWacom. After that it can't be set back to absolute, which is expected.
However, the problem still persists even when xsetwacom reports the pad as being in relative mode, so I'm guessing the above is not quite right ..

What would be the correct way to set the pad in relative mode by default?

azathothgr (azathothgr) wrote :

Can confirm broken in Natty :
xf86-input-wacom : 0.10.11

I tried to apply the always relative patch manually to wcmXCommand.c and wcmValidateDevice.c, but the second file seems to have changed.
I've changed line 516 and following as such, which seems equivalent:
 if (IsPad(priv))
 {
  priv->wheelup = 4;
  priv->wheeldn = 5;
  set_absolute(pInfo, FALSE);
 }

The pad still starts in absolute mode, though it can be set to Relative with XSetWacom. After that it can't be set back to absolute, which is expected.
However, the problem still persists even when xsetwacom reports the pad as being in relative mode, so I'm guessing the above is not quite right ..

What would be the correct way to set the pad in relative mode by default?

azathothgr (azathothgr) wrote :

Whoops, sorry about that ... An error window kept popping up while I tried to post, didn't realize it was actually working.

Bryce Harrington (bryce) on 2011-06-21
summary: - [SRU] Wacom buttons cause mouse to move to upper left corner and click.
+ [SRU] Intuos3 Wacom buttons cause mouse to move to upper left corner and
+ click.
Bryce Harrington (bryce) wrote :

I put the two patches I mentioned earlier into a PPA here:
   https://launchpad.net/~bryce/+archive/honeydew

The patches switch the driver from using absolute mode on pad devices, to using relative mode.

However I see the upstream tree has changed further, and gone back to using absolute mode when it's a core device. See commit ce98b0a20862291892fc7a3110e4779cd69dd5ba. Commits aff73f14eff3fc314412fb4c4d020c185df92801 and 83714d87560e70c3fbf3aeb19bf28aae10da79c0 also look relevant. Because of this, I don't feel comfortable with proposing these two patches for Stable Release Updates. I fear it may result in regressions in other usage patterns and/or other device types.

Instead, I suspect in this case what's really needed is a driver update. There wasn't a newer -wacom available in x-updates so I've done the backport and uploaded it to the x-updates PPA:

https://launchpad.net/~ubuntu-x-swat/+archive/x-updates/?field.series_filter=lucid

On the plus side, this driver update brings some further fixes and improvements to lucid. Please install and test if it resolves the issue. If it does, I would propose we call this the "official" fix for the issue, since it looks to me like extracting and backporting all the various patches would be too time consuming and risky.

I installed 1:0.10.8-0ubuntu1~xup2~lucid from the ubuntu-x-swat PPA and can confirm that the driver update fixes the problem on my Intuos4 tablet.

WRT the problem on natty: xf86-input-wacom-0.10.11 uses the PAD device in absolute mode (again). #774938 (in particular its patch 503_fix_masked_transformed_valuators.patch) likely introduced a bug which prevents using the PAD device in absolute mode.

I installed 1:0.10.8-0ubuntu1 from the ubuntu-x-swat PPA and can confirm that the driver update fixes the problem on my Intuos4 tablet.

WRT the problem on natty: xf86-input-wacom-0.10.11 uses the PAD device in absolute mode (again). #774938 (in particular its patch 503_fix_masked_transformed_valuators.patch) likely introduced a bug which prevents using the PAD device in absolute mode.

Sorry for the dobule posting, but launchpad gives me a cryptic error message when I click the "Post Comment" Button, giving the impression my post was not accepted.

Bryce Harrington (bryce) wrote :

Alright, good to hear that fixes it. Given the complexities in doing a proper backport that I mentioned above, let's consider the update driver to be the official fix for this.

Changed in xf86-input-wacom (Ubuntu Lucid):
status: Triaged → Fix Released
Changed in xf86-input-wacom (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers