> > visual.c:1194: Test failed: Got color 00efebe7, expected 0080 or
> > near
> > visual.c:1200: Test failed: Got color 00efebe7, expected 00ff or
> > near
> I have run the tests in valgrind, and there's a crash somewhere. Could
> be
> related
It seems that the tests crash in the libglcore.
> I guess this is http://bugs.winehq.org/show_bug.cgi?id=10221
Ya, as Henri said this is most likely a driver bug and we can't do anything
against it.
> ../../../tools/runtest -q -P wine -M ddraw.dll -T ../../.. -p
> ddraw_test.exe.so
> visual.c && touch visual.ok
> fixme:win:EnumDisplayDevicesW (
The d3d9 one is probably a driver bug, not sure about the ddraw one.
If it's much of an issue, it might be worth to run the tests using
Mesa instead.
On Wed, Aug 13, 2008 at 12:18 AM, H. Verbeet <[EMAIL PROTECTED]> wrote:
>> d3d9:visual.c
> What kind of failures are you seeing there, and with which drivers?
> (The test should at least pass with recent Mesa versions as long as
> the GLSL extensions are disabled)
I guess this is http://bugs.wine
2008/8/12 Dan Kegel <[EMAIL PROTECTED]>:
> d3d9:visual.c
What kind of failures are you seeing there, and with which drivers?
(The test should at least pass with recent Mesa versions as long as
the GLSL extensions are disabled)
Am Dienstag, den 12.08.2008, 10:58 -0700 schrieb Dan Kegel:
> The list is currently
> user32:msg.c
> user32:input.c
Same problems here. Metacity 2.23.21, compiled myself.
> d3d9:visual.c
> ddraw:visual.c
The last two are really nasty. Take a look at ddraw/tests/visual.c:2624.
It makes a kind o
So, one of the things one learns when writing a
patch robot is that flaky tests are very annoying.
Each time it gets a new git tree,
the robot does five baseline "make -k test" runs,
remembers the tests that fail, and doesn't penalize
patches for failing any of those tests. See
http://code.google
