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.