[Bug 57610] New: No windows are shown when using a dual monitor setup
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(a)winehq.org Reporter: austinenglish(a)gmail.com Regression SHA1: 3cf0506ccae3551132a55d38d9efbde43e54e695 Distribution: Debian 3cf0506ccae3551132a55d38d9efbde43e54e695 is the first bad commit commit 3cf0506ccae3551132a55d38d9efbde43e54e695 Author: Rémi Bernon <rbernon(a)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. -- 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=57610 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon(a)codeweavers.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=57610 --- Comment #1 from Rafał Mużyło <galtgendo(a)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 ? -- 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=57610 --- Comment #2 from Austin English <austinenglish(a)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(a)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(a)debian:~$ wmctrl -a 0x5a00001 austin(a)debian:~$ wmctrl -a 0x5a00002 austin(a)debian:~$ wmctrl -a 0x5a00003 austin(a)debian:~$ wmctrl -a notepad.exe austin(a)debian:~$ wmctrl -a notepad austin(a)debian:~$ wmctrl -a "Untitled - Notepad" -- 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=57610 --- Comment #3 from Rafał Mużyło <galtgendo(a)o2.pl> --- You probably want to start with something simple, like 'wmctrl -i -R <WID>'. -- 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=57610 --- Comment #4 from Rafał Mużyło <galtgendo(a)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 ? -- 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=57610 --- Comment #5 from Rémi Bernon <rbernon(a)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. -- 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=57610 --- Comment #6 from Austin English <austinenglish(a)gmail.com> --- Created attachment 77743 --> https://bugs.winehq.org/attachment.cgi?id=77743 WINEDEBUG=+timestamp,+pid,+loaddll,+system,+x11drv,+event,+win -- 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=57610 --- Comment #7 from Austin English <austinenglish(a)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). -- 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=57610 --- Comment #8 from Rémi Bernon <rbernon(a)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? -- 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=57610 --- Comment #9 from Austin English <austinenglish(a)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). -- 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=57610 --- Comment #10 from Rémi Bernon <rbernon(a)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. -- 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=57610 --- Comment #11 from Austin English <austinenglish(a)gmail.com> --- Created attachment 77748 --> https://bugs.winehq.org/attachment.cgi?id=77748 WINEDEBUG=+timestamp,+pid,+loaddll,+system,+x11drv,+event,+win,+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=57610 --- Comment #12 from Austin English <austinenglish(a)gmail.com> --- Created attachment 77749 --> https://bugs.winehq.org/attachment.cgi?id=77749 xrandr output -- 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=57610 --- Comment #13 from Rémi Bernon <rbernon(a)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. -- 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=57610 --- Comment #14 from Rémi Bernon <rbernon(a)codeweavers.com> --- "its origin is the used instead of its own modes" -> "its origin is then used instead, for its own modes" -- 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=57610 --- Comment #15 from Rémi Bernon <rbernon(a)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. -- 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=57610 --- Comment #16 from Austin English <austinenglish(a)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 -- 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=57610 --- Comment #17 from Rémi Bernon <rbernon(a)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. -- 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=57610 --- Comment #18 from Austin English <austinenglish(a)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 -- 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=57610 --- Comment #19 from Rémi Bernon <rbernon(a)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. -- 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=57610 Zhiyi Zhang <zzhang(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |zzhang(a)codeweavers.com --- Comment #20 from Zhiyi Zhang <zzhang(a)codeweavers.com> --- Created attachment 77788 --> https://bugs.winehq.org/attachment.cgi?id=77788 EnumAdapters.zip Could you run the EnumAdapters.exe inside the EnumAdapters.zip and show us the results? -- 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=57610 Austin English <austinenglish(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #77743|0 |1 is obsolete| | Attachment #77744|0 |1 is obsolete| | Attachment #77746|0 |1 is obsolete| | Attachment #77748|0 |1 is obsolete| | Attachment #77776|0 |1 is obsolete| | Attachment #77781|0 |1 is obsolete| | Attachment #77782|0 |1 is obsolete| | Attachment #77783|0 |1 is obsolete| | --- Comment #21 from Austin English <austinenglish(a)gmail.com> --- Created attachment 77789 --> https://bugs.winehq.org/attachment.cgi?id=77789 debug log with extra traces No problem, thanks for working on 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=57610 --- Comment #22 from Austin English <austinenglish(a)gmail.com> --- Created attachment 77790 --> https://bugs.winehq.org/attachment.cgi?id=77790 enumadapters output -- 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=57610 --- Comment #23 from Zhiyi Zhang <zzhang(a)codeweavers.com> --- Eh, this is a strange one. Just like Rémi mentioned in comment #13, get_primary_rect() suddenly found a valid primary monitor when getting the current mode for the second monitor. However, from the logs in comment #21, after display enumeration, XRRGetOutputPrimary() still fails. I wonder what could cause 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=57610 Rémi Bernon <rbernon(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #77784|0 |1 is obsolete| | --- Comment #24 from Rémi Bernon <rbernon(a)codeweavers.com> --- Created attachment 77796 --> https://bugs.winehq.org/attachment.cgi?id=77796 Add traces to dump XRandR monitors too Yes, it looks like it only succeeds from time to time... which makes it a bit unusable. The attached patch also dumps the new XRandR 1.5 monitors, which could perhaps be used instead to detect the primary rect, if you don't mind making another log with it. -- 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=57610 --- Comment #25 from Rémi Bernon <rbernon(a)codeweavers.com> --- Created attachment 77797 --> https://bugs.winehq.org/attachment.cgi?id=77797 Tentative fix To fix this within the code freeze, I think the attached patch could perhaps do the trick. As XRRGetOutputPrimary seems unreliable, calling it only once per enumeration should make things consistent enough. -- 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=57610 --- Comment #26 from Austin English <austinenglish(a)gmail.com> --- Created attachment 77798 --> https://bugs.winehq.org/attachment.cgi?id=77798 WINEDEBUG=+timestamp,+pid,+loaddll,+system,+x11drv,+event,+win,+xrandr Unfortunately 77797 didn't work either. Attached debug log with that + 77796 traces applied on wine-10.0-rc4-21-g3f7ff8b5896 -- 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=57610 --- Comment #27 from Rémi Bernon <rbernon(a)codeweavers.com> --- Created attachment 77799 --> https://bugs.winehq.org/attachment.cgi?id=77799 Workaround Oof... This is silly, it looks like that none of the monitors are primary in general but suddenly and only for one call, the second monitor briefly remembers that it is primary and that its crtc also moves to 0x0?? Anyway, lets try to workaround it instead, and use the monitor coordinates for the current display mode if they don't match. I don't see how this could fail now but I'm ready for anything at this point. I've also included some more traces, if you could make another log in any case. Thank you! -- 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=57610 Rémi Bernon <rbernon(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #77799|0 |1 is obsolete| | --- Comment #28 from Rémi Bernon <rbernon(a)codeweavers.com> --- Created attachment 77800 --> https://bugs.winehq.org/attachment.cgi?id=77800 Workaround And I'm stupid and the traces broke something, this is the workaround only. -- 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=57610 --- Comment #29 from Rémi Bernon <rbernon(a)codeweavers.com> --- Double stupid, this is driving me crazy, attachment 77799 actually works fine. -- 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=57610 --- Comment #30 from Austin English <austinenglish(a)gmail.com> --- (In reply to Rémi Bernon from comment #28)
Created attachment 77800 [details] Workaround
And I'm stupid and the traces broke something, this is the workaround only.
This works for `wine notepad` on wine-10.0-rc4-21-g3f7ff8b5896 \o/ -- 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=57610 --- Comment #31 from Rémi Bernon <rbernon(a)codeweavers.com> --- At last! Would you mind doing a log with attachment 77799 nonetheless? That could perhaps help finding a better fix for later. -- 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=57610 --- Comment #32 from Austin English <austinenglish(a)gmail.com> --- Created attachment 77801 --> https://bugs.winehq.org/attachment.cgi?id=77801 WINEDEBUG=+timestamp,+pid,+loaddll,+system,+x11drv,+event,+win,+xrandr Sure, here you go. -- 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=57610 --- Comment #33 from Zhiyi Zhang <zzhang(a)codeweavers.com> --- Created attachment 77802 --> https://bugs.winehq.org/attachment.cgi?id=77802 trace patch Could you do another log with this patch and see if the bug is still there? I want to ensure that it's caused by weird behavior from XRRGetOutputPrimary rather than Wine code. -- 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=57610 --- Comment #34 from Austin English <austinenglish(a)gmail.com> --- Created attachment 77817 --> https://bugs.winehq.org/attachment.cgi?id=77817 WINEDEBUG=+timestamp,+pid,+loaddll,+system,+x11drv,+event,+win,+xrandr Here you go Zhiyi, this was applied on wine-10.0-rc5 -- 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=57610 Zhiyi Zhang <zzhang(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #77802|0 |1 is obsolete| | --- Comment #35 from Zhiyi Zhang <zzhang(a)codeweavers.com> --- Created attachment 77819 --> https://bugs.winehq.org/attachment.cgi?id=77819 trace patch 2 Hi, Austin. Your log did suggest that XRRGetOutputPrimary() is working fine. Please try this patch, which enables additional tracing. -- 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=57610 --- Comment #36 from Austin English <austinenglish(a)gmail.com> --- Created attachment 77820 --> https://bugs.winehq.org/attachment.cgi?id=77820 WINEDEBUG=+timestamp,+pid,+loaddll,+system,+x11drv,+event,+win,+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=57610 --- Comment #37 from Austin English <austinenglish(a)gmail.com> --- (In reply to Austin English from comment #36)
Created attachment 77820 [details] WINEDEBUG=+timestamp,+pid,+loaddll,+system,+x11drv,+event,+win,+xrandr
Forgot to mention, the problem is still present with this patch (applied on wine-10.0-rc5). -- 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=57610 Zhiyi Zhang <zzhang(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #77819|0 |1 is obsolete| | --- Comment #38 from Zhiyi Zhang <zzhang(a)codeweavers.com> --- Created attachment 77821 --> https://bugs.winehq.org/attachment.cgi?id=77821 trace patch 3 Log in #36 suggests that the current mode reported is wrong and the primary rect is correct. Please try this patch that adds more logs. Also, get the output from `xrandr --verbose`. -- 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=57610 --- Comment #39 from Austin English <austinenglish(a)gmail.com> --- Created attachment 77822 --> https://bugs.winehq.org/attachment.cgi?id=77822 WINEDEBUG=+timestamp,+pid,+loaddll,+system,+x11drv,+event,+win,+xrandr Still present with patch 3, trace attached. -- 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=57610 Zhiyi Zhang <zzhang(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #77797|0 |1 is obsolete| | Attachment #77800|0 |1 is obsolete| | --- Comment #40 from Zhiyi Zhang <zzhang(a)codeweavers.com> --- Created attachment 77826 --> https://bugs.winehq.org/attachment.cgi?id=77826 winex11.drv: Fix display name in X11DRV_UpdateDisplayDevices(). This should fix the bug. Please test. -- 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=57610 --- Comment #41 from Austin English <austinenglish(a)gmail.com> --- (In reply to Zhiyi Zhang from comment #40)
Created attachment 77826 [details] winex11.drv: Fix display name in X11DRV_UpdateDisplayDevices().
This should fix the bug. Please test.
Yep, thanks! -- 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=57610 --- Comment #42 from Zhiyi Zhang <zzhang(a)codeweavers.com> --- I submitted the patch at https://gitlab.winehq.org/wine/wine/-/merge_requests/7136. Thank you all! -- 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=57610 Rémi Bernon <rbernon(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Fixed by SHA1| |a058bd714f4a70f2b3df6527096 | |126af249ba372 Resolution|--- |FIXED --- Comment #43 from Rémi Bernon <rbernon(a)codeweavers.com> --- Fixed with a058bd714f4a70f2b3df6527096126af249ba372, thanks everyone! -- 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=57610 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #44 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 10.0-rc6. -- 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