[Bug 55074] New: Multiple apps fail to show anything after launch (Steam, Ubisoft Connect)
https://bugs.winehq.org/show_bug.cgi?id=55074
Bug ID: 55074 Summary: Multiple apps fail to show anything after launch (Steam, Ubisoft Connect) Product: Wine Version: 8.10 Hardware: x86-64 OS: Linux Status: NEW Keywords: regression Severity: normal Priority: P2 Component: win32u Assignee: wine-bugs@winehq.org Reporter: andrey.goosev@gmail.com Regression SHA1: c2c9112bf8896d49a6af1ca1f73e563c5a7f909c Distribution: ---
Just zombie process. Coming to previous commit makes them work again.
https://bugs.winehq.org/show_bug.cgi?id=55074
--- Comment #1 from Rafał Mużyło galtgendo@o2.pl --- Are you sure it's 'zombie processes' and not 'windows not shown on screen' ?
Does - for example - something like 'xwininfo -root -children' still list the windows as present ?
https://bugs.winehq.org/show_bug.cgi?id=55074
--- Comment #2 from Andrey Gusev andrey.goosev@gmail.com --- steam.exe process lives for ~20 seconds after launching then silently closes itself. During this behaviour a virtual desktop shows nothing and stay opened.
https://bugs.winehq.org/show_bug.cgi?id=55074
--- Comment #3 from Rafał Mużyło galtgendo@o2.pl --- 'xwininfo -root -children' would show even invisible windows.
Does 'xrandr,system' show anything of interest ?
https://bugs.winehq.org/show_bug.cgi?id=55074
Tatsuyuki Ishi ishitatsuyuki@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ishitatsuyuki@gmail.com
--- Comment #4 from Tatsuyuki Ishi ishitatsuyuki@gmail.com --- The following patch should fix a segfault on Unix side, but sometimes there still seem to be a case where the window is positioned at top left and hardware acceleration is disabled. I'll see if I can root cause that one.
diff --git a/dlls/win32u/sysparams.c b/dlls/win32u/sysparams.c index 4f69cac7040..7498203bf53 100644 --- a/dlls/win32u/sysparams.c +++ b/dlls/win32u/sysparams.c @@ -2335,6 +2339,9 @@ LONG WINAPI NtUserQueryDisplayConfig( UINT32 flags, UINT32 *paths_count, DISPLAY if (!(monitor->dev.state_flags & DISPLAY_DEVICE_ACTIVE)) continue;
+ if (!monitor->adapter) + continue; + adapter_index = monitor->adapter->id; gpu_luid = &monitor->adapter->gpu_luid; output_id = monitor->output_id;
https://bugs.winehq.org/show_bug.cgi?id=55074
--- Comment #5 from Rafał Mużyło galtgendo@o2.pl --- (In reply to Tatsuyuki Ishi from comment #4)
Sorry to bother you, but could you also look into bug 53910 ?
It's only marginally related through its *main* topic (many of my bugs tend to be ranty and digressy), but it hasn't seen any dev input since its filing even though it's trivially reproducible (though it may depend on the monitor setup).
https://bugs.winehq.org/show_bug.cgi?id=55074
Tatsuyuki Ishi ishitatsuyuki@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jacek@codeweavers.com, | |rbernon@codeweavers.com, | |zzhang@codeweavers.com
--- Comment #6 from Tatsuyuki Ishi ishitatsuyuki@gmail.com --- To quickly describe what's triggering a edge case, Chromium temporarily switches to an non-interactive winstation to create an "alt" desktop [1], which causes the current win32u code to return the virtual monitor.
There are tests for 1. Virtual display config for non-interactive services, 2. Testing that EnumDisplayDevices count doesn't change even if winstation is manually set, however 2. only tests the count and seems ineffective as returning either the normal display config (for single-display user) and virtual display config would result in the same count=1.
Jacek, Zhiyi, do you know if the non-interactive winstation check applies to manual SetProcessWindowStation calls? Looking at 2., it probably shouldn't, which means that our interactiveness test likely needs to be done in another way that isn't affected by app SetProcessWindowStation calls.
[1]: https://source.chromium.org/chromium/chromium/src/+/main:sandbox/win/src/win...
https://bugs.winehq.org/show_bug.cgi?id=55074
--- Comment #7 from Zhiyi Zhang zzhang@codeweavers.com --- Doesn't the Chromium code restore the process window station after creating a desktop?
https://bugs.winehq.org/show_bug.cgi?id=55074
--- Comment #8 from Tatsuyuki Ishi ishitatsuyuki@gmail.com --- It does, but it's racy. A display query may happen on another thread during the temporary winstation switch, and the race is somewhat reproducible with the PE Steam test case.
https://bugs.winehq.org/show_bug.cgi?id=55074
--- Comment #9 from Andrey Gusev andrey.goosev@gmail.com --- (In reply to Tatsuyuki Ishi from comment #4)
Still the same behaviour.
https://bugs.winehq.org/show_bug.cgi?id=55074
--- Comment #10 from Tatsuyuki Ishi ishitatsuyuki@gmail.com --- (In reply to Andrey Gusev from comment #9)
(In reply to Tatsuyuki Ishi from comment #4)
Still the same behaviour.
Well, at least it fully fixes black window and hangs on my end (there are still positioning / hwaccel issue I mentioned in another comment). Might be worth double checking you built / install the correct tree.
https://bugs.winehq.org/show_bug.cgi?id=55074
--- Comment #11 from Andrey Gusev andrey.goosev@gmail.com --- I mentioned in comment 2 that a virtual desktop is in use.
https://bugs.winehq.org/show_bug.cgi?id=55074
--- Comment #12 from Tatsuyuki Ishi ishitatsuyuki@gmail.com --- OK, looks like there's a (consistent) deadlock that only happens when using virtual desktop.
https://bugs.winehq.org/show_bug.cgi?id=55074
--- Comment #13 from Andrey Gusev andrey.goosev@gmail.com --- Works with
if (is_virtual_desktop()) continue;
https://bugs.winehq.org/show_bug.cgi?id=55074
--- Comment #14 from Zhiyi Zhang zzhang@codeweavers.com --- Created attachment 74663 --> https://bugs.winehq.org/attachment.cgi?id=74663 1/3
https://bugs.winehq.org/show_bug.cgi?id=55074
--- Comment #15 from Zhiyi Zhang zzhang@codeweavers.com --- Created attachment 74664 --> https://bugs.winehq.org/attachment.cgi?id=74664 2/3
https://bugs.winehq.org/show_bug.cgi?id=55074
--- Comment #16 from Zhiyi Zhang zzhang@codeweavers.com --- Created attachment 74665 --> https://bugs.winehq.org/attachment.cgi?id=74665 3/3
Please test these three patches and see if they fix the issue for you. They are for Chromium sandboxes, which I think all these applications internally use.
https://bugs.winehq.org/show_bug.cgi?id=55074
Zhiyi Zhang zzhang@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|wine-bugs@winehq.org |zzhang@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=55074
--- Comment #17 from Andrey Gusev andrey.goosev@gmail.com --- (In reply to Zhiyi Zhang from comment #16)
Please test these three patches and see if they fix the issue for you. They are for Chromium sandboxes, which I think all these applications internally use.
No, they don't.
https://bugs.winehq.org/show_bug.cgi?id=55074
--- Comment #18 from Tatsuyuki Ishi ishitatsuyuki@gmail.com --- Andrey, this patch fixes the issue that happens when *not* using the virtual desktop.
https://bugs.winehq.org/show_bug.cgi?id=55074
--- Comment #19 from Andrey Gusev andrey.goosev@gmail.com --- (In reply to Tatsuyuki Ishi from comment #18)
Andrey, this patch fixes the issue that happens when *not* using the virtual desktop.
When the virtual desktop is disabled the apps work for me even without patches.
https://bugs.winehq.org/show_bug.cgi?id=55074
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick@piezo-forte.be Summary|Multiple apps fail to show |Multiple apps fail to show |anything after launch |anything after launch in |(Steam, Ubisoft Connect) |virtual desktop mode | |(Steam, Ubisoft Connect)
https://bugs.winehq.org/show_bug.cgi?id=55074
--- Comment #20 from Tatsuyuki Ishi ishitatsuyuki@gmail.com --- https://gitlab.winehq.org/wine/wine/-/merge_requests/3120 fixes the virtual desktop path, FYI.
https://bugs.winehq.org/show_bug.cgi?id=55074
--- Comment #21 from Tatsuyuki Ishi ishitatsuyuki@gmail.com --- Zhiyi, I can confirm the patches work for the non-virtual desktop case of PE Steam.
As a nitpick, you might want to apply the new winstation name logic to the nodrv branch of load_driver as well.
https://bugs.winehq.org/show_bug.cgi?id=55074
--- Comment #22 from Zhiyi Zhang zzhang@codeweavers.com --- (In reply to Tatsuyuki Ishi from comment #21)
Zhiyi, I can confirm the patches work for the non-virtual desktop case of PE Steam.
As a nitpick, you might want to apply the new winstation name logic to the nodrv branch of load_driver as well.
Nice catch, I will do that.
https://bugs.winehq.org/show_bug.cgi?id=55074
Andrey Gusev andrey.goosev@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |9b7669592d6f8b40976b571b70f | |8543777d35167 Status|NEW |RESOLVED
--- Comment #23 from Andrey Gusev andrey.goosev@gmail.com --- Fixed by https://source.winehq.org/git/wine.git/commit/9b7669592d6f8b40976b571b70f854...
https://bugs.winehq.org/show_bug.cgi?id=55074
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #24 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 8.11.
https://bugs.winehq.org/show_bug.cgi?id=55074
Zhiyi Zhang zzhang@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Assignee|zzhang@codeweavers.com |wine-bugs@winehq.org
https://bugs.winehq.org/show_bug.cgi?id=55074
--- Comment #25 from Zhiyi Zhang zzhang@codeweavers.com --- (In reply to Tatsuyuki Ishi from comment #21)
Zhiyi, I can confirm the patches work for the non-virtual desktop case of PE Steam.
As a nitpick, you might want to apply the new winstation name logic to the nodrv branch of load_driver as well.
In load_driver(), the nodrv branch is there so that applications can create windows even if the graphics driver fails to load. I don't think it's related to services.
https://bugs.winehq.org/show_bug.cgi?id=55074
--- Comment #26 from Tatsuyuki Ishi ishitatsuyuki@gmail.com --- (In reply to Zhiyi Zhang from comment #25)
In load_driver(), the nodrv branch is there so that applications can create windows even if the graphics driver fails to load. I don't think it's related to services.
It's a workaround to allow services to create an (invisible) window even when no driver is available. For normal processes it will error out and also print an error log.
-
WineHQ Bugzilla