Created attachment 153286 [details] Picture of Graph with mislabeled y range SUMMARY I added a GPU Memory usage graph, I wanted to set the max y range to my max available. I used the drop down to select GiB, and the entered value got applied as KiB STEPS TO REPRODUCE 1. Add Monitor 2. Change to "Line Chart" 3. Add only "GPU Video Memory Used" 4. Uncheck "Automatic Y Data Range" 5. Change Data Units. OBSERVED RESULT Chart Y Range gets set 2 options lower EXPECTED RESULT Chart Y Range set to selected units Operating System: Fedora Linux 36 KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.99.0 Qt Version: 5.15.6 Kernel Version: 5.19.16-200.fc36.x86_64 (64-bit) Graphics Platform: X11 Processors: 12 × AMD Ryzen 5 5600X 6-Core Processor Memory: 15.5 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 2070 SUPER/PCIe/SSE2 Manufacturer: Gigabyte Technology Co., Ltd. Product Name: B450 AORUS PRO WIFI ADDITIONAL INFORMATION Adding Physical System Memory fixes the issue, so this is GPU specific (and I suppose possibly NVIDIA specific) This also limits the selector to MiB - PiB, when it should allow you to select B. (selecting MiB goes to B so it is effectively B-GiB). I originally missed the fact that auto y range sets it to the total available, so I just kept that checked so I am no longer effected by this bug.
Thank you for the bug report! Please note that Plasma 5.25.5 is not supported for much longer by KDE; supported versions are 5.24, and 5.26 or newer. If at all possible please upgrade to a supported version and verify that the bug is still happening there. If you're unsure how to do this, contact your distributor about it.
I managed to reproduce this with a different sensor that has a similar offset starting unit ("Average Frequency" in Total CPU). Looks like there's something wrong when the initial unit isn't the base unit.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/libksysguard/-/merge_requests/249
Git commit b25f548b483107c3797571692b8fa9315840f6fe by Arjen Hiemstra. Committed on 16/01/2023 at 13:14. Pushed by ahiemstra into branch 'master'. sensors: Account for base unit rather than starting unit in SensorUnitModel Otherwise we end up with incorrect multipliers if start isn't the base unit, since scaleDownFactor will calculate how to go down from something like "Mega" to prefix-less, resulting in tiny multipliers, instead of always starting at 1 and calculating offsets from there. M +3 -1 sensors/SensorUnitModel.cpp https://invent.kde.org/plasma/libksysguard/commit/b25f548b483107c3797571692b8fa9315840f6fe
Thanks for getting this fixed Arjen Hiemstra. I'm sorry for not being able to get to updating my version for reproduction or verification. The merge does seem like it should work. I feel comfortable closing this if it resolves the issue you were able to reproduce.