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.
https://bugs.winehq.org/show_bug.cgi?id=53910
--- Comment #17 from Rafał Mużyło galtgendo@o2.pl --- So, sorry for the delay and no, I don't have a log yet - the changes have turned this from something that triggers 100% of the time to a near-heisenbug.
Yet I've just observed the bug (still with 9.22, don't have latest fixes yet) and did something trivial, yet that still didn't occur to me to try it before.
Namely, I moved the window.
Silly, ain't it ?
So, if I move the window that's had been on the primary monitor (which is leftmost) (and got affected by the bug) somewhat to the left, I regain the mouse access to the seemingly affected part of the window.
So it seems, it's not the game window that's affected, but the internal desktop size tracking/caching. Somehow the flaky behavior of the secondary monitor during the shutdown triggers a race (now, likely before it wasn't a race, but something consistent) on shutdown that *sometimes* makes wine cache the size of the desktop wrongly (without that secondary monitor perhaps (don't know how to check the current size in wine; btw, that was a question)), but doesn't restore proper size when the monitor awakes.
Oh, and now for funsies, I've tried to move the 'affected' widow to the secondary monitor - it completely disappeared both from the monitor *and* the window list (remember, still on 9.22)...
Let's see if I can restore it by xrandr or wmctrl...
(side note: xwininfo sees the window:
Absolute upper-left X: 1996 Absolute upper-left Y: 91 Relative upper-left X: 1996 Relative upper-left Y: 91 Width: 1600 Height: 900 Depth: 24 Visual: 0x21 Visual Class: TrueColor Border width: 0 Class: InputOutput Colormap: 0x5e00001 (not installed) Bit Gravity State: NorthWestGravity Window Gravity State: NorthWestGravity Backing Store State: NotUseful Save Under State: no Map State: IsUnMapped Override Redirect State: no Corners: +1996+91 --396+91 --396-89 +1996-89 -geometry 1600x900+1996-89 )
...
'wmctrl -i R <ID>' restored the window on the secondary - it's fully accessible now, though wrongly sized...though game's internal window reset fixed that.
Interesting...
Your thoughts ?
https://bugs.winehq.org/show_bug.cgi?id=53910
--- Comment #18 from Rafał Mużyło galtgendo@o2.pl --- Note: I may have run xrandr during my attempts to restore the window, but without wmctrl, it wasn't enough to restore the window.
https://bugs.winehq.org/show_bug.cgi?id=53910
--- Comment #19 from Rafał Mużyło galtgendo@o2.pl --- OK, so I still don't know how to reliably trigger the problem, but it seems I have the recovery nailed down: minimize the affected windows, toggle the secondary (though likely primary would work too, but getting the other windows back in their proper place would take too long) off/on then restore the minimized windows.
So, it's some kind of caching problem with the desktop size (likely due to above mentioned flakiness of the secondary monitor's EDID)...
https://bugs.winehq.org/show_bug.cgi?id=53910
banana zardivorku@gufum.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zardivorku@gufum.com
--- Comment #20 from banana zardivorku@gufum.com --- (In reply to Rafał Mużyło from comment #17)
So, sorry for the delay and no, I don't have a log yet - the changes have turned this from something that triggers 100% of the time to a near-heisenbug.
Yet I've just observed the bug (still with 9.22, don't have latest fixes yet) and did something trivial, yet that still didn't occur to me to try it before.
Namely, I moved the window.
Silly, ain't it ?
absolute longshot but this may be related then
https://bugs.winehq.org/show_bug.cgi?id=56774
https://bugs.winehq.org/show_bug.cgi?id=53910
--- Comment #21 from banana zardivorku@gufum.com ---
also can one of the devs update this issue from normal to major
https://bugs.winehq.org/show_bug.cgi?id=53910
--- Comment #22 from Rafał Mużyło galtgendo@o2.pl --- ...so, I did some more window moving...
This problem seems to have become a *rare* race.
Now, the interesting thing seems to be the caching problem. That is sometimes, if rarely, as wine recovers from the blankout, some (all ?) of the wine windows decide they've been moved to a different monitor, despite not actually being moved at all. The more faulty part is that if that happens and I actually move such window to a different monitor, it decides it's been moved to the monitor I moved it from - I've only two monitors and they have significantly different sizes; this is what leads to the mouse problems...and what makes that awkward recovery procedure from comment 19 necessary - if wine wasn't caching, likely moving the window between monitors would suffice to reset...
Rémi, ideas ?
https://bugs.winehq.org/show_bug.cgi?id=53910
--- Comment #23 from Rafał Mużyło galtgendo@o2.pl --- ...all those years and I've never noticed.
Leaving a future note: I just found display settings applet in the wine's control panel; I've never really looked there before, only remembered that it had a input calibration applet and little else - while that's still true, the display settings applet might be able to test/confirm certain things once the bug triggers again. See you afterwards, if I'll remember this then.
https://bugs.winehq.org/show_bug.cgi?id=53910
--- Comment #24 from Rafał Mużyło galtgendo@o2.pl --- So, the race triggered again and the results were...odd.
First of all, a xwininfo/wmctrl dance was needed to make the applet window appear on screen, but that wasn't all that surprising.
What was, was what the applet displayed.
According to it, only one of my monitors was active and it was the DVI one, one with the flaky edid. And it was still labeled as DISPLAY2. The windows were obviously not moved from the monitor they were on - the primary.
Given that one is the smaller one, that 'explains' the odd mouse behavior. But given the one that survives is the one doing fake shutdown (which I believe to be a slower reaction...unless I'm wrong about that) makes me wonder...
I'll need to find the part of the source that handles this...
https://bugs.winehq.org/show_bug.cgi?id=53910
--- Comment #25 from Rafał Mużyło galtgendo@o2.pl --- Also a note (not sure if related or not): lately (measured in months) I've noticed something odd in random Unity games - upon being closed, even if they were running windowed, they remove the second monitor from xrandr list, that is x11 desktop (not just wine) goes from two active monitors to one.
Not sure when that began, as I've been ignoring it for quite awhile (happens only with Unity (AFAICT) and only on shutdown).
-
WineHQ Bugzilla