[MU4 Issue] Ctrl+Scroll is too aggressive on X11 with both mousewheel and touchpad

[crispyricepc]

Zooming in and out using the scroll wheel causes it to step 1000s of % at a time

To Reproduce

1. Open a score in any page view mode
2. Press Ctrl+Scroll in or out using either touchpad or scroll wheel
3. Observe the percentage change

Expected behavior
The view should zoom to the next level; i.e. from 100% to 125%

Video Attached

Platform information

• OS: Linux
• Desktop Environment: GNOME 42 (X11)
  • Also confirmed to be present on multiple machines using X11 with various versions of GNOME

[llui85]

That's odd. I can't reproduce this on my end:

MU4_ScoreScrollAllGood.mov

Linux 5.10.0-12-amd64 #1 SMP Debian 5.10.103-1 (2022-03-07) x86_64 GNU/Linux, GNOME 3.38.5, Wayland

[s1m0n-github]

I can't reproduce this issue as well (Edit: on Wayland):

Bildschirmaufzeichnung_vom_19.04.2022__10.54.31.mp4

Linux 5.17.2-1-default #1 SMP x86_64 GNU/Linux, GNOME 42, Wayland, openSUSE Tumbleweed

Seems to be an X.org error, happens to me when I am logged in with X11:

Bildschirmaufzeichnung_vom_19.04.2022__11.07.08.mp4

[crispyricepc]

I couldn't test with anything other than mouse + X11 on my NVIDIA desktop due to Wayland issues with the GPU drivers, but I just got my new laptop out which can run more extensive tests.

I can reproduce what @s1m0n-github is experiencing with my wayland laptop. Native wayland seems to be broken for now (I opened issue #11244), so I tested with XOrg, XWayland with both touchpad and mouse. In general, XOrg is too aggressive with both the touchpad and mouse

First test: Touchpad zoom followed by mousewheel zoom on XWayland (GNOME 41 wayland compositor)

Edit: There was a video here, but my capture software on wayland seems to not work. The video just described the expected behaviour of both the mouse and touchpad

Second test: Touchpad zoom followed by mousewheel zoom on XOrg (GNOME 41 Mutter)

XOrg_Touchpad_and_Mouse.mp4

The second video is clearly showing much larger steps between Ctrl+Mousewheel and Ctrl+Two-finger touch

I don't think this warrants an urgent fix, since I would guess most linux users have migrated to wayland compositors, but it's massively annoying for anyone stuck on X11 due to their window manager of choice or graphics drivers not supporting wayland yet.

[iwoithe]

I have the zooming issue on X11 as well (XFCE 4.16). A work around for this issue is go to Preferences -> Canvas and change Mouse zoom precision to 16 (which is the highest possible value). Zooming is still not as fine as I'd like, but it's much more workable.

[Gobbel2000]

There is a fix for this issue at #10346. I haven't actually tested that with a touchpad but it most likely makes that work as expected too.

[Tantacrul]

Curious to know whether this is an issue still. I see an old PR which hasn't yet been merged (although I've no idea whether it is mergable)

[oktophonie]

Can confirm I experience this still, for one (single step of Ctrl+mousewheel goes straight from 100% to 1600%)

[MaddyGuthridge]

Just checked on the latest nightly build, and it's still very much happening for me

[Jojo-Schmitz]

A fix for that is in #10346

Edit: sorry, that had been mentioned already

[bmarwell]

Curious to know whether this is an issue still. I see an old PR which hasn't yet been merged (although I've no idea whether it is mergable)

Hi Martin (@Tantacrul) – yes, this horrible UX bug is still a thing in the latest nightly.

The reason is well explained on the forums on musescore.org. The update of some xinput lib will change mouse sensitivity behaviour. Workaround is to downgrade a lib. sudo downgrade xf86-input-libinput on Arch Linux or Manjaro will do the trick. All other dists will follow the moment they update xf86-input-libinput v1.2.0 (or so).

I will cite @Gobbel2000 from that thread:

I am getting the same issue on Arch Linux and have found out the culprit is the package xf86-input-libinput. On 2021-09-19 it was updated from 1.1.0 to 1.2.0 which sparks the problem. This is also why only rolling release distros are affected as of now, most distros won't have this update for a while.

So, that said, Ubuntu Jammy ships xserver-xorg-input-libinput v1.2.1. I'd expect more users affected by now.

Downgrading is a horrible, but doable fix on Arch/Manjaro. But it is close to impossible with Ubuntu and Debian as Package dependencies would not allow installation of older versions.

I will try to test the fix with MuseScore 4 master and report the results here.

[bmarwell]

bmarwell@wells ~/git/musescore4 (master) $ curl --silent --fail --show-error --location "https://patch-diff.githubusercontent.com/raw/musescore/MuseScore/pull/10346.diff" --output - | git apply -v  --index
Checking patch src/notation/view/notationviewinputcontroller.cpp...
Hunk #1 succeeded at 398 (offset 27 lines).
Applied patch src/notation/view/notationviewinputcontroller.cpp cleanly.


bmarwell@wells ~/git/musescore4 (master) $ mkdir bin && cd bin

bmarwell@wells ~/git/musescore4/bin (master) $ cmake ../

bmarwell@wells ~/git/musescore4/bin (master) $ make -j24

bmarwell@wells ~/git/musescore4/bin (master+?) $ ./src/main/mscore
QML debugging is enabled. Only use this in a safe environment.

Yup that worked. Patch applies nicely and the build will now zoom nicely as well. :-)

[RomanPudashkin]

This fix has been merged: #10346

Please check the problem again and reopen the issue if it is still present. Thank you!