ctrl + scrollwheel zooms in and out by a factor of 1600% every scroll wheel tick
OS: Arch Linux w/ KDE Plasma
Reproducible with both the musescore package in the arch official repository and also the appimage.
EDIT: found the Mouse zoom precision setting, setting it to 16 (the highest it'll go, the default is 6) results in a 283%
zoom instead of a 1600% zoom, more usable but still not ideal. This is still a bug yeah? Attempting to make th e setting go above 16 by editing MuseScore3.ini did not work (nice job on not allowing settings to be busted like that)
For whatever reason, (and this bug started in the last couple days). Whenever zooming with ctrl+scrollwheel zooms in or out by a factor of 1600%, rendering the (quite useful) feature useless. Ctrl+scrollwheel up zooms in to 1600% then to 25600%, and zooming out takes me to 6%. I'm not even sure if there was an update since when this broke so I'm thoroughly confused as to what could have happened. This bug report is thus a stab in the dark to see if anyone else is experiencing this. No other programs exhibit this behaviour. Here's an except from the logs:
unknown:unknown: ZoomBox::setLogicalZoom(): Formatting logical zoom level as 1600% (rounded from 16.000000)
unknown:unknown: ZoomBox::setLogicalZoom(): Formatting logical zoom level as 100% (rounded from 1.000000)
unknown:unknown: ZoomBox::setLogicalZoom(): Formatting logical zoom level as 6% (rounded from 0.062500)
unknown:unknown: ZoomBox::setLogicalZoom(): Formatting logical zoom level as 100% (rounded from 1.000000)
unknown:unknown: ZoomBox::setLogicalZoom(): Formatting logical zoom level as 1600% (rounded from 16.000000)
unknown:unknown: ZoomBox::setLogicalZoom(): Formatting logical zoom level as 25600% (rounded from 256.000000)
unknown:unknown: ZoomBox::setLogicalZoom(): Formatting logical zoom level as 40000% (rounded from 400.000000)
unknown:unknown: ZoomBox::setLogicalZoom(): Formatting logical zoom level as 2500% (rounded from 25.000000)
unknown:unknown: ZoomBox::setLogicalZoom(): Formatting logical zoom level as 156% (rounded from 1.562500)
unknown:unknown: ZoomBox::setLogicalZoom(): Formatting logical zoom level as 10% (rounded from 0.097656)
unknown:unknown: ZoomBox::setLogicalZoom(): Formatting logical zoom level as 156% (rounded from 1.562500)
Comments
FWIW, it works normally for me on Debian, and I haven't heard of other reports of this on Arch. Since it appears you are saying this only started recently, it seems likely to be connected to some specific setting on your particular system, as opposed to general MuseScore issue. but if anyone can find steps to reliably reproduce this on other systems, please let us know!
For the record, on my system, the factor is around 12%, and in fact is likely the sixth root of two more precisely, because it takes six "clicks" to reach 200% - and it does reach 200% exactly.
No issues for me. OS: Ubuntu 21.04, Arch.: x86_64, MuseScore version (64-bit): 3.6.2.548021370, revision: 3224f34 running KDE Plasma 5 desktop.
Like Marc, 6 clicks goes from 100% to 200%; 6 more clicks to 400% etc. so 24 clicks from 100% to 1600%. (and going the other way, 6 clicks from 100% to 50%, 6 more to 25% etc.).
In reply to FWIW, it works normally for… by Marc Sabatella
I was pretty sure this would be the response but it's just such a baffling issue, that it only affects MuseScore and in this one very, very specific way. I'll do some more sleuthing and see what I can see.
In reply to I was pretty sure this would… by Minerscale
What is Edit >Preferences >Canvas > Zoom >Mouse zoom precision set to? Default value is 6 (hence the 6 clicks). A lower value would result in larger zoom jumps (although at a value of 1 it would still takes 4 clicks from 100% to 1600%).
In reply to What is Edit >Preferences … by underquark
As mentioned in the original post, I set the value to 16, from 6, and whilst the issue got better, it still wasn't what you'd call 'usable'. Problem's still there by the way. Don't know where it came from, don't know when it's going, don't know where it came from, cotton eye joe. My headcanon is that a cosmic ray went and flipped a bit in one of my config flies, which one I have no idea.
Regardless of what's causing the problem, is there a way to increase the mouse zoom precision beyond 16?
The same thing is happening on my machine: Manjaro 21.1.4; Xfce 4.16; Musescore 3.6.2-2. At precision 16 the factor here is 2.83x, at precision 6 it's 16x. Problem won't be due to changes to Musescore because I last updated it Sep. 13, and the problem only started after a system update today.
I tried a few programs, and none of them have the same issue. So far I tried:
* Gimp 2.10.28
* LibreOffice 7.1.6.2.0+
* Okular 21.08.1
* TeXstudio 3.1.2
* Viewnior 1.7
Sep. 30 update: found a similar issue on Inkscape 1.1.1 (3bf5ae0d25, 2021-09-20). The zoom factor is actually twice the one set in the preferences there. I originally thought it may have been a problem with Qt, but in this case it might be some other reason.
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.This update added some functionality for hi-res scrolling which apparently caused problems on multiple ends (for example https://gitlab.freedesktop.org/libinput/libinput/-/issues/681 ). QT also has some problems with it as mentioned here:
https://gitlab.freedesktop.org/xorg/driver/xf86-input-libinput/-/issues…
It seems clear to me that this is not a bug in musescore. I'm hoping for a change in libinput or QT, until then the easiest workaround would probably be downgrading xf86-input-libinput to 1.1.0.
OK, thanks for this information!
Let's close this issue here as not being a MuseScore one
In reply to I am getting the same issue… by Gobbel2000
Thanks so much for finding the culprit! That fix works great. Now I just have to remember to upgrade xf86-input-libinput when the fix comes out hahaha.
Here's a workaround without downgrading:
https://www.reddit.com/r/archlinux/comments/puiysn/comment/hey8d12/?utm…
HTH :)
In reply to Here's a workaround without… by bmhm
This didn't work for me unfortunately. I'm using a Logitech MX Ergo. libinput reports that the quirks are active but the scrolling in Musescore is still not working correctly.
In reply to This didn't work for me… by reddiesel41264
Any other solutions for this problem?
Are you saying downgrading the library didn’t fix it for you?
In reply to Are you saying downgrading… by Marc Sabatella
I'm saying the reddit solution (without downgrading) didn't solve it. I'm not sure how to downgrade on Debian...
See above:
It seems clear to me that this is not a bug in musescore. I'm hoping for a change in libinput or QT, until then the easiest workaround would probably be downgrading xf86-input-libinput to 1.1.0.
In reply to See above: It seems clear to… by Jojo-Schmitz
Seen it. Don't know how to downgrade, tried the non-downgrade solution but no luck. Any idea how to downgrade on Debian?
If you didn't downgrade to that, you haven't tested the workaround. How to downgrade is nothing the MuseScore forum can tell you. Ask in a Debian forum.
In reply to If you didn't downgrade to… by Jojo-Schmitz
Nothing to see here...
the problem occurs with every mouse in MuseScore only, no other application shows that behavior of the mega zoom, the behavior of ctrl and + is strange too, the zoom factor is normal, but it scrol everything to the right, till the score is not in sight anymore. probably its a libinput thing, but sooner or later every distro is getting 1.2 and yeah... maybe adopt to that upcoming problem instead of saying downgrading is the solution ? couse the behavior of something has changed obviously.... krita, blender, firefox, inkscape and so on have no problem with zooming. just musescore. Its better to take an serious eye on it now, then later when everyone goin to have that problem don`t you think ? :)
See the articles linked above. Apparently the issue happens with any programs built with the same version of Qt as MuseScore. The next version of MuseScore will be built with newer versions of Qt and presumably won’t have the issue (feel free to help us test a nightly build). But for now, with the current version, rolling back to an earlier version of the input library is the known solution.
In reply to See the articles linked… by Marc Sabatella
the nightly builds have the same issue :)
In reply to the nightly builds have the… by hello-guitar
inlcuding musescore 4
OK, thanks for letting us know. I've reopened this so it can be looked at to see if there are workarounds we should be trying to employ in our code while we wait for the libinput folks to fix the bug for real. Looks like their proposed fix has been merged into their code but who knows when it will start showing up in any particular Linux distributions.
In reply to OK, thanks for letting us… by Marc Sabatella
ok great :)
After some digging I found a way to resolve this problem within musescore, see
https://github.com/musescore/MuseScore/pull/10346
for more details.
In reply to After some digging I found a… by Gobbel2000
Excellent! Do we have to wait for Musescore 4 to get this fix?
Well, that PR is s for the 3.x branch, but there won't be a further 3.x release. So that change needs to get made for the master branch to have a chance being included in MuseScore 4
I wasn't aware that PRs to the 3.x branch aren't really useful at this point. But the the same change works for version 4, just in a slightly different place. I updated the above PR to now apply that to the master branch.
If someone still wants to have the change for version 3 to self-compile, it's still up here.
In reply to I wasn't aware that PRs to… by Gobbel2000
the compilation was a little bit of a pain in the **** but i got it to work :) you are my personal "Hero" thank you for the fix !!!
I'll add the 3.x version to my PR #9000
In reply to Weill, that PR is s for the… by Jojo-Schmitz
I'm still seeing nightly builds for 3.x are these just the same as 3.6?
No, the 3.x branch is 81 commits ahead of 3.6.2 (https://github.com/musescore/MuseScore/compare/3.6.2...3.x). But stagnant since 23 Sep 2021 (i.e. no new commit since then, actually no 'real' commit since 12 Aug 2021), just building the same thing time and time again, every night
@Jojo-Schmitz FYI: it still occures in the MuseScore 4 nightly.
In reply to @Jojo-Schmitz FYI: it still… by bmhm
Same here. With the libinput 1.20.1-1
That PR still hasn't been merged into master
Yes that is why I was writing here. Maybe we could get this merged sooner than later? It is "Severity 3 - Major" and most Linux users either don't know how to apply the workaround (downgrading a package) OR don't want to: It is ONLY musescore which is affected by this bug, and the workaround is to break support. I will leave it ticked, but add me to the long list of users who want to see it unticked…
Fixed in branch master, commit 2f783dd671
_Fix #324840: Ctrl+Scrollwheel zoom on Linux X11
With recent libinput versions zooming with Ctrl+Scrollwheel would zoom
in huge steps. This change enforces the previous behavior for Linux X11
only.
Scrolling is left unchanged for Wayland_
Fixed in branch master, commit 5788c24755
_Merge pull request #10346 from Gobbel2000/zoom_fix
Fix #324840: Ctrl+Scrollwheel zoom on Linux X11_
The fix will be in MuseScore 4 which is being developed.
Automatically closed -- issue fixed for 2 weeks with no activity.