http://bugs.winehq.org/show_bug.cgi?id=13481
Summary: ChangeDisplaySettings can't set *only* BPP Product: Wine Version: 1.0-rc2 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: minor Priority: P4 Component: gdi32 AssignedTo: wine-bugs@winehq.org ReportedBy: rolf@neuberrosoft.de
Created an attachment (id=13402) --> (http://bugs.winehq.org/attachment.cgi?id=13402) Test case, w Makefile and full NetBeans project tree
Given an "incomplete" DEVMODE structure, with no fields set except for dmBitsPerPel, and the corresponding flag in dmFields (i.e. dmFields=DM_BITSPERPEL), ChangeDisplaySettings as implemented in Wine doesn't replicate the behaviour of a real Windows system correctly.
A real Windows system happily executes the call and returns DISP_CHANGE_SUCCESSFUL. Display bit-depth will be adjusted, if it was different to begin with, while the remaining parameters stay as they were. After the call, resolution and refresh are still whatever the user selected as the desktop resolution. Even on 2k/XP, which are sometimes happy to drop the refresh rate to 60Hz, the refresh rate remains constant, which is one of the reasons I found this type of call to be useful sometimes. I've tested this today with a MingW-built executable, and found the above to be accurate for Windows 98SE, Windows 2000 SP4 and Windows XP SP2, irrespective of whether the initial desktop bit depth is 16 bit or 32 bit.
On Wine (wine-1.0-rc2 on Ubuntu 8.04), the very same call to ChangeDisplaySettings, made from the same executable, will fail with a return code of -2 (DISP_CHANGE_BADMODE).
I've attached my test case. It will make the call and pop up a message box with the results of the call. I used the i586-mingw32msv-gcc compiler provided by the "mingw32" package in the official Ubuntu repositories. The project was set up in NetBeans 6 so the Makefile is somewhat convoluted, but it doesn't appear as if the build process requires NetBeans. Just navigating to the directory and running make seems to work. The executable ends up in dist/Debug/GNU-Windows/.
Priority of the bug isn't high. I've used it in some graphics-library code, but only in debug builds for my own testing purposes. I'm not aware of publically available shipping programs that hit on this. Reported anyway, for correctness's sake.
The app-level workaround is to query the current desktop mode and fill in the DEVMODE structure more completely. Beyond the scope, but you get the idea.
I'm new to this Bugzilla stuff, so if I forgot some vital piece of info, please be gentle. I want to be helpful.
http://bugs.winehq.org/show_bug.cgi?id=13481
--- Comment #1 from Rolf Neuberger rolf@neuberrosoft.de 2008-05-27 11:26:20 --- Created an attachment (id=13403) --> (http://bugs.winehq.org/attachment.cgi?id=13403) Test case, main .c file only (already included in the above)
http://bugs.winehq.org/show_bug.cgi?id=13481
--- Comment #2 from Rolf Neuberger rolf@neuberrosoft.de 2008-05-27 12:00:37 --- Forgot to mention that I didn't run make clean before taring the stuff up, and so the test case executable is contained in the first attachment as well. It's in wine-bugreport-cds-bpponly/dist/Debug/GNU-Windows.
So if you don't MingW installed and don't want to go through the trouble of adjusting the Makefile, you can just use that.
http://bugs.winehq.org/show_bug.cgi?id=13481
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |testcase
http://bugs.winehq.org/show_bug.cgi?id=13481
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Component|gdi32 |winex11.drv Resolution| |WONTFIX
--- Comment #3 from Vitaliy Margolen vitaliy@kievinfo.com 2008-05-27 21:46:50 --- What's the point of this? Wine can not change BPP since X does not support that.
Closing wontfix - there is nothing Wine can fix here.
http://bugs.winehq.org/show_bug.cgi?id=13481
James Hawkins truiken@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #4 from James Hawkins truiken@gmail.com 2008-05-27 21:52:46 --- Closing.
http://bugs.winehq.org/show_bug.cgi?id=13481
--- Comment #5 from Rolf Neuberger rolf@neuberrosoft.de 2008-05-28 06:47:57 --- (In reply to comment #3)
What's the point of this? Wine can not change BPP since X does not support that.
Then why does Wine's EnumDisplaySettings advertise 16 bpp modes alongside 32 bpp modes on the 32 bpp X server I'm running here, even in virtual desktop mode? And how does ChangeDisplaySettings execute changes to all of those modes without returning error codes?
Closing wontfix - there is nothing Wine can fix here.
Wine does not have to *change* bpp to emulate this more accurately. There is no reason for a request for 32 bpp to fail when X is already running in 32 bpp to begin with, and even when bpp doesn't match, Wine never cared anyway. The inaccuracy isn't even about the attempted bpp "change". It's about treating sparsely (but correctly) filled DEVMODE structures differently from DEVMODE structures that contain a resolution specification *plus* the same bpp setting. Wine's CDS implementation will happily accept those "more complete" DEVMODEs, even though the "Wine can not change BPP" issue would apply to them just the same, if it applied to anything at all in Wine, which it really doesn't.
Wine could accept the call without a failure code, at least when emulating a virtual desktop, or best case if the requested bpp {can be provided on|matches} the current X server settings, and fail if the request is impossible to fill. That's what Windows does anyway. Keeping in line with general CDS behaviour in Wine when it comes to bpp mismatches, it might just as well unconditionally accept the call.
To give you a bit of background for the purpose of this, it's to make sure an OpenGL pixel format including a stencil buffer will be available. That is not the case on a 16 bpp desktop, but on a 32 bpp desktop such modes become available. This is from within a library context, where a misbehaved client app may have switched around display settings itself to display splash screens or a "launcher".
http://bugs.winehq.org/show_bug.cgi?id=13481
--- Comment #6 from Rolf Neuberger rolf@neuberrosoft.de 2008-05-28 09:28:18 --- Created an attachment (id=13430) --> (http://bugs.winehq.org/attachment.cgi?id=13430) Proposed patch
... since I figured you guys are too busy with the 1.0 run-up to bother with such an obscure issue.
Patch to bring Wine CDS behaviour closer to Windows CDS behaviour. Replicates preexisting provision of a default BPP to also produce default width and height. In effect, resolution will be taken from default mode (stored in registry) when not provided in DEVMODE struct and the call goes through successfully.
The request will still be rejected and the call will fail if the CDS_UPDATEREGISTRY flag is specified. This is because the current code does not support partial writes to the default mode storage within the registry, but that's beyond the scope of this patch, and so this measure had to be taken to prevent storing a 0*0 mode as the default.
Solving this secondary issue would allow a more complete and accurate resolution.
I want to point out thought that this same secondary issue also affects default bpp and default refresh rates. Consider these two pseudo-sequences: 1) CDS(640,480,32,60,CDS_UPDATEREGISTRY) CDS(800,600,0,0,CDS_UPDATEREGISTRY)
2) CDS(640,480,16,85,CDS_UPDATEREGISTRY) CDS(800,600,0,0,CDS_UPDATEREGISTRY)
(difference is bpp and refresh in first call) You'd expect the system to keep the refresh rate and bpp settings from the first line, even if it's only a fake setting with no actual effect on the X server. However, the mode stored in the registry after both of these sequences execute is *the same* on wine-1.0-rc2. When the current code needs to provide its own (default) bpp and refresh rates (dmFields flag clear), it no longer uses the parameters as restrictions when picking a new target mode. It insteads selects the first match of only the remaining parameters, starting from the beginning of its mode list. Then it writes back *all* parameters from the mode it ended up picking into the registry. Thus the final default mode ends up being the same, even though bpp and refresh should end up different.
http://bugs.winehq.org/show_bug.cgi?id=13481
--- Comment #7 from Dmitry Timoshkov dmitry@codeweavers.com 2008-05-28 09:39:10 --- Adding the tests to Wine's test suite demonstrating that the patch is correct is always welcome.
http://bugs.winehq.org/show_bug.cgi?id=13481
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=13481
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |andreas@braml.org
--- Comment #8 from Anastasius Focht focht@gmx.net --- *** Bug 31080 has been marked as a duplicate of this bug. ***
-
wine-bugs＠winehq.org