http://bugs.winehq.org/show_bug.cgi?id=31014
--- Comment #3 from Ralf Jung ralfjung-e@gmx.de 2012-06-30 04:36:45 CDT --- (In reply to comment #2)
(In reply to comment #1)
I did some more analysis on this:
Audiosurf calls wined3d_device_get_display_mode with a swapchain_idx of 0. In current wine, this means that the returned hr will be uninitialized, and the mode structure left unchanged - so there's garbage in there (I added a FIXME to get these values):
That doesn't sound right, what version of Wine are you using / what does your wined3d_device_get_display_mode() actually look like?
I am sorry, this was an artefact created by reverting only parts of the patches.
I will attach a patch that fixes the issue here. The difference in the return value (compared to current origin/master) is that refresh_rate and scanline_ordering are set to 0 - that is, however, not the problem. Even forcing those to be 0 after calling wined3d_swapchain_get_display_mode does not make it work.
What confused me during debugging is that the device-specific display mode function calls the swapchain-specific one, which however uses only the device pointer to call the adapter-specific function. But then, I don't know the API ;-)
I noticed during my debugging and logging that the function in question is called *very* often - more than 700 times in my short logfile. Could it be that always calling EnumDisplaySettingsExW is just so much slower than using the data from the device?
From the description, this sounds like some variant of bug 30184, does http://bugs.winehq.org/attachment.cgi?id=40780 make it any better?
I will try it and let you know.