#240 bad cursors arrow behaviour on version 0.18 and later
Hi,
subject: xf86-input-wacom -0.XX.0 drivers from version 0.18.0:
I have compiled those drivers each time a new version is issued, on different versions of PuppyLinux; i have kept compiling them since version 0.15.0 on puppy Wheezy-3.5.2 (linux kernel 3.5.2) which is a debian wheezy compatible distro;
Those distros have the wacom.ko kernel driver already buit-in.
Up to version 0.17.0, things were going well.
Since 0.18.0 and later, the cursors arrow has the following behaviour:
whatever the /etc/X11/xorg.conf setting for the stylus (and cursor) device "relative" or "absolute" mode", the cursors arrow runs away to the above left screens corner quite every time the stylus (or cursor) is lifted far away off the tablets pad. I believe the cursor should stay were it has been left before lifting the stylus, especially in "relative" mode (as it does on version up to 0.17.0).
This occurs on Bamboo MTE-450, and Volito1 and Graphire1 as well wacom tablets.
Thanks considering this.
Best Regards
Charlie
Since you're familiar with compiling and installing the driver, would you be willing to run 'git bisect' to find the bad commit? The following commands should get you started:
$ git clone git://git.code.sf.net/p/linuxwacom/xf86-input-wacom
$ cd xf86-input-wacom
$ git bisect start
$ git bisect bad xf86-input-wacom-0.18.0
$ git bisect good xf86-input-wacom-0.17.0
At this point, git will jump to a commit between 0.17.0 and 0.18.0. Compile, install, and test out the driver. If you see the cursor jump, you can tell git that the build is still buggy by running
git bisect bad; otherwise rungit bisect good. After running the command, git will once again jump to another commit where you can repeat the process.After about 5 compile/install/test cycles, git should have found the commit that causes the problem. If you can let us know which commit was responsible, we can take a closer look and figure out what the bug is :)
Hi Jason,
good news !!
many thanks for your reply and for that "how to" !
that's the first time i'm doing this :-)
All went good !
as also got the cursor to behave "as good" at step 3 (third compile
install process).
In attachment are:
-the command line message after running "git bisect good".
-the targz'ed wacom_drv.so compiled on wheezy-kernel3.5.2 ...if usefull
It tells:
git bisect good
Bisecting: 1 revision left to test after this (roughly 1 step)
[59941213fb8972abc1cd3bf3762444ab73ae1329] Device grab should be optional
Glad to have helped (perhaps)!
Charlie
--
BARÉ Willy sprL
rue du Gonoy, 114
B-5640 Maison-Saint-Gérard
(Belgium)
mobile: +32 0474 780051
fax: +32 071 798711
Related
Bugs:
#240Commit: [599412]
I resent this message as i suspect it not have been sent the right way.
Charlie
Hi Jason,
in addition to my posts, i also observed that the stylus "right-click"
(i.e. stylus button the fartest from the tip) now works as expected.
This had already been reported in bug #229.
So the "bisect good" might also fix bug #229.
Cheers,
Charlie
---------------------------- Message original ----------------------------
Objet: Re: [linuxwacom:bugs] #240 bad cursors arrow behaviour on version
0.18 and later
De: barewillysprl@euphonynet.be
Date: Ven 25 avril 2014 10:38
À: "[linuxwacom:bugs]" 240@bugs.linuxwacom.p.re.sf.net
--------------------------------------------------------------------------
Hi Jason,
good news !!
many thanks for your reply and for that "how to" !
that's the first time i'm doing this :-)
All went good !
as also got the cursor to behave "as good" at step 3 (third compile
install process).
In attachment are:
-the command line message after running "git bisect good".
-the targz'ed wacom_drv.so compiled on wheezy-kernel3.5.2 ...if usefull
It tells:
git bisect good
Bisecting: 1 revision left to test after this (roughly 1 step)
[59941213fb8972abc1cd3bf3762444ab73ae1329] Device grab should be optional
Glad to have helped (perhaps)!
Charlie
Related
Bugs:
#240Commit: [599412]
I can confirm the existence of this issue on Puppy Wheezy with other tablets I have around (e.g. Intuos5, Graphire4). Oddly, however, I cannot reproduce the bug with any other distro that I've tried, including the raw Debian Wheezy (which shares nearly-identical driver, X, and kernel versions as the Puppy Linux variety).
Unfortunately, I am having difficulty getting a development environment created in Puppy to try to see what may be causing the bug. I must confess that its package management is a bit of a mystery to me.
Also, just as a note to my future self, this also seems awfully like bug #229.
I've finally figured out how to install the necessary development tools and have been able to replicate the issue. After poking at it a little bit, I'm confident that this is not a driver issue.
As mentioned above, commit 5994121 is the trigger. This commit removes the grab on the input device, allowing it to be read by other processes. In particular, it seems that removing the grab is allowing the pointer events to be sent out through
/dev/psauxwhich X handles through the generic "mouse" driver (and which is responsible for the jump to (0,0)). Other distributions do not suffer from similar bugs because they're set up to use hotplugged evdev devices and provide all the necessary xorg.conf.d files to ensure any tablets are routed to only our driver.The simplest workaround for Puppy Linux is simply to re-enable the device grab. If you add
Option "GrabDevice" "1"to each wacom InputDevice in/etc/X11/xorg.confthen the problem is prevented.