[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.
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.
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)
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.
See abouve,it has wheel on opposite side like a *noise* now i'm on 1.1.7. 1.2 is totally unusable.
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*
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
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
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.
also, do you only see this in qt apps?
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.
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.
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.
Ok let be fixed, i'm not noticing it with Qt 5.6. I will reopen if needed.
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.