I have a ThinkPad laptop, with a trackpoint and a trackpad. The trackpoint runs with the evdev driver and the trackpad runs with the synaptics driver. 
The (absolute) scroll valuators of the trackpad are reset to 0 as soon as the trackpoint is used; this causes large jumps in scrolling in (for instance) Qt5 apps, but it is indeed an xorg issue.

[commented] sample output of xinput test on the synaptics driver
$ xinput test 11 | grep "a\[3\]"
motion a[3]=1144 
motion a[3]=1153 
motion a[3]=1164 
motion a[3]=1172 
motion a[3]=1178 
motion a[3]=1181 
motion a[3]=1185 
motion a[3]=1186 // Here I move the trackpoint 
motion a[3]=4 // here the Qt app gets a delta of <-1000, so it jumps back
motion a[3]=7 
motion a[3]=9 
motion a[3]=10 
motion a[3]=14 
motion a[3]=17 
motion a[3]=18 
motion a[3]=22

That's a problem with the scroll valuators in the servers and how they react to a device change, similar to what I described here:
https://who-t.blogspot.com.au/2012/06/xi-21-protocol-design-issues.html

Created attachment 128975 [details]
attachment-31372-0.html

Just FYI it works correctly using the xf86-input-libinput driver for the trackpoint (synaptics for the trackpad)


On January 15, 2017 4:28:24 PM EST, bugzilla-daemon@freedesktop.org wrote:
>https://bugs.freedesktop.org/show_bug.cgi?id=99378
>
>Peter Hutterer <peter.hutterer@who-t.net> changed:
>
>           What    |Removed                     |Added
>----------------------------------------------------------------------------
>          Component|Lib/Xi                      |Server/Input/Core
>
>--- Comment #2 from Peter Hutterer <peter.hutterer@who-t.net> ---
>That's a problem with the scroll valuators in the servers and how they
>react to
>a device change, similar to what I described here:
>https://who-t.blogspot.com.au/2012/06/xi-21-protocol-design-issues.html
>
>-- 
>You are receiving this mail because:
>You reported the bug.

huh, true. verified it works with the libinput driver. That's good news, should make it easier to fix. has this always been around or is it recent breakage? if the latter, can you bisect to the broken commit please?

Created attachment 128983 [details]
attachment-27419-0.html

Sorry Peter, but I am confused; why are you assigning the bug to synaptics? I think the issue is with the evdev driver since synaptics works with Libinput 

I can't tell if it is a recent issue or it has been there forever. 
Anyway, what should I bisect? Evdev or synaptics? 

On January 16, 2017 12:50:52 AM EST, bugzilla-daemon@freedesktop.org wrote:
>https://bugs.freedesktop.org/show_bug.cgi?id=99378
>
>Peter Hutterer <peter.hutterer@who-t.net> changed:
>
>           What    |Removed                     |Added
>----------------------------------------------------------------------------
>         Assignee|xorg-team@lists.x.org       |peter.hutterer@who-t.net
>          Component|Server/Input/Core           |Input/synaptics
>         QA Contact|xorg-team@lists.x.org       |
>
>--- Comment #4 from Peter Hutterer <peter.hutterer@who-t.net> ---
>huh, true. verified it works with the libinput driver. That's good
>news, should
>make it easier to fix. has this always been around or is it recent
>breakage? if
>the latter, can you bisect to the broken commit please?
>
>-- 
>You are receiving this mail because:
>You reported the bug.

if you're replying by email, please cut out the context, it makes the bug quite confusing. 'synaptics' is xf86-input-synaptics and that's where it's visible (in the evdev+synaptics combo anyway). did you try libinput+synaptics and it worked?

Created attachment 128988 [details]
attachment-24637-0.html

Yes, precisely.

huh, weird. verified, but now I'm not so sure anymore what the cause could be.

I am seeing this bug as well. None of the devices on my system uses synaptics. Changing to libinput does fix the issue. So it seems that evdev is the source of the bug here.

I am wondering if there is some reliable way of checking if valuators are reset by driver (to mitigate the issues this causes for user experience)? Imagine, you are developing touch based application (you use the same touch screen for developing and testing the app). After testing your app (via touch), you go back to IDE, try to scroll and every time you get a frustrating scroll bar jump (for the first mouse scroll after touch interaction).

I see that chromium (https://bugs.chromium.org/p/chromium/issues/detail?id=609748) simply reverted back to using XInput 1. It is kind of strange to use XInput 1 in 2017.

evdev is in maintenance mode, so it's probably down to you or someone else with stakes in the game to fix it, sorry.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-input-synaptics/issues/4.