Workspaces move between monitors upon replug

[YaLTeR]

Describe the bug I have a laptop with a built-in display and an external monitor plugged in. Upon replugging the external monitor (which happens often because it's a TV and it "replugs" itself every time I turn it on), sometimes, some workspaces switch monitors, which causes windows to end up on the wrong monitor. If unlucky enough, it can be quite annoying to fix (i.e. if the workspace that decided to move to the other monitor was in the middle of other workspaces with windows on them -- which requires a lot of rearranging to fix).

To Reproduce I don't have a 100% reproducer, but more often than not, upon replugging an external monitor, two workspaces will switch monitors (so some workspace on primary will end up on secondary and vice versa). Which workspace switches monitors seems to be loosely based on which workspace is focused at the time of replug, but it's not 100% consistent.

Expected behavior No workspaces switch monitors.

System information: Please execute ./gather-system-info.sh in you PaperWM clone and paste the output below.

Example:
Distribution: Fedora Linux
GNOME Shell 44.3
Display server: Wayland
PaperWM branch/tag: fix-workspace-moving-breaks-workspace-switching
PaperWM commit: 11f9966c45259c8d04374cc6eb1af4ab7c6a296c
Enabled extensions:
- paperwm@paperwm.github.com

[YaLTeR]

Hmm, so running the current latest version I'm also observing workspaces moving between monitors upon sleep and wakeup. I'm not sure if that also triggers the replug code path. I think on the June version workspaces only moved upon replug and not on sleep.

[jtaala]

Hmm, so running the current latest version I'm also observing workspaces moving between monitors upon sleep and wakeup. I'm not sure if that also triggers the replug code path. I think on the June version workspaces only moved upon replug and not on sleep.

Hey @YaLTeR, haven't been able to reproduce this yet (moving workspaces on sleep). Tell me, does your external monitor take a while to wake up on sleep? E.g. paperwm should restore workspaces when waking from sleep as long as the external monitor is awake and active (basically in a ready state when paperwm is ready to be enabled again (e.g logging back in from the lockscreen).... oh, when you sleep, the lockscreen kicks in right?

Let me know if you use the lockscreen when sleeping too.

[jtaala]

or does the external monitor go to sleep while paperwm is still active? (and not in lockscreen?) - which would likely act like a unplug/replug. Anyways, let me know (also can you confirm the commit id you're on?).

[YaLTeR]

Tell me, does your external monitor take a while to wake up on sleep?

It's a TV so yeah I guess. I'll add though that on the June version I haven't noticed workspaces moving on sleep, whereas after the recent updating I'm noticing it frequently.

when you sleep, the lockscreen kicks in right?

Yeah, but locking and unlocking by itself doesn't cause workspaces to move I think.

does the external monitor go to sleep while paperwm is still active? (and not in lockscreen?)

Nope. When I do turn it off and on manually, which causes a replug, the workspaces move too.

also can you confirm the commit id you're on?

I was on the latest develop at the point after the fix-workspace-moving-breaks-workspace-switching branch has been released on e.g.o.

[YaLTeR]

For some reason lately it's been even worse: when I turn on my TV (after having it off throughout the session) a whole pack of 3 workspaces with windows moves over there, and I have to move everything back (Ctrl+T doesn't seem to work across monitors).

[YaLTeR]

Uh, and as I'm moving the windows some extra workspaces appear on the first monitor in the middle?.. Haven't paid attention but this is a bit weird what's happening

[jtaala]

Yeah, previous (June) version likely didn't suffer for this since we were running in unlock-dialog mode - which means that paperwm wasn't being disabled/enabled on lockscreen (and hence sleep etc.). That's not allowed according to GJS rules and hence we needed to remove that mode for ego (which caused a bunch of issues there - solved with single monitor but seems still issues for multi).

[jtaala]

For some reason lately it's been even worse: when I turn on my TV (after having it off throughout the session) a whole pack of 3 workspaces with windows moves over there, and I have to move everything back (Ctrl+T doesn't seem to work across monitors).

So you can actually move entire workspaces to other monitors quite easily (without messing with windows). Use workspace stack switching - bascially you switch to prev workspace (default key Super+`) - then go to the other monitor and do the same thing, which then switches that workspace to the new monitor.

[jtaala]

Uh, and as I'm moving the windows some extra workspaces appear on the first monitor in the middle?.. Haven't paid attention but this is a bit weird what's happening

Pretty weird - are you using dynamic workspaces? Does this happen with fixed workspaces?

[jtaala]

For some reason lately it's been even worse: when I turn on my TV (after having it off throughout the session) a whole pack of 3 workspaces with windows moves over there, and I have to move everything back (Ctrl+T doesn't seem to work across monitors).

So you can actually move entire workspaces to other monitors quite easily (without messing with windows). Use workspace stack switching - bascially you switch to prev workspace (default key Super+`) - then go to the other monitor and do the same thing, which then switches that workspace to the new monitor.

https://github.com/paperwm/PaperWM/assets/30424662/a8461ad2-e3f8-468a-81db-b511304aff22

[YaLTeR]

So you can actually move entire workspaces to other monitors quite easily (without messing with windows). Use workspace stack switching - bascially you switch to prev workspace (default key Super+`) - then go to the other monitor and do the same thing, which then switches that workspace to the new monitor.

Oh, that's handy, thanks! Except it seems to put the workspace in a numerically sorted position I guess, something to keep in mind (so it's "open workspace on this monitor" rather than "move the workspace here" which I would expect to preserve the current position in the workspace stack).

are you using dynamic workspaces?

Yeah, I'm very used to dynamic workspaces.

Does this happen with fixed workspaces?

This particular thing is a bit weird, I'm not sure what the reproduction conditions are.

[jtaala]

which I would expect to preserve the current position in the workspace stack

Sounds like you're using the wrong switching shortcut. There's a sequential workspace switcher, and a "most recent ordered" one. Easier to use the latter.

[jtaala]

E.g. three fingered swipe down switches between current and the last selected workspace (not last sequential workspace) hence I used that in the video.

[jtaala]

This particular thing is a bit weird, I'm not sure what the reproduction conditions are.

Well, one thing at a time. I've been working on #574 which fixes some other multi-monitor issues and #575. Once these are merged in I'll take a look at improving the replug/restore code

I can at least reproduce disabling an external monitor and turning it back on, and trying to reproduce a workspace switch.

On a sidenote, what might be cool is a keybind to swap monitor workspaces. Given, it's easy to open a non-shown (e.g. not currently on a monitor) to another monitor by using "most recent" workspaces stack switching. But swapping the current workspaces on monitors requires doing that twice (e.g. stack switch the workspace 1 away on monitor 1, then on monitor 2, stack switch that workspace 1 to monitor 2, and then doing the same for monitor 1).

[Lythenas]

Btw I managed to also reproduce this yesterday. It didn't happen every time the monitors went to sleep, so I'm not sure what exactly triggers it... Interestingly it also only happened when I have two external monitors plugged in AND the laptop open (so using 3 monitors). If the laptop is closed (i.e. only the external monitors are turned on) it works fine.

[jtaala]

Thanks @Lythenas. Yeah, atm PaperWM uses a heuristic (basically the monitor index, x-offset in stage, and size etc.) to try figure out what space was where. Problem is, sometimes, monitor indexes can change for monitor layouts (and other corner cases). I think it should be changed to use monitor connector id's (e.g like DisplayPort-0) to identify a more stable pairing between monitors and workspaces, especially during enable/disable cycles.

[jtaala]

Hey @YaLTeR and @Lythenas,

Just pushed up a PR that should fix this (although there might be other corner cases here). Can you please test this branch out. Working well for me so far.

git fetch --all
git checkout fix-monitor-workspace-persistence

and logout/login.

Thanks!

[jtaala]

Hey @YaLTeR, also since you're very good(!) at finding, reporting, testing issues etc. I've sent an invite as a collaborator.

[jtaala]

Working well for me so far.

Still not quite right - sometimes I get space on right monitor but windows moved. Getting close though.

Scrap that just workspace indicator not being update after restore.

[jtaala]

Okay, I think I've got it. Please give this a go. Quite a few changes were needed here, but still may be some corner cases on the monitor mapping on restore.

[Lythenas]

I will check it out next week when I'm in the office. As that is the only situation I ran into the problem so far.

[jtaala]

I will check it out next week when I'm in the office. As that is the only situation I ran into the problem so far.

Nice - quick one - at work do you use dynamic workspaces (as opposed to fixed workspaces?).

[Lythenas]

I don't think so, but I will check. But I also use the same laptop at home and don't have problems there. But at home I don't have space to keep the laptop open, so I only the two external monitors.

But I thought we recommend against using dynamic workspaces anyway? Or am I wrong?

[jtaala]

But I thought we recommend against using dynamic workspaces anyway? Or am I wrong?

Thanks @Lythenas, this PR should now work fine with dynamic workspaces (make sure to git pull the latest on #577).

In general PaperWM works okay with dynamic workspaces - does make things a little more complicated and has a few (minor?) issues that I've seen. But people (including @YaLTeR) use it efficiently. It's also AFAIK the default gnome setting, i.e. 4 workspaces dynamic set to true (?).

The main issue I've seen is that if you have workspaces set at 4 (and PaperWM has settings for those 4 workspaces, e.g. in PaperWM settings) - then if you dynamically create a workspace in gnome (e.g. a 5th one by dragging it to a new workspace or using <shift+super+pageup/pagedown>) then PaperWM will confusingly create a space with the same name as the space it was on. So, you could end up with 2 workspace 5's. Now, they're different workspaces... just named the same.

Maybe the above only occurred with multi-monitors but I did notice it, and was very confused there for a while.

I'll create a new issue re this as I can reproduce it with dynamic workspaces. You don't have that with fixed workspaces (well, since you can't dynamically create workspaces there).

Anyways, those issues don't seem too bad, and given some users are using and like dynamic workspaces I'm of a mind to resolve some of the related issues there.

[Lythenas]

Tested the PR today for a while (not the whole day) and re-plugged the monitors multiple times. Everything seemed to work fine. I will test more tomorrow.

[jtaala]

Tested the PR today for a while (not the whole day) and re-plugged the monitors multiple times. Everything seemed to work fine. I will test more tomorrow.

Thanks @Lythenas - please pull the latest to avoid a scratch window issue that was intro'd recently.

Thanks for testing!