Menu

#218 scroll gesture lag

closed-fixed
Mouse (8)
2018-06-13
2012-07-09
Ian Wood
No

When I make a scroll gesture on the touchpad (two fingers moving vertically or horizontally), no scroll events are generated until I move about a 1.5 centimetres, then 1.5cm worth of scroll events suddenly happen, typically scrolling a page or so. Once scroll events have begun, they are generated smoothly as I move my fingers around.

If such a delay is somehow necessary, it'd be much better if the "missed" events didn't appear all at once, but were simply forgotten. Of course best would be to generate scroll events as soon as two fingers move.

1 Attachments

Discussion

  • mcaceres

    mcaceres - 2014-09-16

    I am experiencing the same issue for CTH-480 even with the latest drivers. There is a lag whenever I make a gesture, and when scrolling/zooming finally starts it "remembers" the previous movement, resulting in a big initial change (e.g. jump a page when scrolling, zooming in x1.5 to x2, etc)

    After the initial jump, though, the gesture works smoothly. I have xsetwacom --version 0.26.0 with Kubuntu 14.04 (KDE 4.13.3). It seems this bug has been around for a while, though. Or am I missing a setting/patch?

     
  • Jason Gerecke

    Jason Gerecke - 2014-09-17
    • assigned_to: Jason Gerecke
    • Group: --> Production
     
  • Jason Gerecke

    Jason Gerecke - 2014-09-17

    If you have the ability to build and install the driver from source, please try using the attached patch. It should prevent the large jumps that you see when a gesture is first recognized.

     
  • mcaceres

    mcaceres - 2014-09-18

    (Link leads to a blank page).

    Thanks for the response! Here's what happened with the patch
    - Scrolling now has a minimal lag. It is hard to notice it now unless I look for it.
    - There is no longer a big jump! :) Thanks for that.
    - Zoom still has a lag (no jump tough). I tried playing around with the "Zoom Distance" parameter but still.
    - The express buttons still work, but whenever I use them touch becomes disabled. After that touch becomes re-enabled if I move the cursor with the pen and then use touch.

    Thanks again for the response!

     

    Last edit: mcaceres 2014-09-18
  • Jason Gerecke

    Jason Gerecke - 2014-09-18

    Good to hear :) Right now the driver waits until the fingers have moved a minimum distance before starting to generate scroll/zoom events. That distance controls the lag, but we don't have it exposed as a tunable option right now (the ZoomDistance and ScrollDistance are more about controlling sensitive the gestures are once you're using them).

    Could you try running the latest driver without the patch applied and see if the express button issue still exists? It sounds like it might be a bug in some code new to the 0.26 release.

     
  • mcaceres

    mcaceres - 2014-09-18

    You're right. That's odd. I thought it was working OK before...anyway. Without the patch the issue remains: Express keys disable touch until the pen moves the cursor.

     
  • Jason Gerecke

    Jason Gerecke - 2014-09-18

    I've opened bug #256 for the ExpressKey issue. Please try the patch I attached there and let me know if it fixes your problem.

     
  • Jason Gerecke

    Jason Gerecke - 2014-09-20
    • status: open --> pending
     
  • Jason Gerecke

    Jason Gerecke - 2014-09-25

    Fix due in xf86-input-wacom 0.27.0

     
  • Jason Gerecke

    Jason Gerecke - 2014-09-25
    • status: pending --> pending-fixed
     
  • Jason Gerecke

    Jason Gerecke - 2014-11-04
    • status: pending-fixed --> closed-fixed
     
  • Studio ponnuki

    Studio ponnuki - 2018-06-13

    This is still happening for me - is there a threshold setting now that is uncovered? I am usin 0.36.1-1 on arch linux. The lag happens on scroll and on zoom. I am using Wacom Intuos PT S Finger touch. It's exactly as described by mcaceres, early delay then it 'kicks in'.

     
  • Jason Gerecke

    Jason Gerecke - 2018-06-13

    Hi, would you be willing to open a new issue for this at https://github.com/linuxwacom/xf86-input-wacom/issues/? I can reproduce that the delay still exists (this issue was closed when the unexpected "jump" that also occurred was fixed), and it doesn't look like an option to control the amount of time it takes for scrolling to "kick in" was ever added.