I have a dual-monitor setup with two 2560x1440p screens at 100% scaling on Wayland. After upgrading to plasma 6.1, sometimes after waking the computer from sleep the placement of the monitors are swapped and sometimes one of the monitors get rescaled to 125%. STEPS TO REPRODUCE 1. Put the computer to sleep or wait for it to sleep. 2. Wake it up and observe that sometimes the login screen on one of the monitors is scaled up. 3. Login and open Display & Monitor in system settings and observe that the position of the monitors have swapped and that one of the monitors is set to 125% scaling. OBSERVED RESULT After upgrading to plasma 6.1, sometimes after waking the computer from sleep the placement of the monitors are swapped, and sometimes one of the monitors get rescaled to 125%. EXPECTED RESULT The monitor configuration should be preserved when the computer wakes up. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kernel 6.9.7-arch1-1 (64-bit) (available in About System) KDE Plasma Version: 6.1.1 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.2 ADDITIONAL INFORMATION I'm running Wayland and have an AMD RX 570 graphics card. I also have adaptive sync set to "Automatic" in the display settings.
Oh yeah and I have the monitors set to 75Hz.
An update. Now sometimes when I first log in after rebooting my computer the same issue happens. Am I the only one experiencing this issue? I suppose it's not a major issue but it's still mildly annoying.
Please attach ~/.config/kwinoutputconfig.json and the output of drm_info when the setup is correct, and when it's wrong
(In reply to Zamundaaa from comment #3) > Please attach ~/.config/kwinoutputconfig.json and the output of drm_info > when the setup is correct, and when it's wrong Alright, here it is when it is correct: [ { "data": [ { "autoRotation": "InTabletMode", "brightness": 1, "colorProfileSource": "sRGB", "connectorName": "DP-2", "edidHash": "24958546af32afdbb93ed9c47f196d34", "edidIdentifier": "AUS 9984 16843009 47 2020 0", "highDynamicRange": false, "iccProfilePath": "", "mode": { "height": 1440, "refreshRate": 74924, "width": 2560 }, "overscan": 0, "rgbRange": "Automatic", "scale": 1, "sdrBrightness": 200, "sdrGamutWideness": 0, "transform": "Normal", "vrrPolicy": "Automatic", "wideColorGamut": false }, { "autoRotation": "InTabletMode", "brightness": 1, "colorProfileSource": "sRGB", "connectorName": "DP-3", "edidHash": "edfbd56e01bd44cea3b332ada36972e8", "edidIdentifier": "AUS 9984 16843009 47 2020 0", "highDynamicRange": false, "iccProfilePath": "", "mode": { "height": 1440, "refreshRate": 74924, "width": 2560 }, "overscan": 0, "rgbRange": "Automatic", "scale": 1, "sdrBrightness": 200, "sdrGamutWideness": 0, "transform": "Normal", "vrrPolicy": "Automatic", "wideColorGamut": false } ], "name": "outputs" }, { "data": [ { "lidClosed": false, "outputs": [ { "enabled": true, "outputIndex": 0, "position": { "x": 0, "y": 0 }, "priority": 0 } ] }, { "lidClosed": false, "outputs": [ { "enabled": true, "outputIndex": 0, "position": { "x": 0, "y": 0 }, "priority": 0 }, { "enabled": true, "outputIndex": 1, "position": { "x": 2560, "y": 0 }, "priority": 1 } ] } ], "name": "setups" } ]
When the issue happens again I'll post the json config then.
Ok cool, I got it to happen immediately. Here it is when the issue is present: [ { "data": [ { "autoRotation": "InTabletMode", "brightness": 1, "colorProfileSource": "sRGB", "connectorName": "DP-3", "edidHash": "edfbd56e01bd44cea3b332ada36972e8", "edidIdentifier": "AUS 9984 16843009 47 2020 0", "highDynamicRange": false, "iccProfilePath": "", "mode": { "height": 1440, "refreshRate": 74924, "width": 2560 }, "overscan": 0, "rgbRange": "Automatic", "scale": 1, "sdrBrightness": 200, "sdrGamutWideness": 0, "transform": "Normal", "vrrPolicy": "Automatic", "wideColorGamut": false }, { "autoRotation": "InTabletMode", "brightness": 1, "colorProfileSource": "sRGB", "connectorName": "DP-3", "edidHash": "edfbd56e01bd44cea3b332ada36972e8", "edidIdentifier": "AUS 9984 16843009 47 2020 0", "highDynamicRange": false, "iccProfilePath": "", "mode": { "height": 1440, "refreshRate": 74924, "width": 2560 }, "overscan": 0, "rgbRange": "Automatic", "scale": 1, "sdrBrightness": 200, "sdrGamutWideness": 0, "transform": "Normal", "vrrPolicy": "Automatic", "wideColorGamut": false }, { "autoRotation": "InTabletMode", "brightness": 1, "colorProfileSource": "sRGB", "connectorName": "DP-2", "edidHash": "24958546af32afdbb93ed9c47f196d34", "edidIdentifier": "AUS 9984 16843009 47 2020 0", "highDynamicRange": false, "iccProfilePath": "", "mode": { "height": 1440, "refreshRate": 74924, "width": 2560 }, "overscan": 0, "rgbRange": "Automatic", "scale": 1.25, "sdrBrightness": 200, "sdrGamutWideness": 0, "transform": "Normal", "vrrPolicy": "Automatic", "wideColorGamut": false } ], "name": "outputs" }, { "data": [ { "lidClosed": false, "outputs": [ { "enabled": true, "outputIndex": 0, "position": { "x": 0, "y": 0 }, "priority": 0 } ] }, { "lidClosed": false, "outputs": [ { "enabled": true, "outputIndex": 0, "position": { "x": 0, "y": 0 }, "priority": 0 }, { "enabled": true, "outputIndex": 1, "position": { "x": 2560, "y": 0 }, "priority": 1 } ] }, { "lidClosed": false, "outputs": [ { "enabled": true, "outputIndex": 0, "position": { "x": 0, "y": 0 }, "priority": 1 }, { "enabled": true, "outputIndex": 2, "position": { "x": 2560, "y": 0 }, "priority": 0 } ] } ], "name": "setups" } ]
Yeah, it does appear to be getting messed up. For some reason monitor DP-3 is listed twice and DP-2 does indeed have its scale set to 1.25.
Ah, I forgot to give you the output of drm_info. I'll do that real quick.
Here's the output of drm_info when it is working: https://pastebin.com/wFnPF726
And here is the output of drm_info with the issue present: https://pastebin.com/3xxmkKUg
Oh yeah, I do have a secondary NVidia graphics card that I use for testing stuff in a VM. I wonder if that's creating any funky results? Maybe I'll try removing it and see if the issue is gone.
Nope, I still get the same issue with the NVidia card removed.
๐๐งน โ ๏ธ 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!
Browsing through the commit history, perhaps it's related to this? Maybe for some reason this fix doesn't work on my system? https://invent.kde.org/plasma/kwin/-/commit/d563bc6c86d398a59409f5ea1ad556d93fb45f78
There is also this older commit which is where it seems new screen configuration code was introduced. https://invent.kde.org/plasma/kwin/-/commit/ae84480fbfdc684b8ee4b0207d3ce679f6fb4cd7
Hmm, just taking a gander from reading the source code. Maybe for some reason one of my monitors isn't reporting a valid `edidIdentifier`, and that causes the `uniqueEdid` bool to incorrectly be true here? https://invent.kde.org/plasma/kwin/-/blob/master/src/outputconfigurationstore.cpp?ref_type=heads#L140 Maybe if the `edidHash` was checked before the `edidIdentifier` in that iterator, that would fix the issue? (Since the hash is more likely to be unique than the identifier.) Maybe when I have the time I'll learn how to set up a development environment for KDE to see if that would work.
If the edid identifier is unique, then that's enough to identify the display, and preferable over the edid hash (which can change if you just change settings on the display). As in your case it isn't enough though, apparently the fallback to the hash is indeed not working correctly. It shouldn't have the same hash in the list twice after all...
Ah, yeah, I see. It seems in my case the connector name is more reliable than the hash.
It also seems like `uniqueEdid`, `uniqueEdidHash`, and `uniqueMst` is being recalculated every time `OutputConfigurationStore::findOutput` is called. I'm guessing what may be happening is that for some reason those values are sometimes different across multiple calls. Perhaps the fix is to calculate those bools only once when loading a configuration?
(In reply to Billy Messenger from comment #19) > It also seems like `uniqueEdid`, `uniqueEdidHash`, and `uniqueMst` is being > recalculated every time `OutputConfigurationStore::findOutput` is called. > I'm guessing what may be happening is that for some reason those values are > sometimes different across multiple calls. > > Perhaps the fix is to calculate those bools only once when loading a > configuration? Wait nevermind, that will only be the case if the `const QList<Output *> &allOutputs` parameter changes between calls, which it doesn't appear to.
Wait no, derp, only the list of display pointers stays constant, the values those displays return can still change between calls. So only calculating those bools once could still solve the problem.
Nermind, those methods on `Edid` are constant. (Sorry my C++ is a bit rusty.)
Oh derp, and now I realize those values are supposed to be different across calls.
Darn, now my system is sometimes freezing when I log in/unlock my computer. I'm thinking it might have something to do with one of my monitors not waking up properly. I notice that the freeze happens whenever one of my monitors shows the login/unlock screen while the other monitor shows a blank black screen. If both screens happen to show the login/unlock screens then the freeze/scaling issue does not happen.
Maybe, it's an issue with Mini Displayport? (The monitor that is sometimes blank on the login screen is connected with mini displayport). I'll try switching that to an HDMI cable and see if the issue still persists.
(In reply to Billy Messenger from comment #25) > Maybe, it's an issue with Mini Displayport? (The monitor that is sometimes > blank on the login screen is connected with mini displayport). I'll try > switching that to an HDMI cable and see if the issue still persists. Yes, that actually seems to have fixed both of the issues (the system freezing and the scaling issues). I guess there's something about that mini displayport connection that KDE didn't like.
Oh, nevermind, spoke too soon. I tried just putting the computer to sleep real quick and it froze on the unlock screen again.
This issue could be related to this one https://bugs.kde.org/show_bug.cgi?id=483094
I think this should be fixed by the same MR as for bug 488270
Git commit 7e450e42e5fcbe5d077fcfa473c65a8954c35d11 by Xaver Hugl. Committed on 23/01/2025 at 18:33. Pushed by zamundaaa into branch 'master'. outputconfigurationstore: handle imperfect matches for outputs better There are some situations where there can be multiple matches for a given output, like when two outputs with the same EDID ID but different EDID hashes or connector names were connected before and now only one of them is connected. In these situations, we'd previously just pick the first match in the list, even though the other match is more precise; and that could end up changing the settings for that output. Once the second output is connected again, it would then get the wrong settings. To fix that, this commit only considers an entry in the config as a match if there is only one match for the relevant criteria. If there's multiple, then the search is narrowed down to take more crtieria into account, like the MST path or the connector name. Related: bug 488270 M +90 -38 src/outputconfigurationstore.cpp M +3 -4 src/outputconfigurationstore.h https://invent.kde.org/plasma/kwin/-/commit/7e450e42e5fcbe5d077fcfa473c65a8954c35d11
Git commit c3f4149bf02322011842ad48682c6deabedefc00 by Xaver Hugl. Committed on 23/01/2025 at 18:37. Pushed by zamundaaa into branch 'Plasma/6.3'. outputconfigurationstore: handle imperfect matches for outputs better There are some situations where there can be multiple matches for a given output, like when two outputs with the same EDID ID but different EDID hashes or connector names were connected before and now only one of them is connected. In these situations, we'd previously just pick the first match in the list, even though the other match is more precise; and that could end up changing the settings for that output. Once the second output is connected again, it would then get the wrong settings. To fix that, this commit only considers an entry in the config as a match if there is only one match for the relevant criteria. If there's multiple, then the search is narrowed down to take more crtieria into account, like the MST path or the connector name. Related: bug 488270 (cherry picked from commit 7e450e42e5fcbe5d077fcfa473c65a8954c35d11) M +90 -38 src/outputconfigurationstore.cpp M +3 -4 src/outputconfigurationstore.h https://invent.kde.org/plasma/kwin/-/commit/c3f4149bf02322011842ad48682c6deabedefc00