https://bugs.winehq.org/show_bug.cgi?id=53910
Bug ID: 53910 Summary: windows get moved around when dpms blankout happens Product: Wine Version: 7.20 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs@winehq.org Reporter: galtgendo@o2.pl Distribution: ---
Technically, it's a regression, but not sufficiently significant (for me) to check when it began - I initially thought it was something even more random.
Anyway, as the summary says, relatively recently (I'd say within last two months, perhaps less) I've noticed than under some at the time unclear condition, some of the windows get randomly moved around their respective desktops without any of my interaction.
For the most part it was only slightly annoying and seemingly random, so I've just lived with it.
But today I had an idea and successfully tested it.
All that's needed was 'xset dpms force off'. It's also quite generic - can be triggered with notepad and winecfg.
My setup is of two monitors, but one of them is quite old and most of the time turned off (that still allows for stumbling upon various quirks of winex11.drv's multi-screen handling).
Once 'xset dpms force off' is fully in effect, upon restoring from the blankout the windows get somewhat randomly moved.
https://bugs.winehq.org/show_bug.cgi?id=53910
--- Comment #1 from Rafał Mużyło galtgendo@o2.pl --- Also, some windows (but this looks app-specific) turn invisible from that test.
By 'invisible' I mean exactly that - mouse cursor changes upon entering the window area, but the window itself isn't drawn on the screen.
xwininfo reports: 'Map State: IsViewable'.
https://bugs.winehq.org/show_bug.cgi?id=53910
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
--- Comment #2 from Rafał Mużyło galtgendo@o2.pl --- ...oh, minor correction: now that I think about it, the regression might have been quite a bit older - for quite awhile vivaldi suffered from a chrome bug that prevented dpms blankouts, so the actual timeframe for this bug might actually reach as far as May (or even February) of this year.
https://bugs.winehq.org/show_bug.cgi?id=53910
--- Comment #3 from Rafał Mużyło galtgendo@o2.pl --- Something interesting to add:
I've just seen an interesting reaction to a dpms cycle in a game written for an engine based on node-webkit, one that may hold a part of the answer of those 'invisible' windows (which stopped being 'invisible' awhile be rc cycle (IIRC), but still every now and then crash if moved after such dpms cycle).
What happened was that:
- after the cycle the window was partially moved off-screen (pretty standard)
- after it was moved fully in, initially its content was drawn incorrectly in a very specific way: the strip that was off-screen was black, but its content was wrapped around inside the game window (that is when the window went outside the right edge of the screen during dpms cycle, when it was moved back, that vertical strip was drawn from the *left* edge of the game window)
- after the window lost and regained focus (the game constantly needs that to show its internal confirmation dialogs - most likely a wine bug) it was redrawn correctly
Such display glitch combined with the crashes may suggest that during such dpms cycle windows become desync'd with their gl contexts (and crashes are due to access to unallocated memory or something alike)...
https://bugs.winehq.org/show_bug.cgi?id=53910
--- Comment #4 from Rafał Mużyło galtgendo@o2.pl --- There one other bit, something that happens only with dnSpy 6.1.8 (6.2.0 hangs when I try to run it).
It doesn't happen every time, but every once in awhile after the restore the app has either internal or a full crash if its window is moved.
The internal one is where it goes into RtlpWaitForCriticalSection 60s cycle and stops responding.
There's a couple of interesting lines in the console output...
0158:err:d3d:wined3d_fence_test glClientWaitSync returned 0. malloc(): unsorted double linked list corrupted
...that doesn't look good, the last one looks like coming from glibc...
(there's nothing else in the console, besides the two other lines that spammed throughout a normal run: 066c:fixme:ntdll:RtlGetCurrentProcessorNumberEx (06AFF9CC) :semi-stub 066c:fixme:thread:NtQueryInformationThread ThreadIsIoPending info class not supported yet )
https://bugs.winehq.org/show_bug.cgi?id=53910
--- Comment #5 from Rafał Mużyło galtgendo@o2.pl --- OK, so minor updates aside (bug 54769), I'll add a line from xwininfo from a situation when the window has been moved (through the blankouts) completely offscreen:
0x6a00007 "dnSpy v6.3.0 (32-bit, .NET, Administrator)": ("dnspy.exe" "dnspy.exe") 1300x738+0+0 +-1170+273
The relevant part of 'xrandr -q': HDMI-A-0 connected primary 1920x1080+0+0 DVI-D-0 connected 1280x1024+1920+0
https://bugs.winehq.org/show_bug.cgi?id=53910
--- Comment #6 from Rafał Mużyło galtgendo@o2.pl --- Created attachment 74468 --> https://bugs.winehq.org/attachment.cgi?id=74468 reduce flickering
Another minor update.
wrt dnSpy:
- crashes after restore have at some point become rarer, perhaps they're actually fixed ?
- I've decided to investigate a line in the console spew after restore and it *seems* I've accidentally stumbled upon a fix to an unrelated problem. dnSpy tends to flicker badly upon moving the window or scrolling. But after I've made a semi-obvious change to a block of over 13 years old code block (wined3d_context_gl_update_window), the flickering *seems* to go away. I leave to to you to decide whether or not is this a proper solution.
https://bugs.winehq.org/show_bug.cgi?id=53910
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=53910
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |matteo.mystral@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=53910
--- Comment #7 from Rafał Mużyło galtgendo@o2.pl --- OK, time to ask directly.
Mystral, you may no longer recall it, but the patch in comment 6 refers to your 77face22d5365d94b9bfe61. Would you take a look ?
https://bugs.winehq.org/show_bug.cgi?id=53910
--- Comment #8 from Rafał Mużyło galtgendo@o2.pl --- ...well, minor correction, the flickering still happens, it's just significantly more rare...
https://bugs.winehq.org/show_bug.cgi?id=53910
Stefan Dösinger stefan@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan@codeweavers.com
--- Comment #9 from Stefan Dösinger stefan@codeweavers.com --- Is one of your monitors fake-unplugging (EDID chip powers down, GPU thinks monitor is disconnected) when it goes into standby? This would result in a desktop layout change, and some component (Wine, the window manager, the apps themselves) might reposition themselves based on that.
https://bugs.winehq.org/show_bug.cgi?id=53910
--- Comment #10 from Rafał Mużyło galtgendo@o2.pl --- Going by the content of xorg log, one of the monitors (the much older one) might be acting that way. Its vendor got a bit creative with its EDID.
https://bugs.winehq.org/show_bug.cgi?id=53910
--- Comment #11 from Rafał Mużyło galtgendo@o2.pl --- An interesting inconsistency: if 'xrandr --off' is sent to that monitor, the messages in xorg log upon blankout/restore still happen, but the window is moved in a different direction.
So wine is still reacting to changes of a monitor that but for the inactive connection doesn't exist yet still acts differently depending on whether the monitor connection is active or not.
While wine definitely *should* react to the monitor being activated/removed, once it's deactivated, shouldn't it just be ignored till it's reactivated ?
Also, if wine distinguishes whether the monitor is active or not, why is this bug even a thing ?
https://bugs.winehq.org/show_bug.cgi?id=53910
--- Comment #12 from Rafał Mużyło galtgendo@o2.pl --- Created attachment 74992 --> https://bugs.winehq.org/attachment.cgi?id=74992 'x11drv' debug log (running regedit)
Something is clearly happening here, though I don't really understand what. Also, there's lots of noise.
https://bugs.winehq.org/show_bug.cgi?id=53910
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|matteo.mystral@gmail.com |
https://bugs.winehq.org/show_bug.cgi?id=53910
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #13 from Zeb Figura z.figura12@gmail.com --- Please perform a bisect.
https://bugs.winehq.org/show_bug.cgi?id=53910
Rafał Mużyło galtgendo@o2.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon@codeweavers.com
--- Comment #14 from Rafał Mużyło galtgendo@o2.pl --- Recent changes to X11 events handling brought some odd changes.
It's still in a flux (initial changes had slightly different problems), but as of 9.22 it's as follows:
- windows *as seen* aren't moved or resized
- yet it seems internally windows do get resized; that is initially they were moved partially offscreen and the part that went offscreen became insensitive to mouse input, after later fixes, they aren't moved anymore, but that partial insensitivity remains; it can be fixed if I use xrandr to toggle that monitor off/on
So, to the author of those changes, any idea what happens here ?
https://bugs.winehq.org/show_bug.cgi?id=53910
--- Comment #15 from Rémi Bernon rbernon@codeweavers.com --- Could you attach a log with WINEDEBUG=+pid,+tid,+timestamp,+system,+explorer,+msg,+win,+x11drv,+cursor,+event,+xrandr,+xvidmode with this happening, and including the moment it gets fixed with xrandr?
https://bugs.winehq.org/show_bug.cgi?id=53910
--- Comment #16 from Rafał Mużyło galtgendo@o2.pl --- Well, it's a bit tricky, as 'xset dpms force off' no longer triggers this in 100% of the cases (and I've yet to figure out what differs when it does).
I'm seeing an odd behavior that might give an additional clue: in Unnamed Space Idle (f2p Godot engine game), once the bug hits, a vertical strip on the right side of the game window is cut off from mouse input; I can resize the game window and if I make it small enough (as the interface scales), the elements that were within that vertical strip become accessible, but if I stretch the window back, the strip is still insensitive; also something odd happens upon using 'Reset Window Size' option in the settings while in the buggy state: the window content that should fill the whole window gets letterboxed instead (two horizontal black strips in the window) (no, that interface reset doesn't fix the problem).
I'll write back once I've either figured out how to trigger this manually or that I need to wait until it triggers on its own.
-
WineHQ Bugzilla