SUMMARY The volume OSD sometimes reports 100% volume instead of the correct volume (which is >100%, with the Raise Maximum Volume option). This seems to happen especially when other OSDs appear (verified with the media volume OSD). This also happens sporadically for me, but the below steps reliably reproduce the issue. STEPS TO REPRODUCE 0. Have media playing. 1. Raise the volume to e.g. 120% by e.g. scrolling over the volume icon. 2. Change the media volume by scrolling over the media player icon. (Might also reproduce with other OSDs like brightness, but did not verify.) 3. Lower the volume to 115% with either the keyboard shortcut or by scrolling. 4. Lower the volume again, to 110%. OBSERVED RESULT After step 3, the OSD wrongly indicates a volume of 100%. After step 4, the OSD correctly indicates 110%. EXPECTED RESULT After step 3 the OSD should report the actual volume of 115% instead. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.110.0 Qt Version: 5.15.10 ADDITIONAL INFORMATION Could be related to Bug 467123 or perhaps Bug 428425?
Can reproduce in Plasma 6 with those exact steps.
So I tried to do a little digging, and it's all very confusing. dbus-monitor shows that plasma-pa seems to be sending the correct value of e.g. 105 to org.kde.osdService (member=osdProgress). In the OSD part of plasma-workspace specifically Osd::showProgress, maximumPercent is used to both bound the value and set osdMaxValue which defines how wide the progress bar is. Strangely, the progress bar does have the correct width?! So it seems that osdMaxValue *is* set correctly, but the value is being incorrectly bound somewhere after being sent over dbus. Very confusing. My best guess is that something goes wrong within plasma-workspace/shell/osd.cpp/showProgress, but I have no certainty for this. Maybe something horrible related to QML?
Okay, after attaching Gammaray it seems like the osdValue property is also being set correctly. Perhaps in plasma-workspace we should update the maxValue first and only THEN the value? Perhaps Qt internally limits the progressbar value too, which is then done with the old incorrect limit of 100 which is 'remembered' from the previous OSD (such as media or brightness). Will try and open an MR if it works!
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3595
Git commit 741a0308605a7fd218b12961ec13c77f00777f86 by ivan tkachenko, on behalf of Quinten Kock. Committed on 01/12/2023 at 23:42. Pushed by ratijas into branch 'master'. Osd: set osdMaxValue before osdValue This change fixes incorrect bounded values appearing in the osd, for example 100% when the real volume is 105%. Probably, this happens because osdValue is set to 105 while osdMaxValue=100, which then gets clamped by Qt. By setting osdMaxValue first, Qt clamps with the correct range. M +2 -1 shell/osd.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/741a0308605a7fd218b12961ec13c77f00777f86
Git commit 424144f4f8ab594948d69bce3817037bc9e726c1 by ivan tkachenko. Committed on 02/12/2023 at 02:10. Pushed by ratijas into branch 'master'. Osd: set osdMaxValue before osdValue This change fixes incorrect bounded values appearing in the osd, for example 100% when the real volume is 105%. Probably, this happens because osdValue is set to 105 while osdMaxValue=100, which then gets clamped by Qt. By setting osdMaxValue first, Qt clamps with the correct range. See plasma-workspace@741a0308605a7fd218b12961ec13c77f00777f86 M +2 -1 greeter/greeterapp.cpp https://invent.kde.org/plasma/kscreenlocker/-/commit/424144f4f8ab594948d69bce3817037bc9e726c1