https://bugs.kde.org/show_bug.cgi?id=465396
--- Comment #20 from Harald Sitter <sit...@kde.org> --- Git commit 49cc50e629d55d258218bbe5e0abb0c6e93951e3 by Harald Sitter. Committed on 21/04/2023 at 14:40. Pushed by sitter into branch 'Plasma/5.27'. xrandr: always try to update primary When screen0 gets disconnected the atom essentially says it is priority 1 but we ignore it on account of being disconnected/disabled (this happens inside priority()). This caused setPriority to exit early and not do anything. Upon plugging screen0 back in the atom comes into play again and it is still saying the screen is priority 1, but really another screen was/is priority 1. What happens then is that since the atom says the screen is priority1 == newpriority == noop. tldr: - screen0 disconnect: priority=0 == newPrirority=0 -> noop - screen1: priority=2 != newPriority=1 -> set_primary - screen0 reconnect: priority=1 == newPriority=1 -> noop - screen1 is now primary but the entire kscreen system thinks it should be screen0 to solve this problem simply update the primary regardless of the property change, at worst this is noop on the xcb side of things, at best we ensure the primary is in sync (cherry picked from commit e17c6b5a6a9b5778f9be5b962b1d31878579945a) M +5 -3 backends/xrandr/xrandroutput.cpp https://invent.kde.org/plasma/libkscreen/commit/49cc50e629d55d258218bbe5e0abb0c6e93951e3 -- You are receiving this mail because: You are watching all bug changes.
