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
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.
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
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.so if run
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)
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
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 of
