Bug 94392

Summary: Libinput 1.2 wheel scroll issue in all Qt5 apps on X11
Product: Wayland Reporter: Anthony <bvbfan>
Component: libinputAssignee: Wayland bug list <wayland-bugs>
Status: RESOLVED NOTOURBUG QA Contact:
Severity: major    
Priority: medium CC: peter.hutterer
Version: 1.2.x   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments: evemu-record
Still have opposite scroll

Description Anthony 2016-03-04 07:59:12 UTC
[toni@toni-sony ~]$ libinput-list-devices --version
1.2.1

[toni@toni-sony ~]$ xinput list-props 14
Device 'SINO WEALTH USB Composite Device':
        Device Enabled (140):   1
        Coordinate Transformation Matrix (142): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
        Device Product ID (260):        1539, 2
        Device Node (261):      "/dev/input/event1"

[toni@toni-sony ~]$ sudo libinput-debug-events 
Парола: 
event6  DEVICE_ADDED     Power Button                      seat0 default group1 cap:k
event7  DEVICE_ADDED     Video Bus                         seat0 default group2 cap:k
event8  DEVICE_ADDED     Video Bus                         seat0 default group2 cap:k
event9  DEVICE_ADDED     Sony Vaio Keys                    seat0 default group3 cap:k
event10 DEVICE_ADDED     Sony Vaio Jogdial                 seat0 default group4 cap:kp scroll-nat
event3  DEVICE_ADDED     Power Button                      seat0 default group5 cap:k
event5  DEVICE_ADDED     Sleep Button                      seat0 default group6 cap:k
event1  DEVICE_ADDED     SINO WEALTH USB Composite Device  seat0 default group7 cap:k
event2  DEVICE_ADDED     SINO WEALTH USB Composite Device  seat0 default group7 cap:kp left scroll-nat scroll-button
event17 DEVICE_ADDED     Sony Visual Communication Camer   seat0 default group8 cap:k
event0  DEVICE_ADDED     AT Translated Set 2 keyboard      seat0 default group9 cap:k
event12 DEVICE_ADDED     SynPS/2 Synaptics TouchPad        seat0 default group10 cap:p    size 57.17/25.32mm tap(dl off) left scroll-nat scroll-2fg-edge dwt-on
event2  POINTER_MOTION    +0.78s          1.33/ -1.66
event2  POINTER_AXIS      +4.82s        vert -15.00* horiz 0.00
event2  POINTER_AXIS      +4.86s        vert 15.00* horiz 0.00
event2  POINTER_AXIS      +5.13s        vert 15.00* horiz 0.00
event2  POINTER_AXIS      +5.17s        vert 15.00* horiz 0.00
event2  POINTER_AXIS      +5.18s        vert 15.00* horiz 0.00
event2  POINTER_AXIS      +5.22s        vert 15.00* horiz 0.00
event2  POINTER_AXIS      +5.25s        vert -15.00* horiz 0.00
event2  POINTER_AXIS      +6.30s        vert 15.00* horiz 0.00
event2  POINTER_AXIS      +6.37s        vert 15.00* horiz 0.00
event2  POINTER_AXIS      +6.42s        vert 15.00* horiz 0.00
event2  POINTER_AXIS      +6.46s        vert 15.00* horiz 0.00
event2  POINTER_AXIS      +6.48s        vert 15.00* horiz 0.00

^ Wheel scroll on one direction cause *sometimes* in opposite one causing unsuble desktop. This issue was introdused somewhere in 1.1 series, but was *rare* now in 1.2 it can't use wheel scroll.
Comment 1 Peter Hutterer 2016-03-07 06:13:53 UTC
Attach an evemu recording of your device scrolling please. I vaguely remember seeing this at some point and it was a hardware issue, those events actually came out of the device like this.
Comment 2 Anthony 2016-03-07 18:02:08 UTC
Created attachment 122148 [details]
evemu-record

I don't think its hardware issue since i have problems with 2 mice and with 1.2 (1.1.7 works good)
Comment 3 Peter Hutterer 2016-03-07 21:25:13 UTC
was this a recording that jumped up? if so, the hw events look correct. What's the output of libinput-debug-events while scrolling. note that this sits below the desktop environment, make sure you see the jump while you're recording so we look at the same sequence.
Comment 4 Anthony 2016-03-08 05:15:04 UTC
See abouve,it has wheel on opposite side like a *noise* now i'm on 1.1.7. 1.2 is totally unusable.
Comment 5 Anthony 2016-03-08 05:21:53 UTC
Especially yhis
event2  POINTER_AXIS      +5.22s        vert 15.00* horiz 0.00
event2  POINTER_AXIS      +5.25s        vert -15.00* horiz 0.00
looks like a *jitter*
Comment 6 Peter Hutterer 2016-03-08 05:33:08 UTC
oh right, not sure how I missed this. Please re-record with evemu-record and make sure that you capture at least one scroll jump backwards. The first recording doesn't have any in hardware so i want to make sure that I have a recording that produces the jump.

Best way to try: after the recording, replay it with sudo evemu-play /dev/input/eventX < evemu-file. Substitute your event node (event2 in the above) and make sure you still see the jump when replaying the recording. If so, attach the file here. Thanks
Comment 7 Anthony 2016-03-11 05:48:38 UTC
Created attachment 122215 [details]
Still have opposite scroll

[toni@toni-sony ~]$ sudo evemu-record /dev/input/event2 > res.txt
[toni@toni-sony ~]$ sudo evemu-play /dev/input/event2 < res.txt
Comment 8 Peter Hutterer 2016-03-31 05:44:55 UTC
sorry for the delay, I was on holidays.

I've replayed the recording and afaict the libinput output corresponds to the input, and scroll behaviour appears correct (gnome mouse test area and firefox). I've replayed the recording on current master and 1.1.7 and diff'd the output and they're identical (short of timestamps and some subpixel data in motion events). So I'm still stuck, I cannot reproduce this and I can't quite see why this would even be triggered in libinput.

If you can bisect this to the commit that broke it that would be much appreciated.
Comment 9 Peter Hutterer 2016-03-31 05:47:10 UTC
also, do you only see this in qt apps?
Comment 10 Anthony 2016-03-31 06:25:41 UTC
I use only Qt5 apps and that's why in bug report stays at it's name. Please test this on Qt 5.5.1 and 5.6. With 5.6 this cannot be reproduce *easy* but about me this is a libinput / evedev bug. How i wrote above. 
event2  POINTER_AXIS      +4.82s        vert -15.00* horiz 0.00
event2  POINTER_AXIS      +4.86s        vert 15.00* horiz 0.00
event2  POINTER_AXIS      +5.22s        vert 15.00* horiz 0.00
event2  POINTER_AXIS      +5.25s        vert -15.00* horiz 0.00
this is absolutely not a normal behavior.
Comment 11 Peter Hutterer 2016-03-31 07:14:23 UTC
Please test with non-Qt apps as well so we can figure out if it's a Qt issue.

I can see those events in the output, but they all have the matching hardware event. e.g. in the evemu recording you posted at E: 30.919708 there are two direction changes, but they come from the hardware. comparing with the libinput output, this matches.

all that aside: we dont do anything with wheel events in libinput other than apply natural scrolling, it's one of the simplest code paths we have.
Comment 12 Peter Hutterer 2016-04-05 22:19:45 UTC
fwiw, I just spent about 10 min scrolling in kwrite and konsole and didn't see any odd scroll events. that's with libinput master but the scroll code hasn't seen any changes for a while.
Comment 13 Anthony 2016-04-08 05:08:05 UTC
Ok let be fixed, i'm not noticing it with Qt 5.6. I will reopen if needed.
Comment 14 Peter Hutterer 2016-04-08 05:11:05 UTC
ok,thanks. I'm moving this to notourbug while the suspicion is still on Qt.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.