February 2012 - Wine-Devel - list.winehq.org

Re: [PATCH 1/2] ddraw/tests: Add some IDirect3DViewport interface tests (try 2)

by Henri Verbeet

On 2 February 2012 14:57, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +static ULONG get_refcount(IUnknown *test_iface) > +{ > + IUnknown_AddRef(test_iface); > + return IUnknown_Release(test_iface); > +} ... > + LONG ref; ... > + ref = get_refcount((IUnknown *)d3d); > + ok(ref == 2, "IDirect3D refcount is %d\n", ref); Well yeah, get_refcount() returns ULONG now, but you should fix the type of "ref" and the format strings as well.

Feb. 2, 2012

Re: [PATCH] ddraw/tests: Add some IDirect3DViewport interface tests

by Henri Verbeet

On 2 February 2012 12:56, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > +static LONG get_refcount(IUnknown *test_iface) > +{ > + IUnknown_AddRef(test_iface); > + return IUnknown_Release(test_iface); > +} Release is supposed to return a ULONG. > + hr = IDirect3DViewport_QueryInterface(viewport, &IID_IDirect3DViewport2, (void **)&viewport2); > + ok(SUCCEEDED(hr) || broken(hr == E_FAIL), "Failed to QI IDirect3DViewport2, hr %#x.\n", hr); I think this would make the test fail on old versions of ddraw that simply don't know about IDirect3DViewport2. > + hr = IDirect3DViewport3_QueryInterface(viewport2, &IID_IUnknown, (void **)&unknown); This looks like it was intended to be called on viewport3. > + /* FIXME: This test suggests that IDirect3D, IDirect3D2 and IDirect3D3 are linked > + * to IDirectDraw. However, they are linked to whatever interface is used to QI the > + * first IDirect3D? interface. If DDraw1 is replaced with DDraw4 here the tests break */ Makes sense. I'm not sure it really should be part of this patch though.

Feb. 2, 2012

please test native behaviour with (un)pluggable audio devices

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, please run the mmdevapi render and capture testsuites while unplugging (or deactivating) audio HW. I'd like to hear how native behaves prior to implementing error handling in Wine's drivers. One way to run the testsuites is as follows: 1. Download winetest-xyz.exe from test.winehq; 2. winetest-xyz.exe /x will extract all exes into some directory; 3. set WINETEST_DEBUG=2 4. set WINETEST_INTERACTIVE=1 (not used yet, but soon) 5. mmdevapi_test.exe render 6. mmdevapi_test.exe capture Esp., I'd like to know whether ReleaseBuffer ever signals an error or if it's always the job of GetBuffer to do so. Then I'd like to know whether primitives such as GetBufferSize fail too when the device is unplugged. Note that the testsuite may crash because it doesn't expect loosing devices mid-way. Thank you, Jörg Höhle

Feb. 2, 2012

Re: Wine automated testing update

by Lei Zhang

On Wed, Feb 1, 2012 at 12:11 PM, Jeremy White <jwhite(a)codeweavers.com> wrote: > 1. Test qemu/kvm with a few Windows versions to see if it'll work. I've had good luck running 32-bit Windows in qemu + kvm. You'll probably need to add -rtc=localtime. If you plan to run it headless and connect via the build in vnc, add -usbdevice tablet.

Feb. 2, 2012

Re: dinput: Support INFINITE as number of effect iterations (try 2)

by Vitaliy Margolen

On 02/01/2012 11:17 AM, Marcel Hasler wrote: > 2012/1/30 Marcel Hasler<mahasler(a)gmail.com>: > > I've submitted a final patch. I don't think there's anything more I > can do to improve it. Looks fine. Vitaliy.

Feb. 2, 2012

Wine automated testing update

by Jeremy White

Hi Folks, At the last Wine conference, I volunteered to find a home for the WineTestBot that Ge's brother has been hosting, and to take over the Buildbot that Dan and Austin have been so diligently maintaining. This is an update on that project, mostly to help keep my procrastinating self moving it along. First, we have a lovely set of hardware; 4 servers, in a dedicated rack, with a dedicated static ip to the outside world. One server is the gateway, 2 are dedicated Linux test systems (with nice fast processor + gpus), and one is a beefy system capable of running many VMs. The plan was to move the existing VMWare based WineTestBot to this hardware and simply get the existing system up and running on the new hardware. Here we hit our first snag; the VMWare folks are not willing to provide a permanent license for VMWare to us. So, we've shifted gears, and are exploring whether something like qemu + kvm would be a sufficient alternate. I've done a little of this work, and Maarten is hopefully going to help me try converting the existing VMs to see if we can save any hassle by doing a conversion. In parallel, I learned a great deal about buildbot and the buildbot system that Dan has built. There are two especially valuable and useful functions provided by this buildbot: the first is essentially a patch watcher; a process that catches simple mistakes (e.g. build errors on different architectures, and so on). The second is more powerful and is encapsulated by the 'dotests.sh' shell script. The dotests.sh script does a good job of basically running make test and noticing any test failures outside of 'the usual ones'. There is an infrastructure for Buildbot is a good tool, and I invested a lot of energy into it (as have Dan and Austin). However, Alexandre has persuaded me that we should first explore integrating the dotest.sh functionality into the existing WineTestBot, as that would allow us to have a very simple clean web page, and would also allow us to integrate most cleanly with Alexandre's back end tools. Of course, WineTestBot is Perl code, and my Perl fu is low. So I have recently asked Francois to help with that effort as well. So the basic plan is as follows: 1. Test qemu/kvm with a few Windows versions to see if it'll work. 2. If so, modify WineTestBot to use qemu instead of vmware. (This is 'easy' because the WineTestBot code nicely isolates the VM functions, but 'hard', because VMWare provides some APIs that may have to be replicated). 3. Migrate WineTestBot to the new hardware stack 4. Write new code to run 'dotests.sh' as part of WineTestBot Cheers, Jeremy

Feb. 1, 2012

Re: Profiing windows apps

by Stefan Dösinger

Hi, Am Dienstag, 31. Januar 2012, 21:51:01 schrieb Ralph Little: > IDirectDraw * pDD = NULL; > IDirectDrawSurface * pDDSPrimary = NULL; > DDSURFACEDESC ddsd; Take a look at dlls/ddraw/tests/ddraw*.c > ...<initialisation etc>... Make sure you use the version of the interface the game uses. There are some behavioral differences between them. E.g. with zbuffers DDSURFACEDESC(IDirectDraw, IDirectDraw2) has dwZBufferBitDepth(and DDSD_ZBUFFERBITDEPTH), while DDSURFACEDESC2(IDirectDraw4, IDirectDraw7) always uses a pixel format. As far as I can see from the bug report the game is using IDirectDraw4. > memset(&ddsd, 0, sizeof(ddsd)); > ddsd.dwSize = sizeof(ddsd); > ddsd.dwFlags = DDSD_CAPS | DDSD_PIXELFORMAT | DDSD_HEIGHT | DDSD_WIDTH; > ddsd.ddsCaps.dwCaps = DDSCAPS_SYSTEMMEMORY | DDSCAPS_ZBUFFER; Is it really trying to create a system memory z buffer? (Ok, I just saw this in the logs attached to the bug report - that's really odd). > ddsd.dwHeight = 600; > ddsd.dwWidth = 800; > ddsd.ddpfPixelFormat.dwSize = sizeof(DDPIXELFORMAT); Try to set ddsd.ddpfPixelFormat.dwZBufferBitDepth to e.g. 16 and ddsd.ddpfPixelFormat.dwZBitMask to 0x0000ffff. Keep dwFlags set to 0. Als try to keep dwSize at 0. > I assume that if the caller specifies DDSCAPS_ZBUFFER, the you must also > specify some PIXEL format information. DDSD_PIXELFORMAT is present, but > there are no format flags. Basically that, or dwZBufferBitDepth. See zbufferbitdepth_test in dlls/ddraw/tests/dsurface.c for some tests on this. (Don't add any new tests there btw - use tests/ddraw*.c). > I have to admit that I am a bit of a novice when it comes to DirectX so any > guidance here would be helpful. I see that the lpSurface is NULL, which I > thought was an error. However, I see that this is optional if the caller > wishes the system to manage the surface memory. Correct. > Any error returned by this function the Sims at this point to causes it to > crash. Therefore, it seems to me that if it succeeds in Windows, it must > have passed something different. If only we could see the source :D If the testing doesn't reveal anything, look out for IDirectDraw::GetCaps calls in the logs or IDirect3Dx::EnumZBufferFormats. IDirectDraw::GetCaps returns a DDCAPS structure which has dwZBufferBitDepths containing some flags for z buffer bit depths. EnumZBufferFormats calls a callback multiple times with available DDPIXELFORMAT structures. The application may not like some flags we set there. Also please attach a full +ddraw log to the bug report. If it is too big compress it. bzip2 should do a pretty decent job, if all fails try lrzip.

Feb. 1, 2012

Re: dinput: Support INFINITE as number of effect iterations (try 2)

by Marcel Hasler

2012/1/30 Marcel Hasler <mahasler(a)gmail.com>: > > The only official documentation I can find is in > Documentation/input/ff.txt and it doesn't say anything about the max > for 'value'. I had a look at the kernel source instead. > input_handle_event() in input.c only checks whether 'value' is >= 0 > for EV_FF (which is why the event is ignored for INFINITE), > ml_ff_playback() in ff-memless.c sets 'state->count' (which is an > 'int') to 'value' and ml_get_combo_effect() finally counts down > 'state->count' until it reaches zero. So there really is no limit here > (accept what's given by the data type). > > Marcel I've submitted a final patch. I don't think there's anything more I can do to improve it. Marcel

Feb. 1, 2012

Re: [PATCH] winealsa: snd_card_get_name uses strdup (Valgrind).

by Michael Stefaniuc

Lauri Kenttä wrote: > On 2012-02-01 17:00, Christian Costa wrote: >> In that case you don't need the if (!err) condition to free the buffer >> otherwise you leak the string return by strdup. > > Yeah, I didn't think this through and screwed up. :P > > I also noticed now that Jörg Höhle already deemed this strdup solution > ugly in his previous try. Luckily Michael Stefaniuc sent a finer patch > #83376. Still not good enough. But at least we forced Alexandre to fix it himself ;) bye michael

Feb. 1, 2012

Re: [PATCH] winealsa: snd_card_get_name uses strdup (Valgrind).

by Lauri Kenttä

On 2012-02-01 17:00, Christian Costa wrote: > In that case you don't need the if (!err) condition to free the > buffer > otherwise you leak the string return by strdup. Yeah, I didn't think this through and screwed up. :P I also noticed now that Jörg Höhle already deemed this strdup solution ugly in his previous try. Luckily Michael Stefaniuc sent a finer patch #83376. -- Lauri Kenttä

Feb. 1, 2012