[Bug 13481] New: ChangeDisplaySettings can't set *only* BPP

[wine-bugs at winehq.org]

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 at winehq.org
        ReportedBy: rolf at 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.


-- 
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.