Menu

#240 bad cursors arrow behaviour on version 0.18 and later

closed-rejected
nobody
None
2015-12-04
2014-04-24
charlie6
No

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

1 Attachments

Related

Bugs: #229
Bugs: #240

Discussion

  • Jason Gerecke

    Jason Gerecke - 2014-04-25

    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 run git 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 :)

     
  • charlie6

    charlie6 - 2014-04-25

    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

    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 run git 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 :)


    [bugs:#240] bad cursors arrow behaviour on version 0.18 and later

    Status: open
    Group: Production
    Created: Thu Apr 24, 2014 08:22 AM UTC by charlie6
    Last Updated: Thu Apr 24, 2014 08:22 AM UTC
    Owner: nobody

    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


    Sent from sourceforge.net because you indicated interest in
    https://sourceforge.net/p/linuxwacom/bugs/240/

    To unsubscribe from further messages, please visit
    https://sourceforge.net/auth/subscriptions/

     

    Related

    Bugs: #240
    Commit: [599412]

  • charlie6

    charlie6 - 2014-05-04

    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

    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 run git 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 :)


    [bugs:#240] bad cursors arrow behaviour on version 0.18 and later

    Status: open
    Group: Production
    Created: Thu Apr 24, 2014 08:22 AM UTC by charlie6
    Last Updated: Thu Apr 24, 2014 08:22 AM UTC
    Owner: nobody

    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


    Sent from sourceforge.net because you indicated interest in
    https://sourceforge.net/p/linuxwacom/bugs/240/

    To unsubscribe from further messages, please visit
    https://sourceforge.net/auth/subscriptions/

     

    Related

    Bugs: #240
    Commit: [599412]

  • Jason Gerecke

    Jason Gerecke - 2014-05-08

    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.

     
  • Jason Gerecke

    Jason Gerecke - 2014-12-13
    • status: open --> closed-rejected
     
  • Jason Gerecke

    Jason Gerecke - 2014-12-13

    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/psaux which 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.conf then the problem is prevented.