ddraw: ddrawmodes test failures (all platforms)

Stefan Dösinger stefan at codeweavers.com
Tue Jan 29 13:40:59 CST 2008


Am Dienstag, 29. Januar 2008 19:16:38 schrieb Reece Dunn:
> On 26/01/2008, Paul Vriens <paul.vriens.wine at gmail.com> wrote:
> > Stefan Dösinger wrote:
> > > Am Samstag, 26. Januar 2008 13:20:44 schrieb Henning Gerhardt:
> > >> Am 01/26/2008 12:50 PM schrieb Stefan Dösinger:
> > >>> Am Samstag, 26. Januar 2008 12:05:09 schrieb Reece Dunn:
> > >>>> Hi,
> > >>>>
> > >>>> Looking at the ddrawmode test failures, they are because the test is
> > >>>> checking that if the DDSD_REFRESHRATE flag is set, then
> > >>>> dwRefreshRate is not 0. However, on many of the test platforms at
> > >>>> http://test.winehq.org/data/200801161000, they are reporting a
> > >>>> refresh rate of 0.
> > >>>>
> > >>>> Are these bogus - due to them running on VM - or is this a valid
> > >>>> case?
> > >>>
> > >>> I have never seen such failures on my real hardware(Windows XP or
> > >>> Vista), so I think they fail due to VM drivers. I'll re-run the tests
> > >>> to make sure the tests didn't break somewhen.
> > >>
> > >> I don't think so. My system (called xanlosch) is a real XP system with
> > >> an ATI Mobility 9700 graphic card with one of the latest ATI drivers
> > >> (7.11er catalyst drivers). Maybe an ATI driver issue?
> >
> > Just ran the test on my real WinXP box (NVIDIA GeForce FX 5200) with the
> > same results:
> >
> > http://test.winehq.org/data/200801161000/xp_XPSP2-HOME-NL/ddraw:ddrawmode
> >s.txt
>
> The options for this are:
>
>    1.  Remove this test case.
>
>    2.  Set the data member being checked to 0xdeadbeef or similar
> value, then check if the data member has been set. Ideally, this would
> need to be done before every call into the callback function where
> this check is happening, but this may not be possible.
>
> I prefer option 2, as this tests if the data member is set (even if it
> is set to 0) when the specified flag is set.
I'll send a patch once Alexandre is back, as currently it doesn't make much 
sense flooding wine-patches. I actually intended option 1 first, but now that 
you mentioned it I think 2 is better.



More information about the wine-devel mailing list