https://bugs.winehq.org/show_bug.cgi?id=51312
Bug ID: 51312
Summary: dxgi:dxgi: Wrong screen mode order on AMD GPUs
(cw-rx460)
Product: Wine
Version: 6.10
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
dxgi:dxgi gets failures of the form:
https://test.winehq.org/data/patterns.html#dxgi:dxgi
dxgi.c:1460: Test failed: Mode 3: Modes should have been sorted, refresh rate
59.940060 < 85.000000.
dxgi.c:1460: Test failed: Mode 22: Modes should have been sorted, refresh rate
59.940060 < 85.000000.
dxgi.c:1460: Test failed: Mode 55: Modes should have been sorted, refresh rate
59.940060 < 75.000000.
* These failures happen on all available Windows versions (8.1 to 10 2009).
* They also happen regardless of the Radeon driver version: 19.11.3 to 21.4.1.
* They don't happen on machines with any other GPU (cw-gtx560 and QEmu VMs).
* They also happen systematically so are not probably caused by a threading
issue.
* So this really looks like a Radeon-specific behavior.
The failing test was introduced by the following commit:
commit eb2028fa90c41d3b7b8b4f924cd86059c5ba1e0d
Author: Andrew Eikum <aeikum(a)codeweavers.com>
AuthorDate: Mon Oct 28 16:59:18 2019 +0330
dxgi: Sort reported output modes.
Sekiro: Shadows Die Twice depends on this for its mode switching.
Signed-off-by: Andrew Eikum <aeikum(a)codeweavers.com>
Signed-off-by: Henri Verbeet <hverbeet(a)codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
Does the application crash on Windows machines with an AMD GPU?
Or does the Radeon driver return the wrong order only on some GPUs?
If the application does not crash maybe our order specification is a bit too
strict?
Given that an application depends on this we probably want Wine to respect the
ordering.
Just add a broken()?
--
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=52996
Bug ID: 52996
Summary: comdlg32:printdlg fails when OneNote is installed
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: comdlg32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
comdlg32:printdlg fails on cw-gtx560 and cw-rx460 when running Windows 1809 and
1909:
printdlg.c:198: driver 'winspool' device 'OneNote' port
'Microsoft.Office.OneNote_16001.11629.20028.0_x64__8wekyb3d8bbwe_microsoft.onenoteim_S-1-5-21-2735375161-1667520140-535807745-1002'
printdlg.c:215: Test failed: got 0 with 2 and 00000000 for '' (expected '>1'
and '!= NULL')
printdlg.c:220: Test failed: got driver 'winspool' (expected '')
https://test.winehq.org/data/tests/comdlg32:printdlg.html
It turns out these test configurations are the only ones that have this
'OneNote' line. All the others have the following trace instead:
printdlg.c:198: driver 'winspool' device 'Microsoft Print to PDF' port
'PORTPROMPT:'
So my understanding is that 'Microsoft Print to PDF' is the default printer for
all the machines except for these four where "OneNote" is the default instead.
I don't know how "OneNote" came to be the default on these machines. I don't
think it was intentional on my part. Rather I suspect there was some randomness
in the order in which some Windows updates were installed or something like
that.
For reference the cw-rx460-1909 machine has the following printers:
* Fax
* Microsoft Print to PDF
--> This seems to be the default printer on all other machines.
* Microsoft XPS Document Writer
* OneNote
--> This is the one that's selected by default in notepad, so presumably the
default printer.
(The Windows 10 1909 GUI does not make that really clear anywhere else
that I could find)
So it seems like the test should be adjusted to not fail with the OneNote
printer.
That or that check should be skipped?
--
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=50368
Bug ID: 50368
Summary: DragonAge Origins Launcher doesn't toggle music status
Product: Wine
Version: 6.0-rc3
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: winmm&mci
Assignee: wine-bugs(a)winehq.org
Reporter: lorenzofer(a)live.it
Distribution: ArchLinux
Until recently the Dragon Age Origins Launcher didn't work at all becouse bug
#44185 that was recently fixed.
However now, the laucnehr start, it play correctly the music but the toggle
button to disable/enable the music doesn't work.
This is the flow of what seems the issue:
0164:trace:mci:mciSendStringW (L"pause all", 0074EE48, 100, 00000000)
0164:trace:mci:mciSendStringW verb=L"pause" on dev=L"all"; offset=4
0164:trace:mci:mciSendStringW [-1, MCI_PAUSE, 00000000, 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000]
0164:fixme:mci:MCI_SendCommand unhandled MCI_ALL_DEVICE_ID
0164:trace:mci:mciSendStringW => 117
wine isn't handling correctly the MCI_ALL_DEVICE_ID case in cases others then
closing the device.
This affect just the launcher (the game should work properly if not regressed
recently, still didn't try) so low priority, but other programs may be
affected.
--
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=52990
Bug ID: 52990
Summary: MFMEv20 Emulator needs user32.RegisterTouchWindow
implementation
Product: Wine
Version: 6.14
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: user32
Assignee: wine-bugs(a)winehq.org
Reporter: austinenglish(a)gmail.com
Distribution: Debian
With wine-7.8, the application pops up an error dialog on start:
RegisterTouchWindow Failed.
If the function is hacked to return TRUE instead of FALSE, the application then
starts 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=51217
Bug ID: 51217
Summary: RtlWow64IsWowGuestMachineSupported() check fails on
w1064v1607 for the 32-bit ntdll:info
Product: Wine
Version: 6.8
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
ntdll:info has a failure on w1064v1607 (Windows 10 64-bit version 1607 running
the 32-bit tests):
https://test.winehq.org/data/patterns.html#ntdll:info
info.c:3024: Test failed: wrong result 0
This is a check of the RtlWow64IsWowGuestMachineSupported() result.
The commit that introduced this check is:
commit 4f8ede8e7665328a2a3ccd303875e239bf443512
Author: Alexandre Julliard <julliard(a)winehq.org>
AuthorDate: Thu Apr 29 17:15:15 2021 +0200
ntdll: Implement RtlWow64IsWowGuestMachineSupported().
Signed-off-by: Alexandre Julliard <julliard(a)winehq.org>
--
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=51078
Bug ID: 51078
Summary: mshtml:events hangs on Windows 10 1709
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: mshtml
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Created attachment 69941
--> https://bugs.winehq.org/attachment.cgi?id=69941
Patch to more reliably reproduce the hang
mshtml:events sometimes hangs on Windows 10 1709:
http://winetest.dolphin/data/patterns.html#mshtml:events
For some reason this only happens on Windows 1709 (the reports say this is
mshtml 11.0.16299.309).
The test proceeds all the way to the end but then does not exit because the
mshtml component still has threads running:
VSyncHelper
Internet Explorer_Hidden
MSCTFIME UI
Commenting out the test_focus() run gets rid of the hangs.
Also running the test with WINETEST_INTERACTIVE=1 greatly increases the
probability of getting a hang. I attached a patch that does that and can be
used to reproduce the hang on the TestBot's w1064v1709 VM.
So this is clearly related to focus.
--
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=39659
Bug ID: 39659
Summary: comctl32:button test gets unexpected WM_CANCELMODE on
my Windows 8 laptop
Product: Wine
Version: 1.8-rc1
Hardware: x86
OS: Windows
Status: NEW
Severity: normal
Priority: P2
Component: comctl32
Assignee: wine-bugs(a)winehq.org
Reporter: madewokherd(a)gmail.com
Created attachment 52866
--> https://bugs.winehq.org/attachment.cgi?id=52866
log of test failure
Test report:
https://test.winehq.org/data/1d19eb15d4abfdd14dccc5ac05b83c0ee1a1ace1/win8_…
Message tests calling SetFocus() on a button fail on my Windows 8 machine,
because they get a WM_CANCELMODE message they weren't expecting. I have no idea
what's special about my setup. It doesn't matter if I run the test stand-alone
or with the full test suite, or if I run it as a dedicated user with a default
configuration.
--
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=30875
Bug #: 30875
Summary: Unable to deselect character blocks in BMFont
Product: Wine
Version: 1.5.6
Platform: x86-64
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: dav75uk(a)yahoo.co.uk
Classification: Unclassified
Run BMFont (http://www.angelcode.com/products/bmfont/) and click on some of the
checkboxes to the right to select characters to be included. It is not possible
to uncheck the checkboxes.
Workaround is to unselect one of the characters (click on a character in that
range) which changes the full checked box to a part check box. The part check
box can be unselected.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
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=52911
Bug ID: 52911
Summary: ole32:moniker fails on Windows in the UTF-8 codepage
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: ole32
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
ole32:moniker fails on Windows in the UTF-8 codepage:
moniker.c:2189: Test failed: IsEqual failed with error 0x000001
[...]
https://test.winehq.org/data/patterns.html#ole32:moniker
So the failures happen because moniker1 and moniker2 are always different.
Adding a call to winetest_push_context() shows that the failures all happen for
string 2 which ole32:moniker uses to skip tests on code pages where there are
round-trip issues:
{0xc0, 0xc1, 0xc2, 0xc3, 0xc4, 0xc5, 0xc6, 0xc7, 0xc8, 0xc9, 0xca,
0xcb, 0xcc, 0xcd, 0xce, 0xcf, 0xd0, 0},
[...]
skip("string 2 doesn't round trip in codepage %u\n", GetACP() );
So it looks like the skip fails to trigger for the UTF-8 codepage (or that we
should do something else to make the UTF-8 case work).
--
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.