Adrenaline 21.3.1 does not resolve the issue. When the monitor wakes up from deep sleep it is still locked to 1280x800 for me and has to be turned off and back on.
For now your only option is to turn this setting off and just power down the monitor when you walk away or move to HDMI, they are the only fixes that work right now on my LG 34GK950F
I should have found this thread earlier. Same screen (LG 34GK950F), same issue for months. It was finally acknowledged as a known issue in 21.3.1, so it seems they are looking into it. But in 21.3.2 it's listed as "fixed", and I can confirm it's not, unfortunately. I made another bug report for it and I hope they look at this thread, too.
I am sending a bug report with each driver update. I was hoping our issue was that:
On a limited number of displays, the preferred desktop resolution in Windows® may change when the display is power cycled.
but it was apparently not. Really getting stressed.
I wouldn't stress over it, just change the way you use it and turn the monitor off when you walk away. Problem solved.
A slight update. Recently I was given a Mac Book pro from work and used it for 2 weeks, the monitor sleeps perfectly. I have even tried it on Display Port. Same on my Linux laptop with AMD drivers in there, the monitor sleeps fine.
My theory is that something has changed in Windows 10, which is why certain drivers work! Then the drivers are built going forward and new windows 10 updates causing the issue. I can replicate this all the time on WIndows with display port, so a WIndows 10 timing issue, wake issue and also the panel at play.
The Mac I have on HDMI mainly so I can keep my gaming machine plugged in without faffing on with cables and it just works, but as I said, the Pro has a AMD GPU in it and on usb c to displayport it works fine, no sleep issue and the same for the linux laptop.
I really do think this is a WIndows 10 issue and Panel, I can find reports all over for other monitors makes and models doing the same with display port IPS panels. I know the likes of Dell etc use LG panels but I have seen Iiyama, AOC listed as issues with sleep/wake also.
Nice theory, but doesn't explain what is happening in practice. People have reported that reverting the driver to 20.9.x or so fixes the issue for them. So that indicates that something is wrong in the driver. I first reported it on 20.11.2 and included in the report that 20.10.1 was partially affected as well, though the resolution change wasn't persistent and consistently reproducible, only all of my windows got resized and moved in about 10% of the times where I woke the screen. Unfortunately, that and previous drivers were not an option for me anymore as they caused bluescreens upon waking my PC from standby (and some other problems), so I can't exactly trace back to when it happened (nor is that useful for me). The fact that they seem to acknowledge this problem is also a good indicator that it actually is the driver causing it.
And with regards to things changing in Windows: I have upgraded from 1909 to 20H2 two days ago while I have had the problem for months already. Nothing changed in that regard, and nothing significant has changed leading up to the manifestation of the problem. In that light, you'd expect Nvidia users to report similar problems, but the threads I can find on this issue are AMD-only.
Both Mac and Linux are different systems with different drivers, sharing none of the codebase for the OS-specific parts so a power-related problem in one isn't necessarily going to manifest itself in another. Other screens and screen vendors experiencing the same issue says nothing about whether the problem is driver- or OS-related if there are no other factors (e.g. GPU vendor) excluding the possibility of the display driver being at fault. And at the moment, there are none, or I haven't found them.
As for not stressing over it, I use my computer for more than just gaming or a single window. It is for productivity/work things as well, and I regularly have over 15 windows open (that's part of why I have an ultrawide screen). Coming back to my machine after a planned or unplanned break (in both moment and duration) I expect it to be in the state I left it in or configured it to be in, and that is not with a different resolution and my workspace completely reordered. Working around the problem in whatever way makes the problem less likely to be reported consistently, which might give AMD the false impression that the issue was fixed. Clearly their testing and production machines do suffer from this problem so it won't be caught by their pre-release test suite and day-to-day experience.
I too bought an ultrawide for multi window like yourself.
The issue with this being a driver issue is if it was we'd all have the same issue on the same driver!
I originally had it working on 20.9.1, you are 20.10.x others said 20.11.x so we can get it working on differing drivers. If it was a driver issue then I am sure we'd be working in the same driver and then failing on the next or have slight weirdness but if you swap your cable to HDMI it all goes away, so it's linked to display port, tried the usual of certified cables, refresh rates etc, even using LG Drivers instead of built in Windows ones, just happens on display port.
The Nvidia issue is the original LG community link I posted, the one posted recently is a new thread where we could all put our issues down.
Looking at the LG reply they are wiping their hands of it, it seems they are not interested.
I can replicate this issue all the time if I do sleep mode for the monitor only, my PC never sleeps. Interestingly, if I turn the monitor off and come back (intended or unintended break, I had to change my process as powering the monitor on and off just to get the res back was wasting more time) I do not get the res issue but like yourself my windows will resize, more interestingly on those I have snapped to the left side of the screen!
I caught this on video too with using a screensaver instead of sleep and the monitor makes everything go to top quarter of the screen.
I had this issue on my 144hz 24" dual Iiyama black eagles a few years back with an AMD R390x I got the 5700XT and they stopped doing it, then went ultrawide with the LG 34GK950F-B and it returned.
I have done driver cleanup and new install, I recently completely rebuilt my machine still there but now more interestingly is that the 20.9.1 driver that did work, now also displays the issue... Previously I was on Windows and upgraded through the versions, this is a clean build as if 4 days ago and now no driver works. This is where my guess came from about something in Windows, even upgrading holds onto older files or registry etc. Now I've clean built, no driver works, it does the issue on every driver I had from 20.8 - 21.3.1.
I hope there is a fix for it but we are half a year down, nothing sorts it, I raised it with MS as a bug and heard nothing either. I'd love a fix but our options are either go to HDMI and use the panel at 85Hz and forego the display port and 144hz or wait for a fix that might never come
I think a few have confirmed that HDMI seems to work.
I borrowed a LG 38GN850 from work and the monitor works and sleeps fine on any driver which is why I'm thinking windows/panel issues here.
The issue we have is we don't know if AMD are even reading this or looking at the bug reports as I raise this too with every release, I am guessing we are a niche corner of the market with a very specific monitor.
The last driver that works for me is 20.11.1 (tested it yesterday again). And I can confirm the issue does not occur if my monitor is connected via HDMI, however then I am stuck at 85Hz.
I'm having some trouble following your line of reasoning GreyMata. It seems you're overcomplicating things when they are really simple, as pointed out by vidko below your post, reverting to some earlier driver fixes the problem, that means the only difference is the driver and that is also the place where the behaviour can be changed to fix the problem in newer versions too. If it were actually a Windows problem, there would be one or more similar (and active) threads on the Nvidia side and reverting the driver wouldn't work, since the act of doing that does not change Windows.
I have looked through the thread for the Nvidia issue you talked about, but in that case the screen isn't even turning on at all. While it does reinforce the idea that the screen is either more strict or less compliant and it's on the power side of things, the issue itself seems different, at least for me because the screen turns on, just at 1280x800. It is similar though, might very well be the same thing, but Nvidia probably have fixed it, otherwise there would probably be an active thread on it with many Nvidia users replying.
It's not always black and white that we need to see the exact same symptoms with the same driver versions because a lot of our other hardware is different too, and issues like this usually do not have to have a clear and simple, one and singular, defined path to work up to it, it can be an interaction between different pieces of code. Power state changing code usually consists of a lot of different parts in some order with some defined timing in between that needs to be accurate. Even the BIOS could be a factor. One of the reasons why I can't easily go back to earlier drivers that don't have this problem for me is that they have other bugs that have since been fixed and are show-stoppers for me. One of them is a fairly high chance of a bluescreen when waking my PC from standby, and the trace shows the problem being in the AMD driver trying to change powerstates for my GPU. This happened after upgrading my CPU and BIOS to support it, so nothing in Windows or the drivers changed but the bug started to manifest itself and was subsequently fixed in a later driver. Even if you did a fresh install of Windows you might be running other things at different versions (e.g. BIOS) that are now consistently triggering this bug.
The simple act of fixing that bug A could have inadvertently introduced (just speculating here, just an example) a timing issue B or something similar that is not an issue on most screens but manifests itself in this way on this specific screen. It might very well be that there are more configurations that can cause A to occur but hadn't been discovered yet when the initial fix was made, so fixing the same bug for those other setups will require a new driver version. Now you could be in a situation where the same issue manifests itself on different driver versions on different configurations, while it does not exclude the driver from being at fault (because I have just defined it to be).
It does seem that the LG 34GK950F has some issue where it's not 100% standards-compliant or just behaves differently from what is expected, since it's reported a lot in this thread as being affected. It could easily be the other way around, that the AMD drivers/hardware are not 100% compliant but this screen is more strict about it. We can't really know unfortunately. But LG said they aren't going to do anything about it and are probably rightfully pointing to AMD when they have other drivers that do not exhibit the issue.
Turning off your screen does indeed, in most cases, move and resize all your windows. That's been an issue I've had ranging back all the way to 2011 and Win7 when I first started using DisplayPort. That does seem to be a Windows issue. In the old days of VGA and DVI, you'd set a resolution and there was little or no communication between the screen and the OS. The bit that was there (DCC/EDID) was passive AFAIK, so didn't require the screen to be on. Now with DP (not with HDMI AFAIK), the screen turning off is actually communicated to the host device/OS and can be observed by the "hardware disconnected" sound that's played. In that case, there is no screen to have windows on so Windows uses a virtual one which, coincidentally, is 1280x800 I believe. It'll move all your windows there and they are made to fit. When you turn the screen back on, it reconnects and the windows keep their new positions and sizes. I think a slight attempt is made at restoring the original positions but it's a far cry from being perfect. While I can sort of understand why they did this, I do consider this a bug in Windows and maybe even in the standards which they, unfortunately, still haven't addressed yet.
This is also why I think it's a timing/race thing that could be addressed by AMD, probably by waiting a bit longer for the screen to connect upon wake before telling Windows the display is gone. It then seems to proceed screwing up several things to give us the actual wrong resolution on the screen and no option to set it without actually "reconnecting" the display while the GPU is active.
I think, and I hope, that what they wrote in the change log actually is the issue we're experiencing and that they're working on a proper fix.
I fully agree with you and what you are saying.
The only reason I was leaning towards panel/firmware is that the issue happens on the 34GK950F-B and no matter how much I try it I can't get a solution to work.
If I use the 38GN950 from work (gutted I couldn't keep hold if it), it works flawlessly, no issue at all leading me to the panel/firmware of the 34" version. Only major difference on these montors the 34 is Freesync and I believe the 38GN is G-Sync, I need to look into it further. As you say, it could be a timing thing and I wonder if the G Sync monitors wait a littel longer or poll for the res before firing up. I might be tempted to sell the 34" and see if I can trade it or sell and put money towards the 38. Wish I had access to the Samsung 49" to see what happens on that screen.
Here's hoping there is something that can be done on the driver side with AMD as I don't think LG or MS will do a single thing about it