Bug 437824

Summary:	Wrong monitor enabled on wake-from-suspend
Product:	[Plasma] KScreen	Reporter:	leftcrane <leftcrane>
Component:	common	Assignee:	kscreen-bugs-null <kscreen-bugs-null>
Status:	RESOLVED WORKSFORME
Severity:	normal	CC:	kde
Priority:	NOR
Version First Reported In:	5.21.5
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description leftcrane 2021-05-29 10:08:20 UTC

Since Kwin naively ties basic desktop configs to overly-specific and fragile "display setups" (how exactly these setups are "auto-detected" internally I have no idea but it's a pretty fragile process that can be easily thrown off course). Thus KDE constantly "forgets" which monitor should use which settings, with predictably catastrophic results.

And I only have two monitors - laptop and external. I only use one display at a time. It's the simplest possible configuration involving more than one monitor (dual monitors carry show-stoppers of their own - namely all windows moving to the left-most display when it's plugged in, ).

Here are a couple examples of how can break:

1. The wrong display gets often gets "disabled" on wake, requiring manual intervention to enable the external display every time and disable the laptop.
2. Often, the sole existing display is disabled on wake. Thus you must either track down your secondary monitor and plug it in, or reboot the machine.
3. It is essentially impossible to change the wallpaper permanently. Wallpaper change isn't respected even on the *sole primary display.* Whenever KDE "forgets" the display (it thinks the assembly has changed for some reason), it applies the previous wallpaper.
4. Panels would probably suffer from the same problems as the wallpaper, though I can't test this because I use latte dock - which is tied to display hardware name and always respects the primary display.

It seems that the source of this amnesia is two fold:

1. (plasma) The expectation that each unique "display setup" can have a totally unique plasma config for each display within that "setup", and other configurations in other setups. The number of unique setups is of course infinite.
2. (kwin) The over-specification of "display setups" - KDE tries to find an exact match for the setup and predictably fails.

These problems wouldn't arise if the architecture was based on the concept of primary and secondary monitors (only two distinct classes) instead of infinite unique "setups," each with its own set of unique per-display configs.

I know these are general architectural issues and don't expect a fix too soon. But are these problems at least recognized as such? KDE is the only desktop that can be rendered inoperable by the existence of multiple displays, but I don't see any recognition of this fact.

Possibly related https://bugs.kde.org/show_bug.cgi?id=292419

Comment 1 David Edmundson 2021-05-30 22:25:09 UTC

Please try and keep things specific and terms professional. 

Lets focus this bug report on: 

>1. The wrong display gets often gets "disabled" on wake, requiring manual intervention to enable the external display every time and disable the laptop.

and lets pry for a bit more information to make this actionable.

Can I have the output of "kscreen-console" whilst you perform a sleep.
and kscreen-doctor throughout.


>I know these are general architectural issues 

If you've already looked into this, please do state what you are referring to.

Comment 2 David Edmundson 2021-05-30 22:25:30 UTC

Please try and keep things specific and terms professional. 

Lets focus this bug report on: 

>1. The wrong display gets often gets "disabled" on wake, requiring manual intervention to enable the external display every time and disable the laptop.

and lets pry for a bit more information to make this actionable.

Can I have the output of "kscreen-console" whilst you perform a sleep.
and kscreen-doctor throughout.


>I know these are general architectural issues 

If you've already looked into this, please do state what you are referring to.

Comment 3 leftcrane 2021-06-07 17:36:40 UTC

I can't reproduce the behavior reliably. Sometimes it happens, other times it doesn't. In the same way, I can't reproduce KDE "forgetting" the wallpaper on a particular display, panels etc. This is why my hunch is that this is a general architectural problem.

Comment 4 leftcrane 2021-06-08 12:28:44 UTC

Now I'm finding that the sole connected display (laptop) doesn't get enabled when I disconnect the external. I've seen this behavior before as well.

To mind, it's obvious that KDE simply does not have any code to guarantee that when there is only one display connected (doesn't matter what the display is), that display will be:

1. Turned on
2. Be configured as the primary display.

Comment 5 leftcrane 2021-06-08 12:45:09 UTC

Or if is configured as the primary display, this doesn't seem to affect behavior.

I don't see how this can be solved without simplifying display settings as follows:

There are only two types of displays and display configs - primary and secondary.They apply to all primary and secondary displays regardless of make, model, resolution, other displays present etc.

A primary display must always be present and turned on.

This would result in sane behavior.

Comment 6 leftcrane 2021-06-08 12:47:22 UTC

BTW, I've seen two reports of the same category of problem on reddit in the past month. The users were too lazy to report it here though.

Comment 7 leftcrane 2021-06-08 13:20:54 UTC

For the display disconnect issue:

kscreen-doctor yields error:

qt.qpa.xcb: QXcbConnection: XCB error: 5 (BadAtom), sequence: 381, resource id: 0, major code: 20 (GetProperty), minor code: 0

Comment 8 leftcrane 2021-06-08 13:24:45 UTC

I can't reproduce the sole display being turned off issue anymore, because I just had to toggle some display configs to enable the main display (again). But after I did that, I lost the wallpaper on the secondary display. It's always something.

It's sort of a catch-22 scenario, unless you have the logger running at all times.

Comment 9 Bug Janitor Service 2021-06-23 04:33:46 UTC

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

Comment 10 Bug Janitor Service 2021-07-08 04:33:49 UTC

This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!