[Bug 53910] New: windows get moved around when dpms blankout happens
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(a)winehq.org Reporter: galtgendo(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53910 --- Comment #1 from Rafał Mużyło <galtgendo(a)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'. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53910 Rafał Mużyło <galtgendo(a)o2.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression --- Comment #2 from Rafał Mużyło <galtgendo(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53910 --- Comment #3 from Rafał Mużyło <galtgendo(a)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)... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53910 --- Comment #4 from Rafał Mużyło <galtgendo(a)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 ) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53910 --- Comment #5 from Rafał Mużyło <galtgendo(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53910 --- Comment #6 from Rafał Mużyło <galtgendo(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53910 Rafał Mużyło <galtgendo(a)o2.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53910 Rafał Mużyło <galtgendo(a)o2.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |matteo.mystral(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53910 --- Comment #7 from Rafał Mużyło <galtgendo(a)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 ? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53910 --- Comment #8 from Rafał Mużyło <galtgendo(a)o2.pl> --- ...well, minor correction, the flickering still happens, it's just significantly more rare... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53910 Stefan Dösinger <stefan(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stefan(a)codeweavers.com --- Comment #9 from Stefan Dösinger <stefan(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53910 --- Comment #10 from Rafał Mużyło <galtgendo(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53910 --- Comment #11 from Rafał Mużyło <galtgendo(a)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 ? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53910 --- Comment #12 from Rafał Mużyło <galtgendo(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53910 Matteo Bruni <matteo.mystral(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|matteo.mystral(a)gmail.com | -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53910 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #13 from Zeb Figura <z.figura12(a)gmail.com> --- Please perform a bisect. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53910 Rafał Mużyło <galtgendo(a)o2.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon(a)codeweavers.com --- Comment #14 from Rafał Mużyło <galtgendo(a)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 ? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53910 --- Comment #15 from Rémi Bernon <rbernon(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53910 --- Comment #16 from Rafał Mużyło <galtgendo(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53910 --- Comment #17 from Rafał Mużyło <galtgendo(a)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 ? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53910 --- Comment #18 from Rafał Mużyło <galtgendo(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53910 --- Comment #19 from Rafał Mużyło <galtgendo(a)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)... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53910 banana <zardivorku(a)gufum.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |zardivorku(a)gufum.com --- Comment #20 from banana <zardivorku(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53910 --- Comment #21 from banana <zardivorku(a)gufum.com> ---
also can one of the devs update this issue from normal to major -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53910 --- Comment #22 from Rafał Mużyło <galtgendo(a)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 ? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53910 --- Comment #23 from Rafał Mużyło <galtgendo(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53910 --- Comment #24 from Rafał Mużyło <galtgendo(a)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... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53910 --- Comment #25 from Rafał Mużyło <galtgendo(a)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). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=53910 --- Comment #26 from Rafał Mużyło <galtgendo(a)o2.pl> --- The highly irregular update: the disappearing display bug still triggers in 10.10. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla