Re: New and subtle ddraw:dsurface test failure
Hi W, On Monday 09 August 2010 12:31:45 wy...@volny.cz wrote: > Hi, > > > Do you mean this problem? > > ddraw:dsurface start ... > > Nope and nothing about 64bit (there was no change). I was initially > talking about changed result from last Friday. To be precise this > new information showed up under WinXP 32bit on nvidia 8600GT: > > > dsurface.c:3511: Test failed: IDirectDrawSurface_Flip returned > 0x0003 > dsurface.c:3528: Test failed: IDirectDrawSurface_Flip returned > 0x0003 > > And i had a slight feeling, that i saw you, Oldrich, doing some > changes in this are. Thus decided to substitute "paranoid android" > aka test...@testbot.winehq.org. > > Last note, intel card i915gm does not fail on this "Surface_Flip" > and thus i decided to pinpoint this issue for nvidia. Ah, now I see (just describe the full problem the first time, I don't have a witch ball :-)). The nvidia driver doesn't return DD_OK like it should (see http://msdn.microsoft.com/en-us/library/aa915446.aspx), but other non-error code. I cannot say if this is somehow/totally wrong, but for the test purposes this can be work-around by changing the mentioned "ok" line to something like ok(hr==DD_OK || broken(hr != DD_OK && SUCCEEDED(hr)), "text...") This tells the wine to be correct (hr==DD_OK), but allows windows tests to fail with the alternative result code. Could you please try it/test it? Thanks, Oldřich. > > > Regards, > W.
Re: [PATCH] quartz: implement AsyncReader_FindPin
On Sat, Aug 07, 2010 at 11:53:36AM +0200, David Adam wrote: > Hi, > > what about if ppPin is NULL? then it will crash spectacularly, which is exactly what the client throwing around invalid pointers deserves ;) the surrounding code assumes that it's passed valid pointers too. anyway, dshow seems to require this, so added a check locally > I think that this patch needs test cases to prove that it is correct? I'll try to write something, but i'm not familiar with wine/quartz API (i just wanted to get video playback in a game working :) ) so it might be problematic. anyway, i've looked around some more and it seems that this function can be shared for all IBaseFilter subclasses. same probably goes for some other, e.g. IBaseFilter_EnumPins. is there a reason they're not? Anton Khirnov signature.asc Description: Digital signature
Re: Wine users with a CD-ROM drive, please test
Jörg-Cyril : may be the driver doesn't support TMSF, and from/to fields must be provided in MSF would you mind trying that ? A+ -- -- Eric Pouech
Re: Should we expect Liberation fonts to be installed?
On Sun, Aug 8, 2010 at 8:58 PM, Scott Ritchie wrote: >> This might work for Linux, but these fonts are not installed on any >> MacOSX version that I'm aware of. This might break Wine useage for >> Macs. It might also break it for Solaris as well. > > It should only break in a way that makes it as bad as it currently is. Macs should already have the proper fonts installed, but it might take some config changes to use them properly. Seems more like a packaging issue. Along those lines, the hard drive space is cheap on this one. Seems like Wine packagers could just include the fonts and install them locally in c:\windows\fonts. More properly, we should probably try to detect a system installation of them since it'll probably exist and then fall back on installing them if it doesn't. Fonts are a pretty big usability issue, apps really don't behave properly without them. -Brian
Wine users with a CD-ROM drive, please test
Hi, Thank you for your test results so far. >>>mcicda.c:425: Test failed: SEEK to 00203A43 position last + length: >>>MCIERR_HARDWARE >>>mcicda.c:436: Test failed: PLAY from 1 notify: MCIERR_HARDWARE >> Same as Jeff, please see if one of you can identify which prior MCI command >> causes this. >Do you have any instructions how I can identify this? This sequence of commands worked for Jeff: open cdaudio alias c status c type track 1 set c time format tmsf seek c to start play c from 1 to 2 wait The sequence of commands that the tests use is below. I don't see anything there that explains MCIERR_HARDWARE. Perhaps it's a timing issue and the suite would work after adding a couple of Sleep()? Copy&Paste of this sequence into the mcishell (see bug 20232, comment #10) works for me. Does it generate MCIERR_HARDWARE on your machine? Can you try and eliminate commands until you reach a minimal set that generates the error (start with removing capability, info and notify)? open cdaudio alias c notify shareable capability c has video notify capability c can play capability c capability c 16385 capability c device type status c time format info c product wait notify status c media present status c mode status c mode status c ready info c product identity info c identity info c upc status c number of tracks status c length status c position status c position start notify status c position start track 1 notify play c from 00:02:00 to 00:01:00 notify resume c seek c wait seek c to start notify # # Perhaps use seek c to start notify wait set c video audio all off set c time format ms status c position start status c position start track 1 status c notify wait status c length track 1 set c door closed notify status c type track 1 # # skipping data track tests set c time format msf status c length track 20 # # Replace 20 with number of tracks here status c position track 20 # # Perhaps add status c mode (still seeking?) seek c to 24:55:74 # # Replace with position last track start + length seek c to 24:56:00 set c time format tmsf play c from 1 Thank you for your help, Jörg Höhle
Re: winepath bug without arguments?
On Monday 09 August 2010 01:23:24 pm Jerome Leclanche wrote: > Hi > > After fixing a bug in MPQEdit related to opening directories, I > noticed winepath returns a different result with and without quotes: > > a...@azura:~/.wine/drive_c$ winepath -w > a...@azura:~/.wine/drive_c$ winepath -w "" > C:\ > > With quotes it returns the current directory. Is that intended? If not > I'll open a bug... > > > > J. Leclanche Yes, it's intended. winepath converts zero or more arguments. An empty argument means "start from current dir... and print!" [pa...@bussard drive_c]$ winepath -w "" users "Program Files" C:\ C:\users C:\Program Files Paul
Re: New and subtle ddraw:dsurface test failure
Hi, > Do you mean this problem? > ddraw:dsurface start ... Nope and nothing about 64bit (there was no change). I was initially talking about changed result from last Friday. To be precise this new information showed up under WinXP 32bit on nvidia 8600GT: dsurface.c:3511: Test failed: IDirectDrawSurface_Flip returned 0x0003 dsurface.c:3528: Test failed: IDirectDrawSurface_Flip returned 0x0003 And i had a slight feeling, that i saw you, Oldrich, doing some changes in this are. Thus decided to substitute "paranoid android" aka test...@testbot.winehq.org. Last note, intel card i915gm does not fail on this "Surface_Flip" and thus i decided to pinpoint this issue for nvidia. Regards, W.
winepath bug without arguments?
Hi After fixing a bug in MPQEdit related to opening directories, I noticed winepath returns a different result with and without quotes: a...@azura:~/.wine/drive_c$ winepath -w a...@azura:~/.wine/drive_c$ winepath -w "" C:\ With quotes it returns the current directory. Is that intended? If not I'll open a bug... J. Leclanche
Re: New and subtle ddraw:dsurface test failure
2010/8/9 Roderick Colenbrander :
> 2010/8/8 Oldřich Jedlička :
>> Hi W,
>>
>> On Sunday 08 August 2010 11:21:35 wy...@volny.cz wrote:
>>> Hi,
>>>
>>> i
>> just noticed some new and subtle failure in ddraw:dsurface
>>> tests. I don't
>> know how closely you watch and study tests
>>> results, so i thought it might
>> be a good idea bring it the
>>> the light. Sorry if not ;-)
>>>
>>> Compared
>> WinXP 277040d92454 vs 8b2a403a7dc3 (latest vs last
>>> Friday).
>>>
>>>
>> Interestingly does not happen on Intel and nVidia 64bit. So
>>> the only
>> affected is nVidia 32bit.
>>
>> Do you mean this problem?
>>
>> ddraw:dsurface start -
>> -
>> dsurface.c:419: Tests skipped: Failed to create surface
>> dsurface.c:801:
>> Test failed: IDirectDraw7_QueryInterface returned 80004002
>> dsurface.c:808:
>> this is the last test seen before the exception
>> dsurface: unhandled
>> exception c005 at 00413A29
>> ddraw:dsurface done (4294967295)
>>
>> I've seen
>> this also during my first tests. From my understanding the problem of
>> unhandled exception is caused by query interface failure. For me it looks
>> like that DirectDraw7 isn't supported on the system
>> (E_NOINTERFACE).
>>
>> Oldřich.
>>
>
> I'm not sure how usable 64-bit DirectDraw is. At the time XP64 came
> out, DirectDraw was already deprecated and Direct3D9 was the standard.
> I'm not sure how much effort Microsoft put in 64-bit DirectDraw (it
> wouldn't make sense to use it). Perhaps some IE plugins (or IE itself)
> use DirectDraw and that could be why there is some support.
>
> More investigation is needed on what is supported in 64-bit
> DirectDraw. The DirectDraw 3D tests seem to fail correctly, so at
> least 3D is not around. There is likely some limited 2D support
> though. It shouldn't be that hard to fix the tests.
Something like this -- I haven't tested this on affected Win64 systems.
- Reece
diff --git a/dlls/ddraw/tests/dsurface.c b/dlls/ddraw/tests/dsurface.c
index 76bfc7e..6e1efe4 100644
--- a/dlls/ddraw/tests/dsurface.c
+++ b/dlls/ddraw/tests/dsurface.c
@@ -797,7 +797,7 @@ static void GetDDInterface_1(void)
ret = IDirectDraw_QueryInterface(lpDD, &IID_IDirectDraw4, (void **) &dd4);
ok(ret == DD_OK, "IDirectDraw7_QueryInterface returned %08x\n", ret);
ret = IDirectDraw_QueryInterface(lpDD, &IID_IDirectDraw7, (void **) &dd7);
-ok(ret == DD_OK, "IDirectDraw7_QueryInterface returned %08x\n", ret);
+ok(ret == DD_OK || broken(ret == E_NOINTERFACE) /* some Win64 platforms */, "IDirectDraw7_QueryInterface returned %08x\n", ret);
ref1 = getref((IUnknown *) lpDD);
ok(ref1 == 1, "IDirectDraw refcount is %d\n", ref1);
@@ -805,8 +805,16 @@ static void GetDDInterface_1(void)
ok(ref2 == 1, "IDirectDraw2 refcount is %d\n", ref2);
ref4 = getref((IUnknown *) dd4);
ok(ref4 == 1, "IDirectDraw4 refcount is %d\n", ref4);
-ref7 = getref((IUnknown *) dd7);
-ok(ref7 == 1, "IDirectDraw7 refcount is %d\n", ref7);
+if (dd7) /* maybe NULL on Win64 platforms */
+{
+ref7 = getref((IUnknown *) dd7);
+ok(ref7 == 1, "IDirectDraw7 refcount is %d\n", ref7);
+}
+else
+{
+ref7 = 0;
+win_skip("IDirectDraw7 not supported.");
+}
ret = IDirectDrawSurface2_GetDDInterface(dsurface2, &dd);
@@ -814,7 +822,8 @@ static void GetDDInterface_1(void)
ok(getref((IUnknown *) lpDD) == ref1 + 1, "IDirectDraw refcount was increased by %d\n", getref((IUnknown *) lpDD) - ref1);
ok(getref((IUnknown *) dd2) == ref2 + 0, "IDirectDraw2 refcount was increased by %d\n", getref((IUnknown *) dd2) - ref2);
ok(getref((IUnknown *) dd4) == ref4 + 0, "IDirectDraw4 refcount was increased by %d\n", getref((IUnknown *) dd4) - ref4);
-ok(getref((IUnknown *) dd7) == ref7 + 0, "IDirectDraw7 refcount was increased by %d\n", getref((IUnknown *) dd7) - ref7);
+if (dd7) /* maybe NULL on Win64 platforms */
+ok(getref((IUnknown *) dd7) == ref7 + 0, "IDirectDraw7 refcount was increased by %d\n", getref((IUnknown *) dd7) - ref7);
ok(dd == lpDD, "Returned interface pointer is not equal to the creation interface\n");
IUnknown_Release((IUnknown *) dd);
@@ -825,7 +834,7 @@ static void GetDDInterface_1(void)
IDirectDraw_Release(dd2);
IDirectDraw_Release(dd4);
-IDirectDraw_Release(dd7);
+if (dd7) IDirectDraw_Release(dd7);
IDirectDrawSurface2_Release(dsurface2);
IDirectDrawSurface_Release(dsurface);
}
