Screen Lock reorders windows to hardware primary display in dual screen on returning

[grizzlyfred]

I have a FHD and a 4K Monitor connected to an NVIDA-proprietary driven card.
FHD ist connected with DVI and 4K is connected with Display Port.
From the BIOS point of view, the FHD Display is the primary display, but I set the 4K display within Cinnamon 3 and within NVDIA settings as the primary display.

In both Mint 18 and Manjaro-Cinnamon, after the screen saver / lock has been activated and then I return to my session by re-entering the password, open windows are moved from the 4K ("virtual primary") desktop to the FHD ("virtual secondary") desktop.

I expected to find all windows at their original place - as is the case with long-used Mint 17.3.

[mtwebster]

Is happening when the screen is just locked, or after maybe waking from suspend? (if you lock the screen, then immediately unlock it, does it happen?) I just want to be as clear as possible about the condition where it occurs.

[Feuerfuchs]

I have a similar setup (4K display over DisplayPort + FHD display over HDMI) and I think I know what the reason for this problem is.

When I started using my 4K display, I had the same issue that all windows were all on one display (I don't remember if it was the primary or secondary one) when I woke my computer from idle mode (with switched off displays). It turned out my 4K display stopped reporting as being connected as soon as it entered the standby mode, and when it woke up it was recognized again. Since Cinnamon automatically adapts to new display layouts and the 4K display was "gone" at one point, it moved all windows to the remaining FHD display.

@grizzlyfred, when you were on Mint 17.3, did you already have the 4K display?

In any case, I could circumvent the issue by disabling Cinnamon's automatic adaption altogether:
dconf write /org/cinnamon/settings-daemon/plugins/xrandr/active false

[grizzlyfred]

I try to sum up what I found out (untested yet, but now obvious - afraid to log out to have to setup all again.

@mtwebster It happens always in normal screen lock mode (I do not use suspend, it has been shaky for a decade and I do not experiment / tinker with it any more)
@Feuerfuchs: On Mint 17.3 there were no problems at all I had the same 4K and an FHD display. I attribute this to the fact, that I once used the cinnamon "Monitor" settings app and then forgot after months of not changing anything)

But I think the flaw was as follows - also refer to nvidia-x-server-settings-lost-on-every-reboot

• The NVIDIA graphical screen configuration panel is by design not persistent. You have to save the machine-wide configuration in the "X Server Display Configuration" dialogue and the per-user settings in the nvidia-settings Configuration dialogue, but it is not obvious which option belongs to which domain.
• Mint Cinnamon has its own configuration App called "Monitors" (or Displays?) in the start menu (and the system configuration control center). Here you have to change something to release the "Apply" button. Then a ~/.config/monitors.xml is saved. As I did my initial 18 install inVirtualbox keep working on 17.3 at the same time, this file had obviously totally wrong contents in the first place.
  I will now check if after saving a new monitors.xml (whose contents look promising), all will be good.

Note:
I had to tinker with "nomodeset" in the grub line though and have not yet figured out how to get a "normal" bootup-message (like whats started instead of the splash screen...)

[grizzlyfred]

Tested now the following:

• Lock screen and re-login => all good
• Log out and re-login => small flaw, mouse cursor and the like are now slightly (60% smaller) than before e.g. they were larger before and now back to what's for the 4k - I scaled fonts by 1.4 and the start bar, did not use "double UI" feature as a tradeoff for both monitors)

So I figure there is a "usability" issue as NVIDIA proprietary driver settings and cinnamon built-in config is not synchronized (compare to windows, where you usually have vendor-specific tabs added to the display config (not sure how that would look know 8.x and 10 though, lost track after 7...).
Will this ever fix or is it rather a matter of documentation / learning curve? Kind of unsure whether to close this or not...
Probably a user who changes non-persistent settings in NVIDIA to something different from the monitor.xml will have her windows reordered after logging back in. A fix would be to always honor the user's settings when opening the lock screen -- rather than reading the monitors.xml. In other words: assuming all resolution settings are made through the built-in dialogue and not a driver dialogue is not 100% correct). Or bad user behavior ;-)

@Feuerfuchs: I refrained from disabling xrandr automatic adaption for now.

Note: the smaller cursor and so on is also reflected in a smaller (in absoulte pixel count) login box at the lock screen. There could also be the fact, that the 1.4 font scaling setting is not honored at the lock screen and for some reason, virtual box had decided before that doubling everything and running with "2k" including the lock screen was good enough...

Tiny note:
This is also consistent to some privacy flaw I noticed in some lollipop and android phones/tablets and mint 17.3 as well as some other (mostly gnome-flavored) distros like in winter 2015/2016 that sometimes the user's screen contents where visible for 200-500ms until the password entry dialogue was shown. Most likely such an attempt to restore user's settings was made and thus somehow the content shown, that should be hidden until user logs back in?

[grizzlyfred]

Mostly works stable after some days of testing. Seldomly the login screen is back to the FHD secondary disply, but fortunately no windows are reordered.

[pwil3058]

I've just suddenly (today) noticed this behaviour on my system. Relevant details are:

• Cinnamon-3.0.7 updated on 11OCT2016 (over 6 weeks ago)
• only desktop setting changes that I've made recently is using "click to focus" instead of "focus follows mouse"
• most recent "likely" significant change was kernel upgrade to 4.8.7 yesterday from 4.8.6

I'm going to reboot with an older kernel to see if the problem goes away.

[pwil3058]

After rebooting with the older kernel (4.8.6-201), the problem has not been seen. This would indicate that a change to the graphics driver in kernel-4.8.7 is strongly implicated in this problem. From Cinnamon's "System Info" page, my graphics hardware is:

AMD/ATI Cape Verde XT [Radeon HD 7770/8760/R7 250X]](prog-if 00 [VGA controller])

Please note that I made a mistake (since fixed) in my original comment and I have Cinnamon 3.0.7 installed (not 3.0.2) but the date of installation was correct.

Is there any other information I can provide that would be of help?

[pwil3058]

I've just upgraded to kernel-4.8.8 and the problem seems (only a few minutes running, though) to have gone away. If it comes back I'll report it again.

[pwil3058]

It's back but there is a twist. When I tested by locking/unlocking the screen it didn't occur but when I left the machine unused for a while and it turned off the screens (without locking) the problem occurred again. This is with the 4.8.8 kernel. I'm going to switch back to 4.8.6.

[pwil3058]

It seems to be the case that Cinnamon isn't turning the monitors off when I'm using 4.8.6 kernel (just locking them) which could be why the problem doesn't occur there.

[pwil3058]

After another half day unattended with kernel 4.8.6 Cinnamon still hasn't turned the screens off but locking the screens doesn't cause the moving windows problem. So both 4.8.6 and 4.8.7/8 are causing problems for Cinnamon albeit different ones.

[pwil3058]

Went to kernel-4.8.8 and did:

dconf write /org/cinnamon/settings-daemon/plugins/xrandr/active false

which fixed the problem of the migrating windows. However, a new problem has arisen in that after the system comes back from "monitors off" the sound (which comes via the video card) no longer works.

Cinnamon can see the sound driver in the "settings" tool and it is selected as sound system to be used but nothing comes out of the speakers. Tried kernel 4.8.7 and same problem. Problem does not exist with kernel 4.8.6 but with that kernel Cinnamon seems unable to turn the monitors off.

[germanfr]

I've installed a second monitor just today and this has been happening to me all the day, but it moves them to the secondary monitor instead.

I've been out and when I came back and resumed my computer all windows where moved to the secondary monitor. Also, new windows opened in there, even though they where launched from the primary one and the mouse was there.

Now I lock it and nothing happens. I suspend it and nothing happens. I even let it turn off the screen by the power timeout but nothing. I can't reproduce anything again, but all the day happening.

[tjmpoc]

I too see the bug "uncommanded move of all windows to a single monitor on a two monitor setup".

OS: Linux mint 18.1 with kernel-4.4.0-53
hardware: Intel i7-6700 integrated GPU and dual identical external monitors

the bug only happens after leaving the computer (e.g. for 10 minutes) but seems to be intermittent. I have tried disabling as many screensaver and suspend settings as I could find, but without effecting the bug.

[tjmpoc]

make that "Linux Mint Cinnamon 18.1".
also, I don't know if it is related, but I too see the "Cinnamon unable to turn off monitors" bug.

[AlbertJP]

Bug still exists in 18.1. At my work I currently use three monitors: laptop and two external screens (DP and HDMI). The windows on the HDMI monitor get moved to the laptop screen, but the windows on the DP monitor stay in place. Intel HD Graphics 620.

It doesn't happen always, it seems to happen only when the screen turns black, not when I manually lock & immediately unlock it with Ctrl-Alt-L.

[finswimmer]

Hello,
are there any new news to this problem?

I'm using cinnamon 3.6 under ArchLinux. My Laptop have an intel card for the internal display and a nvidia card for the externals.

This workaround doesn't work for me:
dconf write /org/cinnamon/settings-daemon/plugins/xrandr/active false

It seems that cinnamon is just to fast in recognizing all monitors. So if the external monitor needs to long to wake up, the described behaviour appears.

fin swimmer

[grizzlyfred]

Unfortunately, I had to switch to single monitor setup for now (old one broken) so I cannot update. As soon as dualhead is on the table again, I'll keep you posted.
For some reason, however, I did not observe that behaviour on debian stretch with an hp ultraportable 11" thing

[macrokernel]

I am using Ubuntu Trusty with Cinnamon 2.8.8. My computer has an Intel i3-3220 video with a TV on HDMI3 and a monitor on DP1, both are Full HD, monitor is primary screen.

This workaround does work for me:
dconf write /org/cinnamon/settings-daemon/plugins/xrandr/active false

[redjaguar]

4K monitor on HDMI, 2K monitor on DVI. Mint 17.3 did not have this issue. 18.1 does. 17.3 has the "windows being moved to single display instead of saved in location" when the 4K is turned off.

My workaround: keep the nvidia-settings application running... however I still have to rearrange the windows back to where they were.

I have the settings saved in both the user and system wide X settings but that does not make a difference.

[bitstrings]

I have tried dconf write /org/cinnamon/settings-daemon/plugins/xrandr/active false but it doesn't fix anything, Cinnamon 18 and 19.

This is super annoying.

[redjaguar]

This may be a separate but related bug but now instead of jus re-ordering the windows the display mode goes to mirrored when the displays are powered off then turned back on. Don't know which is more annoying.

…

On Mon, Jul 9, 2018, 6:46 PM Pino Silvaggio ***@***.***> wrote: I have tried dconf write /org/cinnamon/settings-daemon/plugins/xrandr/active false but it doesn't fix anything, Cinnamon 18 and 19. This is super annoying. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5487 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALT632jJ_MPOHhTD1Nqnrg_pk-B781Whks5uE-tEgaJpZM4JVh5Q> .

[mtwebster]

Disable it in startup programs -

[bitstrings]

Yeah that's not going to work for all, specially if you need to rotate or position your screens (nvidia-settings might help). However, you have 2 choices. Either use another xrandr client like lxrandr or simply edit cinnamon-settings-daemon-xrandr.desktop (.config/autostart) and add --exit-time:

Exec=/usr/lib/cinnamon-settings-daemon/csd-xrandr --exit-time 1

[nicoulaj]

I have also been affected by this bug for many versions. It happens when screens wake up (no suspend needed, just screens off). I guess this is due to the main screen being slower at waking up than the other one, and cinnamon does not wait long enough. I tried many combinations, swapping ports, using HDMI vs DisplayPort, none worked: windows are always moved to the same screen.

If this work with a timeout, maybe just make it somehow configurable ?

Some info:

• Distro: Arch Linux

• Cinnamon 3.8.8

• Using nvidia proprietary driver 396.54

• Screen models: Asus PG2789QR / Asus VG248QE

• Xorg config:

   Section "ServerLayout"
       Identifier     "Layout0"
       Screen      0  "Screen0" 0 0
       InputDevice    "Keyboard0" "CoreKeyboard"
       InputDevice    "Mouse0" "CorePointer"
       Option         "Xinerama" "0"
   EndSection
   
   Section "Files"
   EndSection
   
   Section "InputDevice"
       Identifier     "Mouse0"
       Driver         "mouse"
       Option         "Protocol" "auto"
       Option         "Device" "/dev/psaux"
       Option         "Emulate3Buttons" "no"
       Option         "ZAxisMapping" "4 5"
   EndSection
   
   Section "InputDevice"
       Identifier     "Keyboard0"
       Driver         "kbd"
   EndSection
   
   Section "Monitor"
       Identifier     "Monitor0"
       VendorName     "Unknown"
       ModelName      "Ancor Communications Inc VG248"
       HorizSync       30.0 - 160.0
       VertRefresh     50.0 - 150.0
       Option         "DPMS"
   EndSection
   
   Section "Device"
       Identifier     "Device0"
       Driver         "nvidia"
       VendorName     "NVIDIA Corporation"
       BoardName      "GeForce GTX 1080 Ti"
   EndSection
   
   Section "Screen"
       Identifier     "Screen0"
       Device         "Device0"
       Monitor        "Monitor0"
       DefaultDepth    24
       Option         "Stereo" "0"
       Option         "nvidiaXineramaInfoOrder" "DFP-5"
       Option         "metamodes" "DP-0: 1920x1080_144 +2560+360 {AllowGSYNC=Off}, DP-2: 2560x1440_144 +0+0 {AllowGSYNC=Off}"
       Option         "SLI" "Off"
       Option         "MultiGPU" "Off"
       Option         "BaseMosaic" "off"
       SubSection     "Display"
           Depth       24
       EndSubSection
   EndSection
  

• ~/.config/monitors.xml:

   <monitors version="1">
     <configuration>
         <clone>no</clone>
         <output name="DP-2">
             <vendor>AUS</vendor>
             <product>0x27b1</product>
             <serial>0x0001747a</serial>
             <width>2560</width>
             <height>1440</height>
             <rate>144</rate>
             <x>0</x>
             <y>0</y>
             <rotation>normal</rotation>
             <reflect_x>no</reflect_x>
             <reflect_y>no</reflect_y>
             <primary>yes</primary>
         </output>
         <output name="DP-0">
             <vendor>ACI</vendor>
             <product>0x24a4</product>
             <serial>0x01010101</serial>
             <width>1920</width>
             <height>1080</height>
             <rate>144</rate>
             <x>2560</x>
             <y>360</y>
             <rotation>normal</rotation>
             <reflect_x>no</reflect_x>
             <reflect_y>no</reflect_y>
             <primary>no</primary>
         </output>
     </configuration>
   </monitors>
  

[grizzlyfred]

Actually, it seems to me like a more widespread problem now in 2018, because I have seen the same happening on android devices (revealing what the user sees for a short time before asking e.g. the swipe code. (Meaning: no correct saving of the user screen and blackening it prior to lock)
My current manjaro vm on my mac, however seems to correctly "blacken" everything when going in lock mode - so as said above, there is probably two bugs at work - not waiting a reasonable time for multiple monitors to wake up (causing wrong restore as in "docked off" mode AND not blackening the user screen prior to locking...)

[torgash-ivanblch]

Hey everyone. Still no solution? This bug irritates me even in Cinnamon 4 of Linux Mint 19.1.
Secondary display is where windows gather on wake up

[brigantino2]

I have the same problem on Linux Mint 19.1 with two monitors. I found a workaround on another blog. It looks like the problem comes with power management: when DPMS is active monitors are turned off after a period of inactivity. In this case the system thinks there is no monitor plugged and when reactivating, windows move to the first screen that powers on (I suppose).
So the workaround is disabling this PM feature. In Mint menu, Power Management -> set "Turn off screen when inactive" to "never".

[IAMtheIAM]

Years later it still occurs! Mint 17, 18, and 19. Really annoying

[socketbox]

Still an issue under 19.2, with kernel 4.15.0-58-generic x86_64

[Journeyman1900]

Same here,
19.2, 4.15.0-58-generic,
Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X]

[tdenewiler]

I have been having a similar problem for a year or so. I have dual monitors: FHD as primary on HDMI and 4K as secondary on Display Port. I let the monitors sleep after about 10 minutes. When waking up, all windows move from secondary to primary monitor. Both monitors are plugged into an nVidida GeForce GTX 1080.

Today I accidentally fixed the issue for my setup. My secondary 4K monitor is a Samsung, Model Code LU28E510DS/ZA, Version PA01. I went into the settings on the monitor (not through the OS) and changed Samsung Magic Bright from Standard to Custom. I also turned Eye Saver Mode from On to Off. After making those changes the monitors went to sleep after 10 minutes, woke up on mouse movement, and all of my windows were on the monitors I had previously moved them to. The whole cycle has worked about 10 times today.

I had previously tried the following suggestion without success (reverted the setting after it didn't make any difference):

 dconf write /org/cinnamon/settings-daemon/plugins/xrandr/active false

My operating system is:

$ lsb_release -a
No LSB modules are available.
Distributor ID:	LinuxMint
Description:	Linux Mint 18.2 Sonya
Release:	18.2
Codename:	sonya

The kernel I am using is

$ uname -a
Linux leaf 4.8.0-53-generic #56~16.04.1-Ubuntu SMP Tue May 16 01:18:56 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

I hope that helps someone.

[Gustav0ar]

I'm having this issue, it is really annoying. In my setup I have workspaces enabled only in main monitor.
I'm using Linux Mint 19.3,
Kernel: 5.3.0-24-generic #26~18.04.2-Ubuntu
QHD Acer monitor using Display Port and
FHD LG monitor using HDMI
GPU: Nvidia GTX 1070 using official nvidia 440.44 driver

The DisplayPort monitor is set as primary, but the windows are all moved to the HDMI one when computer wakes up.

[evanleonard]

Having this issue now again. System info:

GPU: NVIDIA Corporation GM107GL [Quadro K1200]
Nvidia driver version: 430.50
Distributor ID:
Debian Description: Debian GNU/Linux rodete
Release: rodete
Codename: rodete
5.2.17-1rodete3-amd64 #1 SMP Debian 5.2.17-1rodete3 (2019-10-21 > 2018) x86_64 GNU/Linux

Dual monitors, and the newer 4k monitor seems to take longer to wake up than the older 27" monitor, so all windows go to the older 27" monitor (which is the secondary monitor).

[deeaycee]

Happening to me too. for a few years.... i'm on the newest mint and the newest cinnnamon. two identical samsung monitors. one on hdmi, one on display port. both on nvidia card.

Monitors: 2x Samsung U28E510 (reset to factory settings)

Distributor ID: LinuxMint
Description: Linux Mint 19.3 Tricia
Release: 19.3
Codename: tricia

Cinnamon 4.4.8

Kernel: 5.3.0-28-generic #30~18.04.1-Ubuntu SMP Fri Jan 17 06:14:09 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Nvidia GeForce GTX 750Ti
Nvidia Driver: 435.21

i tried "dconf write /org/cinnamon/settings-daemon/plugins/xrandr/active false", didn't work so i set it back.

finally i went to power management, set "Turn off screen when inactive" to NEVER,
"suspend when inactive" is always NEVER for me,
then I went to Screensaver and set it to 5 minutes.

not what i want, but it works for now.

[jorp]

Just to chime in here, it looks like this issue possibly spans DEs as well. I'm experiencing something similar with a triple monitor setup on Fedora 31, Xfce 4.14.

It is possible that this is an Xorg bug?

Here is what seems to be a relevant report for KDE on Ubuntu.

I've also found some Xfce forum posts here and here.

[ghost]

I have this 4 year old problem on wayland too (had it on xorg before that).

The solution seems to be to just switch to a WM (i3, sway, etc).

[mintyDave7s]

Just to be different, this is an issue for me on Mint 19.3 Mate simply by plugging in an HDMI cable connected to a powered off ASUS 27" external monitor.
Dell Studio 1555, dell (maybe radeon?) graphics, not nVidia.
My laptop monitor is set as primary, but as soon as I plug in the HDMI cable, all my windows (and desktop icons like "Computer" and mounted filesystems) move to the powered-off external monitor.
The arrangement is such that the external monitor becomes 0,0 on the screen (is it display or screen?) with the primary laptop screen to the right.
I could maybe understand moving windows when the external display is turned on, but why are they moving when it is off and the HDMI cable is plugged in?!

[brianread108]

This is also an issue for me on Fedora 32 with Cinnamon. Just changed my graphics card to Radeon 550, attached to two monitors by DVI and HDMI and this is occurring when I suspend the system and turn off the monitors (which I do a lot - anything from 5-10 times a day), all the windows are then concentrated on one of the screens (the designated "primary"), when I unsuspend. It did not happen with my previous graphics card (Radeon R7) connected by VGA and DVI to the monitors. I presume the new card is detecting the turn off and reporting back, causing Cinnamon/Mutter(?) to adjust the displays. I really "just" need some way of suppressing that activity in whatever is doing it! If someone could point me in the right direction I could have a look at the source, but I need some initial direction.

[bes1002t]

Same issue here with Fedora 31 and Cinnamon.

My setup is 2 QHD monitors connected via mini display port daisy chain

[mfroment]

I have this issue with Linux Mint 20 Cinnamon. 2 monitor setup, 1 HDMI FHD and 1 Asus VG27AQ connected via DP.
But I also have it with Windows 10 on the same setup.

My (crude) understanding is that in my case, the core issue is DP Hot Plug Detect related. When the Asus monitor goes to sleep, it also immediately goes into "deep sleep", from the PC point of view it's physically disconnected. It's unclear to me if there is a well defined behavior in the event the monitor is connected again, but in most instances (Cinnamon, Windows 10, etc) it appears that the behavior is to move windows to monitors which are still connected / first to reconnect, in my case the HDMI monitor, and not update position when the DP monitor reconnects (later).
There seems to be some debate whether it is an issue with window management, drivers, monitors, the DP standard, or a bit of all that. And because there is debate, there is also not much drive to address the problem as a bug by respective parties (nVidia is aware but it appears to be low priority, and this is for Windows drivers). DP experts please share your insight.

There seem to be a few recipes to work around this issue, with caveats.
On Windows, a program called Persistent Windows will restore windows positions after waiting enough time so that all screens have entirely waken up (it takes a few seconds before PC is usable, and there are occasional glitches in combination with full screen applications like games).
There are DP dongles that prevent the HDP disconnect event from triggering, but they have issues of their own (e.g. they break G-Sync).
Most successful workaround is to go to monitor settings, and disable DP Deep Sleep there - unfortunately many monitors do not have that option.

I'd be thankful if this can be addressed at Cinnamon level with something similar to Persistent Windows behavior.

[beedogs]

how has this bug, which has persisted across several versions of Mint, and which appears to be very frustratingly widespread, lingered for FOUR YEARS without even anyone being assigned to the issue?

Come on.

[janvlug]

See also:
https://gitlab.gnome.org/GNOME/mutter/-/issues/1419
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2092
https://bugs.launchpad.net/gnome-shell/+bug/1295267
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/380
https://bugzilla.redhat.com/show_bug.cgi?id=1878367

[cems2]

SOLVED?????? This may be the fix for at least a lot of this.

UPDATE: it's been three days now and this fix is still working. I think this is SOLVED
I tried the suggestion of @bitstrings above as so far it's working. At least through the first several suspend tests.
So far the following fixed the problem I was seeing.

I did this. Edit this file /etc/xdg/autostart/cinnamon-settings-daemon-xrandr.desktop
and alter the line
Exec=/usr/lib/cinnamon-settings-daemon/csd-xrandr
to
Exec=/usr/lib/cinnamon-settings-daemon/csd-xrandr --exit-time 1

I suspect that what may possibly matter here is that there are two things going on that happen at different times. I suspect that there is a sleep issue-- one monitor may turn off later than the other after video signal shuts off. And then there may be a wake time lag in the monitors responding to the video card. It may be that this command fixes the first of these. I wonder if there is a related command that might look like --enter-time 1 ???

@beedogs

[bes1002t]

@cem2 unfortunately setting "Exec=/usr/lib/cinnamon-settings-daemon/csd-xrandr --exit-time 1" will kill my session. If my screen goes to sleep, there is no way to wake it up again. I had to force poweroff my machine and boot again. After removing "--exit-time 1" screen wakeup works again as expected.

OS: Fedora 32

[franklx]

@cems2 your solution worked for me.
I'm running mint 20.1 beta (I had the same issue even on mint 20).

[franklx]

Before the csd-xrandr modification display sleep didn't work (I had to use xset dpms force off to force monitors enter sleep mode), now even this problem is fixed and sleep works as expected.
I don't know how these issues are related...

[FStefanni]

Hi,

I have the same issue, I am using Debian testing (bookworm).
I'll try the proposed workarounds, but it seems to me that the actual solution should be something "out of the box".
So I am not sure the proposed workaround is 100% correct: as @bes1002t wrote (but also the note by @franklx), it could lead to unexpected behaviors... I hope the cinnamon team will fix this issue asap.

Regards

[FeralBytes]

Seems that #5619 is related.

[HighOnVoltage]

@FStefanni
I can also confirm it's an issue with Debian (11) Bullseye

[FStefanni]

Hi,

yes, #5619 is related for sure. I still do not think that making a daemon to exit is good, since we are going to loose its functionalities...

Since it affects different versions of Debian, I am wondering if it is a cinnamon component bug, or of a third-party software.
For example, I am wondering if other DE have the same issue... If I'll try, I'll let you know.

Even if this is not a critical functionality bug, this is very annoying and haveily damages the usability and the user experience.

Regards

[FeralBytes]

From this issue: #5477
I found this script: https://github.com/dosmanak/wmsavior
I am going to give it a try and will report back, because currently this is really starting to annoy me. If a simple state script can solve the issue then it probably is what we should implement in cinnamon to fix it.
I just wonder does any one know off hand of a signal that would occur just prior to screen lock so the script can save?
Then we need a signal once the screens wake up, really when either wakes up, then we can wait like 30 seconds or a configurable amount to restore the window positions.

Also of note this is an issue for my System but not my wife's. We both run Linux Mint Cinnamon 20.3 x64 with all updates. But my system has a AMD GPU 5700XT, and she has a Nvidia 2070 Super. Both of us have she same monitors, Sceptre Monitors.

Update: the wmsavior script did not work.

[FeralBytes]

Adding "--exit-time=5" to xrandr in the startup applications seems to have fixed the issue for now.

[brianread108]

I did this. Edit this file /etc/xdg/autostart/cinnamon-settings-daemon-xrandr.desktop and alter the line Exec=/usr/lib/cinnamon-settings-daemon/csd-xrandr to Exec=/usr/lib/cinnamon-settings-daemon/csd-xrandr --exit-time 1
@beedogs

I am afraid this no longer works for Fedora 37, it has worked consistently for 34,35 and 36, but the "/etc/xdg/autostart/cinnamon-settings-daemon-xrandr.desktop" file no longer exists.

anyone got any ideas?

I've been unable to find another instance of the xrandr program being run.

[brianread108]

Update on my problem 'with Fedora 37. Actually the problem seem to be now that tasks left on the 2nd Workspace end up on the 1st workspace after a suspend. This may well be a seperate bug?