https://bugs.kde.org/show_bug.cgi?id=465396
--- Comment #18 from Harald Sitter <sit...@kde.org> --- Git commit e17c6b5a6a9b5778f9be5b962b1d31878579945a by Harald Sitter. Committed on 21/04/2023 at 14:37. Pushed by sitter into branch 'master'. 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 M +5 -3 backends/xrandr/xrandroutput.cpp https://invent.kde.org/plasma/libkscreen/commit/e17c6b5a6a9b5778f9be5b962b1d31878579945a -- You are receiving this mail because: You are watching all bug changes.
