Powertoys: "Keep windows in their zones when the active FancyZones layout changes" or "Keep windows in their zones when the screen resolution changes" doesn't work properly anymore.

[WindowsTablet]

Environment

Windows build number: [Version 10.0.19041.388]
PowerToys version: v0.19.2
PowerToy module for which you are reporting the bug (if applicable): FancyZones

Steps to reproduce

Create a separate layout for landscape and portrait orientation on a Surface/Windows tablet, then snap a window in one of the zones, rotate the screen to portrait orientation, and back to landscape orientation.

Expected behavior

Windows should stay in their assigned zones, just like in the older v0.18.2 build.

Actual behavior

Windows don't stay in their assigned zones between portrait and landscape orientation changes.

[WindowsTablet]

This is a follow-up to this previous bug #4855

[enricogior]

@WindowsTablet
this seems specific of the Surface tablet since we can't reproduce it rotating an external monitor.
Can you confirm that this is working with 0.18.2?
Thanks.

[WindowsTablet]

@WindowsTablet
this seems specific of the Surface tablet since we can't reproduce it rotating an external monitor.
Can you confirm that this is working with 0.18.2?
Thanks.

Yes, this feature used to work properly since the beginning of PowerToys, up until 0.18.2. I relied heavily on this feature.

[enricogior]

Thanks for confirming it.

[WindowsTablet]

Is there any news on this issue?

[CorneliousJD]

Is this sitll not currently fixed with the 0.20 release? :(

[enricogior]

@CorneliousJD
what PC are you using, is it a Surface?
These features are working as expected beside some specific hardware configurations.

[CorneliousJD]

@CorneliousJD
what PC are you using, is it a Surface?
These features are working as expected beside some specific hardware configurations.

Nope just a Windows 10 desktop PC.
I'm using a super-ultrawide @5120x1440 along with another regular resolution screen attached as well.
When the ultrawide goes into sleep mode since it's DisplayPort the PC just assumes it's disconnected and when it gets hooked back up, windows do not open back to their last known zones, and instead open in the top left corner. -- With 0.18.x installed they would open back up to their correct zone assignmens.

[WindowsTablet]

This issue seems to be fixed in v0.20.1.

[enricogior]

@CorneliousJD
the problem you describe is different from the original issue, since in your case the windows are moved by Windows to the primary monitor or to the monitor top left corner because the monitor is detected as disconnected. It's not a FancyZone bug, it's a feature request to restore windows when a monitor is disconnected and reconnected, the feature request is tracked by https://github.com/microsoft/PowerToys/issues/4

[crutkas]

@WindowsTablet says this was resolved. @enricogior has it?

[enricogior]

@crutkas
we also haven't been able to reproduce it. If its still happening for someone else, it might be a driver/Windows issue that doesn't send the correct event to FZ, if that is the case, probably it's not fixable in FZ.
Closing for now,

[WindowsTablet]

v0.21.1 broke it again.

Can this be reopened?

[enricogior]

@WindowsTablet
we didn't make any change that could have broken this, I suspect that in your case it was never fixed, it just happened to work for some reason.
We need a way to repro this because we haven't been able to do so.

[markeman]

Having same symptoms with very similar use case as described by @CorneliousJD above.. super-ultrawide (Samsung CRG9) @ 5120x1440 via DisplayPort to desktop PC. I have a second DisplayPort cable plugged into monitor but it is not at any point connected to another PC.

FZ window snapping works as expected even after monitor goes to sleep and when user locks / unlocks Windows when DisplayPort connected to nVidia RTX 2080 Super output.

However, when DisplayPort is connected to motherboard video out, which uses IGD onboard Intel i7-9700K, FZ display symptoms where all window locations are reset to top left corner of screen.

Using PowerToys v0.21.1
Other system specs:

[crutkas]

However, when DisplayPort is connected to motherboard video out, which uses IGD onboard Intel i7-9700K, FZ display symptoms where all window locations are reset to top left corner of screen.

@markeman That is Windows bug with displayport, not FZ

[markeman]

@crutkas Thx for input. Why doesn't it affect DisplayPort when connected to the dedicated GPU? Is there an open Windows issue I can track?

[markeman]

@crutkas UPDATE - problem solved easily. What I can't explain is why the symptoms only occur using my integrated Intel UHD 630 graphics but not using my dedicated nVidia GPU given both via DisplayPort. Evidence online suggests this problem has been around for years, but then so has Intel IGD and Windows so seems crazy it's not been addressed.

Cause: Windows capturing a dummy GraphicsDriver entry in registry (inmy case 'NOEDID_8086..') configured with a low resolution 1080x768 each time my monitor goes into a sleep cycle. On monitor wake this is loaded and applied rather than the other 'live' entry which contains the correct resolution (5120x1440).

Solution: Follow instructions in links below to regedit Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers\Configuration dummy driver entry (in my case 'NOEDID_8086..') and set the correct resolution values.

Related links
https://www.tenforums.com/graphic-cards/10681-tutorial-how-change-windows-10-default-resolution.html
https://answers.microsoft.com/en-us/windows/forum/windows_7-hardware/windows-7-movesresizes-windows-on-monitor-power/1653aafb-848b-464a-8c69-1a68fbd106aa
https://superuser.com/questions/990398/setting-display-resolution-beyond-1024x768-with-headless-windows-10

[CorneliousJD]

Solution: Follow instructions in links below to regedit Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers\Configuration dummy driver entry (in my case 'NOEDID_8086..') and set the correct resolution values.

Related links
https://www.tenforums.com/graphic-cards/10681-tutorial-how-change-windows-10-default-resolution.html
https://answers.microsoft.com/en-us/windows/forum/windows_7-hardware/windows-7-movesresizes-windows-on-monitor-power/1653aafb-848b-464a-8c69-1a68fbd106aa
https://superuser.com/questions/990398/setting-display-resolution-beyond-1024x768-with-headless-windows-10

@markeman sadly part of the issue for me is I'm using a DP connection on a GTX 970 (I know it's an old card... still holding out hope for a RTX 3080).

I do NOT have any "Simulated" entries in that location in the registry.
I know we're getting a bit away from the initial topic but this would fix the problem and make it a non-issue for me but I've never had a simulated entry there at all, ever :(

[markeman]

Interesting.. you don't have a 'NOEDID..' entry either, perhaps your problem is different. If you expand each of those config entries and click on the '00' child node, do any have PrimSurfSize.cx/cy keys indicating a resolution lower than that of your UW monitor? If so, you could try and edit to match UW resolution in decimal value (obviously make a backup of registry first!).

Another potentially useful data point is the timestamp on each of the config nodes. I found majority of mine are months old with only a couple that have been edited recently. The dummy NOEDID entry was being touched every time the monitor went into sleep cycle. Use this to convert hex timestamp value to human readable - https://doubleblak.com/blogPosts.php?id=7#win64

[CorneliousJD]

Interesting.. you don't have a 'NOEDID..' entry either, perhaps your problem is different. If you expand each of those config entries and click on the '00' child node, do any have PrimSurfSize.cx/cy keys indicating a resolution lower than that of your UW monitor? If so, you could try and edit to match UW resolution in decimal value (obviously make a backup of registry first!).

Another potentially useful data point is the timestamp on each of the config nodes. I found majority of mine are months old with only a couple that have been edited recently. The dummy NOEDID entry was being touched every time the monitor went into sleep cycle. Use this to convert hex timestamp value to human readable - https://doubleblak.com/blogPosts.php?id=7#win64

Holy moly. @markeman THANK YOU!

I have at least "fixed" it in a sense.
While i have no Simulated or "NOEDID" entry, I was able to find one for my 2nd monitor alone (it's the shortest line in the screenshot) and using your link: https://doubleblak.com/blogPosts.php?id=7#win64 and entering timestamps as Big Endian I was able to find that one that was updated the last time my PC put my monitor to sleep and disconnected it. From there I was able to set the primary surace size on it to 5120x1440 (even though it's techincally a smaller resolution monitor as my secondary) however I NEVER use that monitor by itslef.

The result is that when my main display goes to sleep and disconnects, everything looks absolutely horrid on my 2nd monitor, but again I never use that by itself anyways, so the end result is when I power my main monitor back on, everything moves back exactly where it was without any fuss.

The only thing I have ot move is the one window I keep up on the second monitor, that moves itself back to the main for some reason but that's not a big deal at all. So much eaiser than moving 20 windows around!

[mykhailopylyp]

That functionality is broken for me as well. Windows do not match a zone while changing resolution. Tested it on v0.21.2.

Here's the video to reproduce it.
2020-09-24_19-43-19.zip

[enricogior]

@mykhailopylyp
it looks like you didn't have Keep windows in their zones when the screen resolution changes option on.

[enricogior]

@WindowsTablet
what type of layout are you using: grid or canvas?
Grid are the Columns, Rows, Grid and Priority templates (and any customization starting from one of them)
Canvas layout are any Focus or custom layout created from scratch.

The option to Keep windows in their zones when the screen resolution changes is supposed to work smoothly only for grid templates, since they are defined in terms of % if the screen and can adapt to the screen resolution changes.
Canvas layout may not work as expected because they are not properly scaled when resolution changes.

Can you please post a screenshots of:

• the layout you are using
• the windows position before changing resolution
• the windows position after changing resolution

When you change the layout but not the resolution, screenshots of:

• the layout you are using
• the windows position before changing layout
• the new layout you are using

[DrSebastianPauli]

Same here. I've a UHD Display (5120x1440). I've to layouts:

• Screen divided in three zones/columns of same size
• Priorty grid with three columns

Expected: If I change between both layouts, windows will resize

Reality: Nothing happens. In older versions it worked.

Here my configuration:

[enricogior]

@DrSebastianPauli

are you running 0.23.0?

Screen divided in three zones/columns of same size

Is this the default column template or a modified one?

Priorty grid with three columns

The default one or modified?

Can you please provide screenshots or even better use the Windows Steps Recorder to create a report?

[DrSebastianPauli]

Hi @enricogior

yes it is 0.23.0

Is this the default column template or a modified one?

I use custom grids

The default one or modified?

It is a custom grid

I also tried with the templates. Windows do not resize.

Here is the zip from the windows steps recorder
fancy_zones_steps.zip

[enricogior]

@DrSebastianPauli
what tool are you using for the custom taskbar? Ha you tried quitting it and verify if the FZ problem still persists?

[DrSebastianPauli]

I use CenterTaskbar.exe. There is no difference if it is started or not.

[DrSebastianPauli]

Hi @enricogior

after a system reboot with connected external display it finally works again. I think it maybe has to do with different screen resolutions on my Laptop and external display and connecting the display after reboot... I come back with new information, if I find out, how to reproduce the issue.

Sebastian

[enricogior]

@DrSebastianPauli
OK thanks for the update.

[msftbot[bot]]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 5 days. It will be closed if no further activity occurs within 5 days of this comment.