If I try to scoll tabs in kate I cannot do so one at a time, instead it jumps multiple at once. This has certainly to do with with high-res scrolling (REL_WHEEL_HI_RES), which was introduced with libinput 1.2.0, see link to libinput issue below. According to this bug/ libinput-maintainer it is up the application to fix this behavior. Hence this issue here. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.18.5-1-MANJARO arch: x86_64 bits: 64 KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.4 Mouse: Logitech MX Master 2 libinput: xf86-input-libinput 1.2.1 ADDITIONAL INFORMATION See also: https://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput/-/issues/39 https://forum.manjaro.org/t/logitech-mx-master-vertical-scroll-issue/100859 https://forums.opensuse.org/showthread.php/560616-High-resolution-scrolling-amp-tab-switching
Probably needs to be reported upstream Qt (most likely fixed in Qt6)
I think I will have some high precision mouse around in the near future, then I can try out, how it behaves here. With Qt 5 and 6.
Hmm, I have now some high precision scroll wheel, too, the MX 3. I have no issues scrolling in the tabs of the 22.04.x version with Qt 5.15.x here, but perhaps I need to try this more, just used it some minutes.
Is there any special thing to do to reproduce this? If I scroll "slow or normal", it seems to just behave as wanted, one tab at a time. Naturally, if I just "spin" the wheel and it enters the "fast" mode or however you will call it, it will very fast scroll through XX tabs, but that is intended, just like it would scroll through XX lines.
(In reply to Christoph Cullmann from comment #4) > Is there any special thing to do to reproduce this? > No, but it might be configuration thing. What libinput version are you using. Is the high res scrolling option activated? Output of evtest for one scroll tick on my setup: Event: time 1657140543.952137, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), value -15 Event: time 1657140543.952137, -------------- SYN_REPORT ------------ Event: time 1657140543.958151, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), value -15 Event: time 1657140543.958151, -------------- SYN_REPORT ------------ Event: time 1657140543.990245, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), value -15 Event: time 1657140543.990245, -------------- SYN_REPORT ------------ Event: time 1657140544.020147, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), value -15 Event: time 1657140544.020147, type 2 (EV_REL), code 8 (REL_WHEEL), value -1 Event: time 1657140544.020147, -------------- SYN_REPORT ------------ Event: time 1657140544.036178, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), value -15 Event: time 1657140544.036178, -------------- SYN_REPORT ------------ Event: time 1657140544.052157, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), value -15 Event: time 1657140544.052157, -------------- SYN_REPORT ------------ Event: time 1657140544.068143, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), value -15 Event: time 1657140544.068143, -------------- SYN_REPORT ------------ Event: time 1657140545.100103, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), value -15 Event: time 1657140545.100103, -------------- SYN_REPORT ------------ > If I scroll "slow or normal", it seems to just behave as wanted, one tab at > a time. This is not the case here in kde apps. But it works like this in chromium.
I use NixOS with libinput 1.21.0 Need to try out what evtest does say here.
I get this for one scroll Event: time 1657212830.065464, -------------- SYN_REPORT ------------ Event: time 1657212831.617502, type 2 (EV_REL), code 8 (REL_WHEEL), value -1 Event: time 1657212831.617502, type 2 (EV_REL), code 11 (REL_WHEEL_HI_RES), value -120
Hmm, if I patch master, are you able to compile some master build of Kate to test? A howto is e.g. on https://kate-editor.org/build-it/ I see we have implemented the wheel event on our own again, for me, using just the normal QTabBar implementation still changes docs like wanted.
Git commit 2cfe3a8e2e982010a7d97ec391e3a787fdc5bc58 by Christoph Cullmann. Committed on 07/07/2022 at 19:31. Pushed by cullmann into branch 'master'. avoid changing QTabBar scrolling use the normal Qt tab bar scrolling perhaps this fixes high precision scrolling in any case, if high precision scrolling is still not working after this change, this needs to be reported upstream to Qt M +0 -10 apps/lib/katetabbar.cpp M +0 -3 apps/lib/katetabbar.h https://invent.kde.org/utilities/kate/commit/2cfe3a8e2e982010a7d97ec391e3a787fdc5bc58
Btw., I looked in the Qt code, at least in 6.x they have there pixel precise scrolling handling. That was for sure missing in our code. Seems for me that really is not active, otherwise I would be able to reproduce this.
Ok, thanks for the investigation. I don't have any further ideas so far. I will try to build the patched version and see if it helps. Its kinda strange that there aren't more reports about this (might be a individual problem only on my side), but then again the bar for reporting bugs on bko is kinda high...