30 Jan
2007
30 Jan
'07
1:10 p.m.
When I run the dlls/d3d9/device conformance test on Windows in VMware, I
get a trace telling me that IDirect3D9_CreateDevice() failed and
returned 0x8876086c. This seems to be because Windows has trouble
changing the screen resolution when running in VMware (though it's
perfectly capable of doing it when I go through the control panel).
But when I run the test in Wine I'm getting a test failure because:
* IDirect3D9_CreateDevice() did not change the screen resolution
* but it returned success so that the screen size checks fail
That's because XRandR fails to change the resolution (for whatever
reason, it's irrelevant here). Wine detects that but does not report the
information to the upper layers. So I have made a couple of patches:
* the first one detects when XRandR, XVidMode or some low level
routine fails to change the screen resolution, and propagates this so
ChangeDisplaySettingsEx() returns an error
* the second one modifies
IWineD3DDeviceImpl_CreateAdditionalSwapChain() so it detects when
ChangeDisplaySettingsEx() propagates that error upstream too
Now the dlls/d3d9/device test succeeds on my machine (all while loudly
complaining something is wrong):
[...]
err:xrandr:X11DRV_XRandR_SetCurrentMode Resolution change not successful
-- perhaps display has changed?
fixme:d3d9:IDirect3DDevice9Impl_CreateAdditionalSwapChain (0x1c4358)
call to IWineD3DDevice_CreateAdditionalSwapChain failed
fixme:d3d9:IDirect3D9Impl_CreateDevice (0x171448) D3D Initialization
failed for WineD3DDevice 0x174ee8
device.c:741:could not create device, IDirect3D9_CreateDevice returned
0x8876086c
device.c: 245 tests executed (0 marked as todo, 0 failures), 0 skipped.
I have attached the relevant patches. Does this look ok to the DirectX
gurus?
--
Francois Gouget
fgouget(a)codeweavers.com
31 Jan
31 Jan
9:25 a.m.
On 30/01/07, Francois Gouget <fgouget(a)codeweavers.com> wrote:
I have attached the relevant patches. Does this look
ok to the DirectX
gurus?
At least the wined3d part looks ok to me, although we should probably
be cleaning up the GL context as well, there and in the other places
where we return.
10:42 a.m.
Am Mittwoch 31 Januar 2007 10:25 schrieb H. Verbeet:
On 30/01/07, Francois Gouget
<fgouget(a)codeweavers.com> wrote:
For some reason I didn't get the original patch, or I
accidentally deleted
it(more likely). Note that I have patches to rework the context creation and
initialization routines(for easier cleanup).
I do not know to what extend we want to catch screen res change failures. The
resolution? I'd say yes. Color depth? Propably no because we can't change it
anyway. Refresh rate? Don't think its important.
I have attached the relevant patches. Does this
look ok to the DirectX
gurus?
At least the wined3d part looks ok to me, although we should probably
be cleaning up the GL context as well, there and in the other places
where we return.
2 Feb
2 Feb
3:31 p.m.
Stefan Dösinger wrote:
Am Mittwoch 31 Januar 2007 10:25 schrieb H. Verbeet:
Yo can find it there:
http://www.winehq.org/pipermail/wine-devel/2007-January/053725.html
[...]
On 30/01/07, Francois Gouget
<fgouget(a)codeweavers.com> wrote:
For some reason I didn't get the original patch, or I
accidentally deleted
it(more likely). I have attached the relevant patches. Does this
look ok to the DirectX
gurus?
At least the wined3d part looks ok to me, although we should probably
be cleaning up the GL context as well, there and in the other places
where we return. I do not know to what extend we want to catch screen
res change failures. The
resolution? I'd say yes. Color depth? Propably no because we can't change it
anyway. Refresh rate? Don't think its important.
There's already some code dealing with color depth issues:
devmode.dmBitsPerPel = (bpp >= 24) ? 32 : bpp; /* Stupid XVidMode
cannot change bpp */
But there's another place where we deal with these issues differently:
if(devmode.dmBitsPerPel == 24) devmode.dmBitsPerPel = 32;
[...]
ret = ChangeDisplaySettingsExW(NULL, &devmode, NULL,
CDS_FULLSCREEN, NULL);
if (ret != DISP_CHANGE_SUCCESSFUL) {
if(devmode.dmDisplayFrequency != 0) {
WARN("ChangeDisplaySettingsExW failed, trying without the
refresh rate\n");
devmode.dmFields &= ~DM_DISPLAYFREQUENCY;
devmode.dmDisplayFrequency = 0;
ret = ChangeDisplaySettingsExW(NULL, &devmode, NULL,
CDS_FULLSCREEN, NULL) != DISP_CHANGE_SUCCESSFUL;
}
if(ret != DISP_CHANGE_SUCCESSFUL) {
return DDERR_INVALIDMODE;
}
}
--
Francois Gouget
fgouget(a)codeweavers.com
3:24 p.m.
H. Verbeet wrote:
On 30/01/07, Francois Gouget
<fgouget(a)codeweavers.com> wrote:
Is there some code that would show what cleaning the GL context entails?
I have looked at the other exit paths of CreateAdditionalSwapChain()
but the only relevant one only does stuff if object->frontBuffer != NULL
which cannot be the case there.
--
Francois Gouget
fgouget(a)codeweavers.com
I have attached the relevant patches. Does this
look ok to the DirectX
gurus?
At least the wined3d part looks ok to me, although we should probably
be cleaning up the GL context as well, there and in the other places
where we return.
5 Feb
5 Feb
5:58 a.m.
Am Freitag 02 Februar 2007 16:24 schrieb Francois Gouget:
Is there some code that would show what cleaning the
GL context entails?
I have looked at the other exit paths of CreateAdditionalSwapChain()
but the only relevant one only does stuff if object->frontBuffer != NULL
which cannot be the case there.
I have patches in my tree which change the context
creation, and they also
clean up properly in the case of an error(hopefully). I'll send them when
things get going again after Alexandre's return.
6313
days inactive
6319
days old
5 comments
3 participants
participants (3)
-
Francois Gouget -
H. Verbeet -
Stefan Dösinger