-
Notifications
You must be signed in to change notification settings - Fork 341
Keep DisplayPort output layout around on disconnect. #479
Comments
I can reproduce. We can just mark them as disabled, and refuse to enable them again. How to detect that a DP monitor is turned off but phy? |
Huh, I was supposed to write "physically connected", but I guess I accidentally deleted the rest of the sentence. |
Ahah, I thought it was a common abbreviation in the DRM world. So what if the user really disconnected the monitor? |
That's why this issue is such a pain in the ass: we can't tell. Either we need to let the user's window placement get massively screwed up by buggy monitors or let a "phantom display" exist, possibly requiring user intervention to actually get rid of it. |
This sounds terrible, I'd rather just mess up the window layout. In sway that just means moving workspaces to another output. If they plug the display back in we can remember where those workspaces came from and move them back. |
Letting the library user deal with it is fine. I was just proposing solutions that would work if it was to be handled in wlroots itself. |
Seconded for remembering the previous workspace on monitor disconnect. I currently have a TV as my primary and a vertical second monitor, and when the TV goes to sleep it shoves all my windows onto the secondary monitor in X (Cinnamon), so I have to move them all back manually when I come back to my computer. It's annoying at best. |
Closing because this is a job for compositors. |
There are some monitors that will appear to be "disconnected" from DisplayPort when you turn them off, even when they're still phy. This can mess with your window placement and what you were doing pretty hard.
It's a complete misfeature, and I don't know why some monitors do it.
Anyway, to get around shit like this, Xorg will still pretend that the monitor is still connected, so your window layout doesn't get messed up.
We should probably do something similar.
I don't know whether this should be done in wlroots itself (inside DRM or elsewhere) or if we should expect compositors to handle it.
It should be a special-case for DisplayPort though. It doesn't seems to happen on other connector types.
The text was updated successfully, but these errors were encountered: