SUMMARY Kscreen is not showing all video modes, resulting in not showing the default mode. When your monitor have 60hz and 59.94hz, the values get rounded to 60 and the dropdown you can't choose 60hz instead you have a 60hz label but enables the non default 59.94hz Workaround: when you delete the folder .local/share/kscreen the monitors gets the default video mode. STEPS TO REPRODUCE 1. buy an screen with 60hz and 59.94hz 2. change video mode to 30hz with kscreen 3. change again to 60hz 4. see xrandr output. OBSERVED RESULT 59.94hz (non default videomode) is choosen EXPECTED RESULT 60hz is choosen SOFTWARE/OS VERSIONS KDE Plasma Version: 5.18.5 Xrand output: HDMI-A-0 connected 1920x1080+1920+0 (normal left inverted right x axis y axis) 640mm x 360mm 1920x1080 60.00 + 50.00 59.94* 30.00 25.00 24.00 29.97 23.98 1680x1050 60.00 1280x1024 60.02 1440x900 60.00 1360x768 59.80 1280x800 60.00 1280x720 60.00 50.00 59.94 1024x768 60.00 800x600 60.32 720x576 50.00 720x480 60.00 59.94 640x480 60.00 59.94
Posible implementation: when iterating for all refresh rates... if they are rounded to the same number on the dropdown... if the refresh rate is a default videomode dont deduplicate or discard the others refresh rates with the same number. Another implementation: use 2 decimal points on the drop down.
I think this is related to https://bugs.kde.org/show_bug.cgi?id=423576 but is not the same bug.
What does `kscreen-doctor -o` returns ?
And the content of .local/share/kscreen when the bug occurs ?
Just a side note unrelated to a bug: 59.94 _is_ a proper mode computed with CVT Reduced Blanking algorithm. It reduces pixel clock requirement and resulting in slightly better power saving. You should prefer 59.94 to 60 wherever possible.
Thank you for the bug report. Unfortunately we were not able to get to it yet. Can we ask you to please check if this is still an issue with Plasma 5.25 or 5.26? If it is, please change the status to CONFIRMED when replying. If not, or if you can't because you no longer use this setup, you can change the status to RESOLVED WORKSFORME. Thanks a lot!
(In reply to Nate Graham from comment #6) > Thank you for the bug report. Unfortunately we were not able to get to it > yet. Can we ask you to please check if this is still an issue with Plasma > 5.25 or 5.26? > > If it is, please change the status to CONFIRMED when replying. If not, or if > you can't because you no longer use this setup, you can change the status to > RESOLVED WORKSFORME. Thanks a lot! This is still an issue as of KDE 5.25.4 on Fedora 35.
Thanks. Can you paste the output of `kscreen-doctor -o` after you've reproduced the issue?
(In reply to Nate Graham from comment #8) > Thanks. Can you paste the output of `kscreen-doctor -o` after you've > reproduced the issue? Unfortunately, no, I won't be able to use the PC this or next week. See my bug 431057, it contains more information. It's not exactly the same bug, but the root could be the same.
Similar, yeah, and possibly the same issue. Ironically Bug 431057 shows that we store the refresh rate as a floating point value, probably to support the case of a refresh rate of 59.94hz. But apparently it's not working, since you have this bug too, and storing the data that way also causes Bug 431057. What a mess!
Does this happen in Plasma 6? There were some changes regarding fixing kscreen mode and output device mode mapping
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.