RFC: detecting wine drivers in the audio tests
reif at earthlink.net
Tue Apr 29 23:06:14 CDT 2008
The returned result of some audio functions on windows may be
inconsistent because a driver may actually supply the returned value.
This presents a problem for the wine regression tests because a buggy
driver may return an unexpected result which causes the test to fail.
One way around this is to accept known failures as OK but that reduces
the usefulness of the test for wine because it may allow wine bugs to
slip in. I'm proposing the we determine if we are running on wine by
defining a wine manufactures id and checking for that id in the test.
If a wine driver is found, don't accept a failure as OK. The returned
result should be well defined and any failure is unacceptable. However,
if the driver is not a wine driver and there are known buggy windows
drivers that return specific errors, we can check for that and not fail
the test. This should be easier than maintaining a database of known
broken drivers and black listing them.
I am concerned that requiring 100% wine regression test success on
windows is not practical when there are broken windows drivers out
there. Accepting the failures as success is not good for wine because
it may allow buggy wine drivers to also pass. I think we should hold
wine audio drivers to higher standards than the typical audio card
I am suppling a minimal patch to the alsa driver and a single wave test
to illustrate this concept. I hope this allows valid tests to remain in
spite of buggy windows drivers.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the wine-devel