[Bug 58358] New: Dungeons & Dragons Online: No suitable graphics device was found. [122]
http://bugs.winehq.org/show_bug.cgi?id=58358
Bug ID: 58358 Summary: Dungeons & Dragons Online: No suitable graphics device was found. [122] Product: Wine Version: 10.9 Hardware: arm OS: MacOS Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: ccooksey@mindspring.com
Created attachment 78747 --> http://bugs.winehq.org/attachment.cgi?id=78747 Logs showing the video driver failures in Wine 10.0_1 and higher
On macOS Sequoia, using Apple Silicon on a MacBook Pro, running Dungeons and Dragons online and entering the game world on any version of Wine *after* 10.0 will stop with a message:
"No suitable graphics device was found. Are you running through a remote session or a VM? If not, please check your video hardware capabilities. [122]"
The game terminates and cannot be played. Note that the Game Launcher works fine. It is the game client that fails -the bit that uses DX9 and above.
If the original Wine 10.0 is installed (prior to 10.0_1), it works fine.
To recreate:
Working case (Wine 10.0): - Register a free account at: https://www.ddo.com/register - Download the game installer here: https://www.ddo.com/download - Install wine 10.0, (not wine-stable - see instructions below). - Install the game to a standard wine prefix. - Run "C:/Program Files (x86)/StandingStoneGames/Dungeons & Dragons Online/DNDLauncher.exe" to enter the launcher. Use your free account. - Enter the world "Orien". - Observe that the character creation screen in the game client appears.
Non working case (Wine 10.0_1 and higher): - Install any higher version of Wine, i.e. wine-stable (10.0_2), wine@staging or wine@devel. - Install the game to a standard wine prefix (if you didn't already). - Run "C:/Program Files (x86)/StandingStoneGames/Dungeons & Dragons Online/DNDLauncher.exe" to enter the launcher. Use your free account. - Enter the world "Orien". - The game client will stop with error [122] as it tries to connect to DX9.
My observation:
10.0 uses: [mvk-info] MoltenVK version 1.2.10, supporting Vulkan version 1.2.290.
10.0_1 and higher all use: [mvk-info] MoltenVK version 1.3.0, supporting Vulkan version 1.3.313.
There are literally no code changes in Wine from 10.0 to 10.0_1. But these graphics libs did change and now there appears to be no video driver.
I have been using brew to install. Here is a speedy way to get the original Wine 10.0 installed on a machine:
brew uninstall wine-stable # or wine@staging or wine@devel, as needed curl -o wine-stable.rb https://raw.githubusercontent.com/Homebrew/homebrew-cask/3b6f8acd9c1f8aad561... sed -i '' 's/wine64/msidb/g' wine-stable.rb # Implements an important change from the 10.0_1 brew cask. brew install --no-quarantine wine-stable.rb # Note the '.rb' suffix. # If you are on Apple Silicon, install Apple's x86 emulator. Ignore any errors. /usr/sbin/softwareupdate --install-rosetta --agree-to-license
For the breaking case, you can just "brew install --no-quarantine [wine-stable | wine@staging | wine@devel]". No need to use older casks.
Note that the current gstreamer is not compatible with wine-stable. Optionally add these commands to prevent gstreamer from being noisy and slowing things down: export GST_PLUGIN_PATH=/dev/null export GST_PLUGIN_SYSTEM_PATH=/dev/null
I have attached logs from 10.0 (working) and 10.9 (not working).
I used WINEDEBUG="+seh,+tid,+d3d,+vulkan,+dxvk,+d3d12".
Please let me know if you need any additional info from me.
Thanks, Chris.
http://bugs.winehq.org/show_bug.cgi?id=58358
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
--- Comment #1 from Ken Sharp imwellcushtymelike@gmail.com ---
There are literally no code changes in Wine from 10.0 to 10.0_1. But these graphics libs did change and now there appears to be no video driver.
You need to report that to MoltenVK then.
If a Wine bug can be demonstrated then please come back with the details.
http://bugs.winehq.org/show_bug.cgi?id=58358
--- Comment #2 from Chris Cooksey ccooksey@mindspring.com --- The bug seems to have been introduced in a library called wined3d.dll. If I drop the version from 10.0 into 10.0_2, everything works. I think that might make this a Wine problem again. It doesn't matter what version of MoltenVK I use.
I am going to try to isolate whatever changes could have happened in the short window between Wine 10.0 and Wine 10.0_2 (probably Wine 10.0_1 even, but I haven't tested the fix there).
http://bugs.winehq.org/show_bug.cgi?id=58358
--- Comment #3 from Chris Cooksey ccooksey@mindspring.com --- I tested with wine-stable 10.0_1.
Replacing the wine-stable 10.0_1 file
/Applications/Wine\ Stable.app/Contents/Resources/wine/lib/wine/x86_64-windows/wined3d.dll
with the same file taken from wine-stable 10.0 makes D3D work again.
There are 78 commits between Jan 22 and Apr 21, which I estimate to be the window where this problem was introduced (Sorry Github does not provide a date filter).
https://github.com/wine-mirror/wine/commits/master/dlls/wined3d?before=88544...
I looked through it all and most seem improbable as sources of the issue. There are some that seem like they could potentially be telling the application something wrong, but I am well out of my depth here.
I am a wee bit suspicious that this is a copy paste error: https://github.com/wine-mirror/wine/commit/078f0a8e191b761a7c7bbfda859ddac22... Maybe it was supposed to be ALL_GL_UNIX_FUNCS like all the others. But again -well out of my depth.
Since this bug is closed, should I open another?
http://bugs.winehq.org/show_bug.cgi?id=58358
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com Resolution|INVALID |--- Status|RESOLVED |UNCONFIRMED
--- Comment #4 from Zeb Figura z.figura12@gmail.com --- Reopening.
http://bugs.winehq.org/show_bug.cgi?id=58358
--- Comment #5 from Chris Cooksey ccooksey@mindspring.com --- I figured out how to build and install wined3d.dll.
It was the set of commits on Feb 28th, 2025 that prevents Dungeons and Dragons Online from using DX 9.
I will experiment some more, but it looks like these changes were intended to switch from OpenGL to Vulkan. That is just speculation on my part.
http://bugs.winehq.org/show_bug.cgi?id=58358
--- Comment #6 from Chris Cooksey ccooksey@mindspring.com --- This is the commit that broke DDO: https://gitlab.winehq.org/wine/wine/-/commit/984e24d327ecc5ec92e3cf8f8afa9d7...
http://bugs.winehq.org/show_bug.cgi?id=58358
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, regression URL| |https://www.ddo.com/downloa | |d Regression SHA1| |984e24d327ecc5ec92e3cf8f8af | |a9d7631d39d64 Component|-unknown |d3d
http://bugs.winehq.org/show_bug.cgi?id=58358
--- Comment #7 from Zeb Figura z.figura12@gmail.com --- The logs from comment 0 are from some patched version of Wine, or at least, the 10.9 log is. Specifically, it's doing this:
0024:err:winediag:wined3d_adapter_create Using the Vulkan renderer for d3d10/11 applications.
which is a patch taken from CrossOver, and is not supported here.
(In reply to Chris Cooksey from comment #6)
This is the commit that broke DDO: https://gitlab.winehq.org/wine/wine/-/commit/ 984e24d327ecc5ec92e3cf8f8afa9d7631d39d64
That's odd, and I don't think it's the same cause. Can you please attach +d3d,+d3d11,+dxgi logs from before and after this commit?
http://bugs.winehq.org/show_bug.cgi?id=58358
--- Comment #8 from Chris Cooksey ccooksey@mindspring.com --- Created attachment 78793 --> http://bugs.winehq.org/attachment.cgi?id=78793 Logs +d3d,+d3d11,+dxgi for commits b2a (good) and 984 (bad)
http://bugs.winehq.org/show_bug.cgi?id=58358
--- Comment #9 from Chris Cooksey ccooksey@mindspring.com --- Attached logs. The first material difference I could see is at line 12800, after which the "bad" run ends the game before the first screen comes up:
0024:fixme:d3d9:d3dformat_from_wined3dformat Unhandled wined3d format 0x77.
http://bugs.winehq.org/show_bug.cgi?id=58358
--- Comment #10 from Chris Cooksey ccooksey@mindspring.com --- Oh -I dont use Crossover. Never have. I do have Apple's Game Porting Toolkit installed, but it uses a separate prefix. There is a possibility that the Game Porting Toolkit might have used my regular wine prefix at some point. Could that have contaminated it? I notice that the wined3d.dll seems to be copied over into the prefix drive c occasionally. I have never been able to figure out when, so I make sure to copy it to both places every time when testing a new build. But if it can, then perhaps other things can as well.
http://bugs.winehq.org/show_bug.cgi?id=58358
--- Comment #11 from Chris Cooksey ccooksey@mindspring.com --- I installed a brand new copy of wine 10.0_2, deleted my .wine folder entirely, reinstalled the game and ran it. It still has the same issue "No suitable graphics device was found". That should rule out any possibility of cross contamination from Apple's Game Porting Toolkit.
http://bugs.winehq.org/show_bug.cgi?id=58358
--- Comment #12 from Zeb Figura z.figura12@gmail.com --- (In reply to Chris Cooksey from comment #9)
Attached logs. The first material difference I could see is at line 12800, after which the "bad" run ends the game before the first screen comes up:
0024:fixme:d3d9:d3dformat_from_wined3dformat Unhandled wined3d format 0x77.
Are you doing something like replacing *only* wined3d.dll? That line should be impossible unless you have a mismatch between d3d9.dll and wined3d.dll.
(In reply to Chris Cooksey from comment #11)
That should rule out any possibility of cross contamination from Apple's Game Porting Toolkit.
It's not the Game Porting Toolkit, it's a patch to Wine itself. Unfortunately, it turns out that our official Mac Wine builds started using external patches, which I was quite unaware about, and as far as I can tell caused a regression in this case. I'll try to make the case to stop doing this.
http://bugs.winehq.org/show_bug.cgi?id=58358
--- Comment #13 from Chris Cooksey ccooksey@mindspring.com --- Yes -I am only replacing wined3d.dll. Sorry, I am very new to this and dont know how it all hooks together. So I should be building and replacing d3d9.dll and wined3d.dll both at the same time? Are there any others I should be building as well? I want to diagnose this as accurately as possible.
As to the larger problem, good luck. I had provided instructions to other gamers based on my initial experience with 10.0. It immediately broke with the release of 10.0_1 -which should not have been changing code -it should have just been a brew cask change. And now the issue has propagated through every subsequent release through 10.9.
The issue affects Lord of the Rings Online as well. A much more popular game than Dungeons and Dragons Online.
Thanks for your help!
http://bugs.winehq.org/show_bug.cgi?id=58358
--- Comment #14 from Chris Cooksey ccooksey@mindspring.com --- Im setting up to build the whole thing now. That seems to be the only safe way to go when I am switching between arbitrary commits.
http://bugs.winehq.org/show_bug.cgi?id=58358
--- Comment #15 from Nikolay Sivov bunglehead@gmail.com --- (In reply to Chris Cooksey from comment #13)
Yes -I am only replacing wined3d.dll. Sorry, I am very new to this and dont know how it all hooks together. So I should be building and replacing d3d9.dll and wined3d.dll both at the same time? Are there any others I should be building as well? I want to diagnose this as accurately as possible.
Yes, you should do a full rebuild, you can't drop compiled modules between different versions. A lot of times it will work, but you can't assume that.
http://bugs.winehq.org/show_bug.cgi?id=58358
Gcenx gcenx83@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gcenx83@gmail.com
--- Comment #16 from Gcenx gcenx83@gmail.com --- I did do a couple of rebuilds last night while talking to Zeb last night, even with the d3d10/11 Vulkan hack reverted the game didn't run.
Due to how long it had taken to download the game I wasn't able to do too much testing as I wanted a clean prefix between tests.
If the game is working in my wine-stable package and not the wine-devel package it won't be related to the d3d10/11 Vulkan hack as both packages have this patch applied.
I was able to get the game to launch when using CX MoltenVK so this might be due to a lack of geometry shaders in MoltenVK?
http://bugs.winehq.org/show_bug.cgi?id=58358
--- Comment #17 from Gcenx gcenx83@gmail.com --- This bug can be closed as invalid, this was caused by an incorrectly applied hack that was resolved in wine-devel-10.10 & will be resolved in wine-stable-10.0 with a rebuild.
-
WineHQ Bugzilla