https://bugs.winehq.org/show_bug.cgi?id=57610
Bug ID: 57610 Summary: No windows are shown when using a dual monitor setup Product: Wine Version: 9.19 Hardware: x86-64 OS: Linux Status: NEW Keywords: download, regression Severity: normal Priority: P2 Component: win32u Assignee: wine-bugs@winehq.org Reporter: austinenglish@gmail.com Regression SHA1: 3cf0506ccae3551132a55d38d9efbde43e54e695 Distribution: Debian
3cf0506ccae3551132a55d38d9efbde43e54e695 is the first bad commit commit 3cf0506ccae3551132a55d38d9efbde43e54e695 Author: Rémi Bernon rbernon@codeweavers.com Date: Sun Sep 8 16:33:51 2024 +0200
win32u: Use the current display mode as monitor rect.
dlls/win32u/sysparams.c | 83 +++++++++++++++++++++++++++++++++++++++-------------------------------------------- 1 file changed, 39 insertions(+), 44 deletions(-)
After this commit, running ./wine notepad will start notepad, but no window is shown (the process is running, though).
The 'wineboot' updating the wineprefix dialog box is also not shown.
If I disable my second monitor the windows show as normal.
https://bugs.winehq.org/show_bug.cgi?id=57610
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=57610
--- Comment #1 from Rafał Mużyło galtgendo@o2.pl --- So, a semi-standard question: is the window not getting created or just not being made visible, i.e. does xprop/xwininfo list the window and if so, is wmctrl able to force it to show up ?
https://bugs.winehq.org/show_bug.cgi?id=57610
--- Comment #2 from Austin English austinenglish@gmail.com --- (In reply to Rafał Mużyło from comment #1)
So, a semi-standard question: is the window not getting created or just not being made visible, i.e. does xprop/xwininfo list the window and if so, is wmctrl able to force it to show up ?
I'm not very familiar with those tools..That said, xwinfo does list the window:
austin@debian:~$ xwininfo -tree -root | grep -i notepad 0x5a00001 "Untitled - Notepad": ("notepad.exe" "notepad.exe") 1018x735+1924+61 +1924+61 0x5a00003 (has no name): ("notepad.exe" "notepad.exe") 1x1+0+0 +0+0 0x5a00002 "Default IME": ("notepad.exe" "notepad.exe") 1x1+0+0 +0+0
I'm not sure how to use wmctrl. I tried a few things, but none of them made the window show: austin@debian:~$ wmctrl -a 0x5a00001 austin@debian:~$ wmctrl -a 0x5a00002 austin@debian:~$ wmctrl -a 0x5a00003 austin@debian:~$ wmctrl -a notepad.exe austin@debian:~$ wmctrl -a notepad austin@debian:~$ wmctrl -a "Untitled - Notepad"
https://bugs.winehq.org/show_bug.cgi?id=57610
--- Comment #3 from Rafał Mużyło galtgendo@o2.pl --- You probably want to start with something simple, like 'wmctrl -i -R <WID>'.
https://bugs.winehq.org/show_bug.cgi?id=57610
--- Comment #4 from Rafał Mużyło galtgendo@o2.pl --- Though the last line looks like it should have worked...
Also, as you identify the window, check it with 'xwininfo -id <wid>' before and after you put it through wmctrl, for comparison.
How do those window dimensions correspond to your monitor sizes ?
https://bugs.winehq.org/show_bug.cgi?id=57610
--- Comment #5 from Rémi Bernon rbernon@codeweavers.com --- Could you attach a log with WINEDEBUG=+timestamp,+pid,+loaddll,+system,+x11drv,+event,+win? I'm using a dual monitor setup every day and I don't experience any problem.
https://bugs.winehq.org/show_bug.cgi?id=57610
--- Comment #6 from Austin English austinenglish@gmail.com --- Created attachment 77743 --> https://bugs.winehq.org/attachment.cgi?id=77743 WINEDEBUG=+timestamp,+pid,+loaddll,+system,+x11drv,+event,+win
https://bugs.winehq.org/show_bug.cgi?id=57610
--- Comment #7 from Austin English austinenglish@gmail.com --- (In reply to Rémi Bernon from comment #5)
Could you attach a log with WINEDEBUG=+timestamp,+pid,+loaddll,+system,+x11drv,+event,+win?
Attached.
I'm using a dual monitor setup every day and I don't experience any problem.
I suspect it may be hardware/driver related. I'm using a laptop with a usb-c external monitor plugged into a usb-c hub.
To get it to work on debian, I had to install the displaylink driver from Synaptics (https://www.synaptics.com/products/displaylink-graphics/downloads/ubuntu).
https://bugs.winehq.org/show_bug.cgi?id=57610
--- Comment #8 from Rémi Bernon rbernon@codeweavers.com --- Created attachment 77744 --> https://bugs.winehq.org/attachment.cgi?id=77744 Possible fix
Thanks, if read the log correctly and according to the bisected change the issue is probably that the current display mode for the second monitor isn't positioned correctly (while its monitor rect is):
``` 84174.567:004c:0050:trace:system:add_monitor 0 (0,0)-(1920,1080) (0,31)-(1920,1080) 84174.568:004c:0050:trace:system:add_modes current 1920x1080 32bits 60Hz rotated 0 degrees unstretched non-interlaced at (0,0), modes_count 996, modes 0x555561d50c20, param 0x7ffffe0fe090 84174.572:004c:0050:trace:system:add_monitor 0 (1920,0)-(3840,1080) (1920,31)-(3840,1080) 84174.572:004c:0050:trace:system:add_modes current 1920x1080 32bits 60Hz rotated 0 degrees unstretched non-interlaced at (0,0), modes_count 996, modes 0x555561d50c20, param 0x7ffffe0fe090 ```
Could you check whether the attached patch helps?
https://bugs.winehq.org/show_bug.cgi?id=57610
--- Comment #9 from Austin English austinenglish@gmail.com --- Created attachment 77746 --> https://bugs.winehq.org/attachment.cgi?id=77746 WINEDEBUG=+timestamp,+pid,+loaddll,+system,+x11drv,+event,+win, with patch
Unfortunately that didn't help. I've attached another log with the patch applied (on wine-10.0-rc3).
https://bugs.winehq.org/show_bug.cgi?id=57610
--- Comment #10 from Rémi Bernon rbernon@codeweavers.com --- Hmm... looks like it's actually using XRandR 1.4, which I assumed was getting the position right. It's apparently not, and that may be some issue coming from XRandR configuration itself.
Could you paste what `xrandr` command outputs?
Also maybe adding +xrandr to WINEDEBUG channels could add useful information, in case we're doing something wrong in our xrandr enumeration.
We could probably decide to check whether display mode vs monitor rect differ, but I think they are supposed to match, and if they don't we can't really know whether we should trust monitor rects over display modes.
https://bugs.winehq.org/show_bug.cgi?id=57610
--- Comment #11 from Austin English austinenglish@gmail.com --- Created attachment 77748 --> https://bugs.winehq.org/attachment.cgi?id=77748 WINEDEBUG=+timestamp,+pid,+loaddll,+system,+x11drv,+event,+win,+xrandr
https://bugs.winehq.org/show_bug.cgi?id=57610
--- Comment #12 from Austin English austinenglish@gmail.com --- Created attachment 77749 --> https://bugs.winehq.org/attachment.cgi?id=77749 xrandr output
https://bugs.winehq.org/show_bug.cgi?id=57610
--- Comment #13 from Rémi Bernon rbernon@codeweavers.com --- Thank you! From the log it looks like there might some sort of hot-plugging that happens with one of the monitor.
These messages are being printed when the first monitor and its mode is enumerated:
158096.748:0050:0054:warn:xrandr:get_primary_rect Primary is set to a disconnected XRandR output.
But they stop being printed right before the second active monitor is enumerated:
158096.755:0050:0054:trace:x11drv:X11DRV_UpdateDisplayDevices adapter: 0xc9, monitor count: 1 158096.755:0050:0054:trace:system:add_monitor 0 (1920,0)-(3840,1080) (1920,31)-(3840,1080) 158096.758:0050:0054:trace:system:add_modes current 1920x1080 32bits 60Hz rotated 0 degrees unstretched non-interlaced at (0,0), modes_count 996, modes 0x55558214e740, param 0x7ffffe0fe090
My understanding is that the second monitor is the primary one, and it is seen as being disconnected at first, and the first one is used to compute the virtual screen origin which causes the first monitor modes to be located at 0x0.
When the second monitor is enumerated, and now actually detected as the primary monitor, its origin is the used instead of its own modes, and they end up at 0x0 too, but no update is done to fix the previously enumerated monitors.
It's not completely clear if this is some sort of hotplugging, or an effect of a lazy enumeration, but we also register for XRandR change events *after* the enumeration:
158096.794:0050:0054:trace:event:X11DRV_register_event_handler registered handler 0x7f11b24e7b10 for event 89 "XRandR CrtcChange" 158096.794:0050:0054:trace:event:X11DRV_register_event_handler registered handler 0x7f11b24e7b10 for event 90 "XRandR OutputChange" 158096.794:0050:0054:trace:event:X11DRV_register_event_handler registered handler 0x7f11b24e7b10 for event 92 "XRandR ProviderChange"
This should probably be done before the enumeration as if there's any hotplug happening we would be missing it.
It's also possible that something is lazily enumerated, and we should perhaps avoid calling XRandR enumeration functions over and over, and instead invoke and enumerate every device upfront, them populate win32u devices and display settings from that. This is probably going to need some larger changes though.
https://bugs.winehq.org/show_bug.cgi?id=57610
--- Comment #14 from Rémi Bernon rbernon@codeweavers.com --- "its origin is the used instead of its own modes" -> "its origin is then used instead, for its own modes"
https://bugs.winehq.org/show_bug.cgi?id=57610
--- Comment #15 from Rémi Bernon rbernon@codeweavers.com --- Created attachment 77776 --> https://bugs.winehq.org/attachment.cgi?id=77776 Tentative fix
Could you try if the attached patch changes anything? It registers the XRandR event handlers before the enumeration, and should catch any delayed change if they send the proper events. It's possible that they don't, though.
https://bugs.winehq.org/show_bug.cgi?id=57610
--- Comment #16 from Austin English austinenglish@gmail.com --- Created attachment 77781 --> https://bugs.winehq.org/attachment.cgi?id=77781 WINEDEBUG=+timestamp,+pid,+loaddll,+system,+x11drv,+event,+win,+xrandr
Unfortunately it didn't help, new log attached.
Applied on wine-10.0-rc4-21-g3f7ff8b5896
https://bugs.winehq.org/show_bug.cgi?id=57610
--- Comment #17 from Rémi Bernon rbernon@codeweavers.com --- Created attachment 77782 --> https://bugs.winehq.org/attachment.cgi?id=77782 Possible fix
Hmm, unfortunate... I think it's an interesting issue though, and I still suspect that we're not doing the enumeration completely right but it's difficult to debug without a similar local setup.
Anyway, another try in the attached patches, which instead update the primary display after everything has been enumerated, removing the intermediate and broken fixup that winex11 is doing. Hopefully that could be acceptable for the code freeze.
https://bugs.winehq.org/show_bug.cgi?id=57610
--- Comment #18 from Austin English austinenglish@gmail.com --- Created attachment 77783 --> https://bugs.winehq.org/attachment.cgi?id=77783 WINEDEBUG=+timestamp,+pid,+loaddll,+system,+x11drv,+event,+win,+xrandr with latest patch
https://bugs.winehq.org/show_bug.cgi?id=57610
--- Comment #19 from Rémi Bernon rbernon@codeweavers.com --- Created attachment 77784 --> https://bugs.winehq.org/attachment.cgi?id=77784 Patch to add traces and dump XRandR state before/after
Alright, I was hoping this would be enough but looks like it's not. Sorry for the number of failed attempts, and thanks a lot for your patience and for your help!
We probably need more information then, could you please make another log with this new patch? It'll dump the entire XRandR state before/after the enumeration and hopefully will help clarifying what is happening.