Summary: | Libinput 1.2 wheel scroll issue in all Qt5 apps on X11 | ||
---|---|---|---|
Product: | Wayland | Reporter: | Anthony <bvbfan> |
Component: | libinput | Assignee: | 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
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.