regolith-linux / regolith-desktop

Meta package for the Regolith Desktop Environment
1.5k stars 31 forks source link

Multi-monitor workspaces mixed after sleep #605

Open tartavull opened 3 years ago

tartavull commented 3 years ago

Let's say I have workspace 1 in an external monitor and workspace 2 on the laptop screens. If I lock the screen and then unlock it, both workspace appears on the laptop screen and none on the external monitor.

Which package is responsible for managing this? is there an i3 configuration for this?

kgilmer commented 3 years ago

My guess is it that it's a bug that spans monitor hotplug and gnome-settings-daemon. I also have this issue, and my work around is to use i3-snapshot to save and restore my workspace layouts after this occurs.

antgrutta commented 3 years ago

I am experiencing this bug as well, upon unlocking not only will the workspaces be all jumbled up between the monitors but the scaling of the i3 bar will have reset as well. The i3-snapshot workaround unfortunately is inconsistent for me and does not account for the scaling issue. What might the best way to debug this issue further? Is this page, Debugging i3 still relevant?

cfsmp3 commented 3 years ago

Is this after unlocking or after waking up? Can you reproduce this bug by just locking (not sleeping) and unlocking (and therefore, not waking up)?

antgrutta commented 3 years ago

For me it is unlocking after waking.

cfsmp3 commented 3 years ago

For me it is unlocking after waking.

So just locking / unlocking is not enough to reproduce the problem?

If this is the case then - is the state of the monitors relevant? What happen if you turn off the monitors first, and then sleep the computer? Does that makes a difference?

antgrutta commented 3 years ago

Tested a couple different scenarios:

I suspect in the cases of the monitoring and computer sleeping, the issues are being caused by the same thing...whatever that is. Also I did get a message box stating "compton has closed unexpectedly", this was when the computer came back from a full sleep

tartavull commented 3 years ago

This is by far my biggest annoyance with Regolith, so I would love to help fixing it, but I'm not sure were to get started.

I can attest the same behaviour as you @antgrutta

cfsmp3 commented 3 years ago

This is by far my biggest annoyance with Regolith, so I would love to help fixing it, but I'm not sure were to get started.

I don't think this is a Regolith issue but an i3 issue.

Does this help?

https://faq.i3wm.org/question/2332/flexible-monitor-setup.1.html

kgilmer commented 3 years ago

Thanks @cfsmp3! In this case I believe that gnome-flashback is managing the monitors and so that would be the first place to look. I've also added a new howto just now for determining if behavior is specific to Regolith or may be in gnome-flashback: https://regolith-linux.org/docs/howtos/gnome-flashback-session/

If someone can run a gnome-flashback session based on the linked howto and see if the problem is resolved or continues it would help in isolating where to look.

antgrutta commented 3 years ago

@kgilmer, I tested with gnome-flashback and did not observe any of the same behaviors.

kgilmer commented 3 years ago

Very helpful, thank you @antgrutta . I guess this indicates that i3 is not keeping window/workspace state when monitor configuration changes. It seems like this should be a common issue for laptop users that use multiple displays. Monitor and computer sleeping may cause the display configuration to change. i3 responds by remapping workspaces to available displays on start (another guess). It should be possible to confirm this by checking the syslog under either case to see if there is a log entry indicating that a display has been removed. I don't know if a syslog entry is generated in this case but can check tomorrow.

kgilmer commented 3 years ago

this problem should be reproducible with a "vanilla" i3 install. I don't believe there is anything in Regolith causing this issue, it's simply the behavior of i3 as it relates to display changes.

kgilmer commented 3 years ago

Managing i3 window state is pretty straightforward via the IPC interface. The challenge that comes to mind now in writing something to fix this is knowing when state should be saved and restored in such a way that it only happens when you want it to.

cfsmp3 commented 3 years ago

In theory we can always get interesting change events from D-Bus. Here's a script (not mine, just found it) that get session lock/unlock events:

https://gist.github.com/naftulikay/ab8740c769a599ab457bb611f8b75dad

kgilmer commented 3 years ago

nice find @cfsmp3 ! It wouldn't be perfect (because i3-snapshot isn't fully implemented) but it should be possible to use something like this python program to call i3-snapshot to save and restore the window layout across the subset of events that need this treatement. Of course, if there are other programs that do this better that would be fine too.

kgilmer commented 3 years ago

i3-snapshot restores workspaces to their displays and windows to their workspaces but doesn't reconstruct the positions of the windows in a given workspace at this time.

cfsmp3 commented 3 years ago

i3-snapshot restores workspaces to their displays and windows to their workspaces but doesn't reconstruct the positions of the windows in a given workspace at this time.

Maybe this will do the trick? https://i3wm.org/docs/layout-saving.html

kgilmer commented 3 years ago

No, this wouldn't work without user intervention:

Please note that the output of i3-save-tree(1) is NOT useful until you manually modify it — you need to tell i3 how to match/distinguish windows (for example based on their WM_CLASS, title, etc.). By default, all the different window properties are included in the output, but commented out. This is partly to avoid relying on heuristics and partly to make you aware how i3 works so that you can easily solve layout restoring problems.

i3-snapshot cheats by using the volatile window ids from X. But of course these would not remain stable across instances of an X session so it only works in a given session. the upside is that it's automatic.

It's been awhile but I believe this function needs to be updated to handle window position. But before doing anything there a PoC should be produced to valid that DBus events are sufficient for this task.

cwh1te commented 2 years ago

I recently switched from using just i3-gaps on Arch to Regolith on Pop_OS! and this is now a problem for me. On my Arch build it always remembered my monitor and window layout. Now even letting the monitors turn off is enough to scramble everything. Also the resolution of my displays gets changed when they wake up. I wonder if maybe gnome-session is hijacking some signals that i3 needs to gracefully handle these events.

kgilmer commented 2 years ago

Hi @cwh1te , thanks for the details. You could test your theory by installing the i3-gaps (or i3) xsession package, and then login with that. That would be "straight" i3 without any gnome integration. If you're on Regolith, the package is i3-gaps-session. After installing select the session from your login screen. Would love to know either way if gnome has any impact on this bug, TIA!

fhchl commented 1 year ago

I am using Regolith on a laptop with closed lid and two identical monitors. The monitors get's switched around sometimes after waking from sleep or switching the monitors on and off. My current hack is to turn the monitors on and off in some order that will make the displays appear in the right spots again.

Works every time - most of the times. 🤓