On Tue, 20 Sep 2011, Charles Davis wrote:
On Sep 20, 2011, at 3:11 PM, Stefan Dösinger wrote:
gdi32/dc user32/monitor
No Xvidmode support, so Get/SetDeviceGammaRamp fail. There's a win_skip for that already. Should we change it to skip(), or ignore it until we have a quartz driver? User32/monitor also fails because it can't change the display mode.
Key words: "stock X11 server". XQuartz has much better support for this. You should be using that.
That's what I have been told too so I documented it there: http://wiki.winehq.org/ConformanceTests#MacOSX
However XQuartz 2.6.3 (the latest) would systematically become 'non responsive' at some random point during the tests on my Leopard Mac Mini (GMA 950 graphics). So I downgraded to XQuartz 2.6.1 which at least lets me complete the WineTest run.
[...]
mmdevapi/capture
Various Set*Volume calls fail
I know that some CoreAudio devices actually don't have software volume controls. Optical out, for example. For these devices, Set*Volume will always fail. Not sure if that's what 's happening in your case, though.
My Mac Mini uses an optical audio connection and indeed I cannot set the volume on the Mac. Yet I have no failures in mmdevapi/capture (or in any other sound test for that matter).
ws2_32/sock
A mixture of test failures and unexpected successes. From what I can tell, Wine's WinSock implementation seems to depend on several nuances of Linux's BSD sockets implementation that are different from the original 4.xBSD implementation (from which most others, including WinSock itself, are derived).
That's my impression too given that it fails on Solaris and FreeBSD too (quite a paradox as that should be the original 'BSD sockets' <g>).
Note also that the firewall will also ask whether to allow incoming network access for some of the tests. I would really like information on how to best deal with that.
Also the OOB tests are not reliable at all, even on Windows, so this test won't be reliable anywhere until that's fixed: http://test.winehq.org/data/tests/ws2_32:sock.html