RFC: detecting wine drivers in the audio tests
m.b.lankhorst at gmail.com
Tue Apr 29 23:31:41 CDT 2008
2008/4/29 Robert Reif <reif at earthlink.net>:
> 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 manufacture.
> 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.
I don't know, the general idea is that whatever windows lets you do is
fine for wine, so I'm not 100% sure that testing for this is a good
idea, because it means in border cases windows programs can't rely on
those to return a correct or incorrect value either.
By the way you also used a C++ style comment, wine doesn't allow that.
More information about the wine-devel