wine-bugs

wine-bugs@winehq.org

1 participants
158770 discussions

[Bug 54017] New: dwmapi:dwmapi - test_DwmGetCompositionTimingInfo() fails on AMD GPUs
by WineHQ Bugzilla 30 Nov '22

30 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=54017 Bug ID: 54017 Summary: dwmapi:dwmapi - test_DwmGetCompositionTimingInfo() fails on AMD GPUs Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: dwmapi Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com dwmapi:dwmapi - test_DwmGetCompositionTimingInfo() fails on (PCI passthrough) AMD and NVIDIA VMs: * the TestBot's Windows 11 NVIDIA RTX3050 VM * the TestBot's Windows 11 AMD RX6600 VM * my Windows 10 22H2 AMD RX550 VM RTX3050 + HDMI/DisplayPort dongle: dwmapi.c:81: Test failed: Got wrong monitor refresh period 28b07. RX6600 + HDMI/DisplayPort dongle: dwmapi.c:81: Test failed: Got wrong monitor refresh period 28b20. RX550 + HDMI screen: dwmapi.c:81: Test failed: Got wrong monitor refresh period 28bb1. See https://test.winehq.org/data/patterns.html#dwmapi:dwmapi Note that this test succeeds on both of the TestBot's plain QEmu w11pro64 test configuration (virtual QXL GPU). This test has two other failures that also impact QXL (see bug 54016). -- 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.

1 1

[Bug 53265] New: mmdevapi:capture - test_capture() has timing-related failures on Windows
by WineHQ Bugzilla 29 Nov '22

29 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=53265 Bug ID: 53265 Summary: mmdevapi:capture - test_capture() has timing-related failures on Windows Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: mmdevapi Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com mmdevapi:capture - test_capture() has timing-related failures on Windows: capture.c:282: Test failed: Position 1719 last 896 frames 448 https://test.winehq.org/data/patterns.html#mmdevapi:capture The failures happen randomly but frequently on Windows 8 to Windows 10 1809. However, because the message includes a duration, it is prone to cause false positives (see also bug 53126 for a similar failure in mmdevapi:render). Furthermore mmdevapi:capture has other systematic failures on Windows 10 1909+ that probably just mask this one (see bug 53264). So one should assume that this timing-related failure impacts all Windows 10 versions. -- 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.

1 3

[Bug 53433] New: mmdevapi:capture - test_capture() sometimes fails after resuming capture
by WineHQ Bugzilla 29 Nov '22

29 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=53433 Bug ID: 53433 Summary: mmdevapi:capture - test_capture() sometimes fails after resuming capture Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: mmdevapi Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com mmdevapi:capture - test_capture() sometimes fails after resuming capture: capture.c:301: Cont'ed position 2103 pad 21548 flags 0, amount of frames locked: 448 capture.c:325: Restart position 2615 pad 21100 flags 1, amount of frames locked: 448 capture.c:330: Test failed: Position 2615 expected 2551 capture.c:331: Test failed: flags 1 https://test.winehq.org/data/patterns.html#mmdevapi:capture As of today there are 3 known instances of these failures (2022-06-28, 2022-07-11, 2022-07-28) and all 3 happened on Windows 8. Also are independent from the failures in bug 53265. -- 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.

1 3

[Bug 53281] New: d3d9:d3d9ex - test_wndproc() sometimes gets an unexpected WM_WINDOWPOSCHANGED on Windows 8+
by WineHQ Bugzilla 29 Nov '22

29 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=53281 Bug ID: 53281 Summary: d3d9:d3d9ex - test_wndproc() sometimes gets an unexpected WM_WINDOWPOSCHANGED on Windows 8+ Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com d3d9:d3d9ex - test_wndproc() sometimes gets an unexpected WM_WINDOWPOSCHANGED on Windows 8+: d3d9ex.c:3117: Test failed: Received WM_WINDOWPOSCHANGED but did not expect it, i=0. (also happens with i=1) https://test.winehq.org/data/patterns.html#ddraw:ddraw1 Note that a similar failure seems to happen with KDE in Wine but there is more than one WM_WINDOWPOSCHANGED message so it may be different (see fg-deb64). -- 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.

1 4

[Bug 53979] New: d3d9:d3d9ex - test_wndproc() is sometimes missing a WM_WINDOWPOSCHANGING message in Wine
by WineHQ Bugzilla 29 Nov '22

29 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=53979 Bug ID: 53979 Summary: d3d9:d3d9ex - test_wndproc() is sometimes missing a WM_WINDOWPOSCHANGING message in Wine Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: d3d Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- d3d9:d3d9ex - test_wndproc() is sometimes missing a WM_WINDOWPOSCHANGING message in Wine: d3d9ex.c:3115: Test failed: Expected message 0x46 for window 0x1, but didn't receive it, i=1. See https://test.winehq.org/data/patterns.html#d3d9:d3d9ex This seems to be mostly happening on my desktop (Intel + KDE), but it also happened on the debian11 VM in MR!1538 (unrelated heap refactoring). So it's not specific to KDE and can indeed happen on the TestBot VMs. -- 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.

1 2

[Bug 53232] New: d3d8:device - test_reset() fails randomly on Windows
by WineHQ Bugzilla 29 Nov '22

29 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=53232 Bug ID: 53232 Summary: d3d8:device - test_reset() fails randomly on Windows Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com d3d8:device - test_reset() fails randomly on Windows. The failures change a bit from one run to the next: device.c:1955: Test failed: Reset failed, hr 0x88760873. device.c:1957: Test failed: TestCooperativeLevel failed, hr 0x88760869. or device.c:1964: Test failed: Failed to reset device, hr 0x88760873. https://test.winehq.org/data/patterns.html#d3d8:device They have been seen on Windows 8 up to Windows 10 21H1 but are quite rare on the TestBot VMs. -- 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.

1 3

[Bug 3781] iRiver caption editor: Main window layout severely broken
by WineHQ Bugzilla 29 Nov '22

29 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=3781 Eleanor Ellis <essayhelpzone(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |essayhelpzone(a)gmail.com --- Comment #17 from Eleanor Ellis <essayhelpzone(a)gmail.com> --- Great opportunity provide when you are stuck on any problem related to your project, so you can visit to learn more https://essayhelpzone.co.uk/blog/7-best-benefits-using-essay-help-online/ -- 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.

1 0

[Bug 54004] New: ntoskrnl.exe:ntoskrnl sometimes does not receive IRP_MN_REMOVE_DEVICE in Wine
by WineHQ Bugzilla 29 Nov '22

29 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=54004 Bug ID: 54004 Summary: ntoskrnl.exe:ntoskrnl sometimes does not receive IRP_MN_REMOVE_DEVICE in Wine Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntoskrnl Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- ntoskrnl.exe:ntoskrnl sometimes does not receive the IRP_MN_REMOVE_DEVICE request in Wine: driver_pnp.c:737: Test failed: expected IRP_MN_REMOVE_DEVICE See https://test.winehq.org/data/patterns.html#ntoskrnl.exe:ntoskrnl This failure is pretty rare (7 instances in ~5 months) but did cause a false positive in MR!1549. -- 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.

1 1

[Bug 54002] New: user32:win sometimes has 90+ failures on the w7u VM
by WineHQ Bugzilla 29 Nov '22

29 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=54002 Bug ID: 54002 Summary: user32:win sometimes has 90+ failures on the w7u VM Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Created attachment 73585 --> https://bugs.winehq.org/attachment.cgi?id=73585 2022-11-23 w7u-2qxl user32:win report with 97 failures user32:win sometimes has 90+ failures on the w7u VM. The failures are spread out in multiple test functions but an early message indicates they are probably all caused by a window that popped up: win.c:10296: Tests skipped: there's another window covering test window win.c:9134: monitor (0,0)-(1024,768), work (0,0)-(1024,728) win.c:1541: Test failed: Expected color 0xc0c0c0, got 0xffffffff. win.c:800: parent 007E01FC adopter 00790162 child1 00290210 child2 00220214 child3 0030021A win.c:1541: Test failed: Expected color 0xc0c0c0, got 0xffffffff. win.c:1541: Test failed: Expected color 0xc0c0c0, got 0xffffffff. win.c:1541: Test failed: Expected color 0xc0c0c0, got 0xffffffff. 0820:win: 19 tests executed (0 marked as todo, 0 as flaky, 0 failures), 0 skipped. [... full user32:win report attached ...] See https://test.winehq.org/data/patterns.html#user32:win Unfortunately it seems not all test functions skip when a window covers the test window. Because this failure only happens on w7u and not on w7pro64 it is indeed likely the the failures are caused by a rogue window popping up specifically on that VM for some reason. -- 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.

1 2

[Bug 53984] New: Broken minimize-restore logic in conhost.exe for all console apps
by WineHQ Bugzilla 28 Nov '22

28 Nov '22

https://bugs.winehq.org/show_bug.cgi?id=53984 Bug ID: 53984 Summary: Broken minimize-restore logic in conhost.exe for all console apps Product: Wine Version: 7.21 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: x1917x(a)gmail.com Distribution: --- Created attachment 73566 --> https://bugs.winehq.org/attachment.cgi?id=73566 Issue log for minimize-restore There is an old bug in Wine's conhost.exe, introduced years ago. Whenever a console window is minimized and then restored, conhost.exe creates both vertical and horizontal scrollbars for that window, no matter that there were no changes to that window. Bad consequence is that both of them overlap parts of content of the console window, so now one have to actually scroll the window to see the lines/columns covered by scrollbars. From what I see, the bug affects all console apps, the attached log file was taken for Wine's cmd.exe (wineconsole cmd.exe). The root cause of the bug is that conhost.exe makes no distinction between WM_SIZE caused by regular resize and WM_SIZE caused by minimizing. Whenever the console window gets minimized, ShowWindow(SW_MINIMIZE) is being called for it. Internally, Wine's show_window() calls window_min_maximize() to retrieve the minimized window Rect. For a minimized window it fills that Rect with the size of "iconic" window, which is determined by get_system_metrics(SM_CXMINIMIZED) and get_system_metrics(SM_CYMINIMIZED). Not sure if it depends on the host, but on my system it is 160 x 31. So eventually WM_SIZE(<...>, 160, 31) is being sent to conhost.exe's window, among few other WM_-messages. As conhost.exe makes no distinction between the different states the console window can be, it assumes that the minimized window size (160x31) is the new real window size. Then it tries to apply the same sequence of actions like for any received WM_SIZE. One of them is checking if the newly resized console window is smaller than its content. If it was the case, it creates respective horizontal/vertical scrollbars in window.c/update_window(). So basically, conhost.exe treats every window minimizing as a resize. Luckily, the fix is trivial - Wine's conhost.exe shouldn't try to resize its window when it is minimized. There is zero point to resize a minimized window, especially if it wasn't resized at all. case WM_SIZE: if (console->window && console->window->update_state != UPDATE_BUSY) resize_window( console, --> case WM_SIZE: if (console->window && console->window->update_state != UPDATE_BUSY && !IsIconic(console->win)) resize_window( console, (the patch is attached) Please review and apply the proposed fix if it's ok (I am not a Wine contributor - don't know how to commit to Wine, not a member of the mail list etc). -- 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.

1 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-bugs