April 2011 - Wine-Devel - list.winehq.org

Re: wined3d/state: Treat unrecognized D3DZBUFFERTYPEs as WINED3DZB_TRUE.

by Henri Verbeet

Nope.

April 26, 2011

Re: wined3d/query: Add support for timestamp queries.

by Henri Verbeet

On 26 April 2011 19:35, Adam Martinson <amartinson(a)codeweavers.com> wrote: > +#include "d3d10.h" I don't think so.

April 26, 2011

Re: wined3d: Track when the FBO is dirty. (try 4)

by Henri Verbeet

This is mostly the same as the previous version.

April 26, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Dylan Smith

On Tue, Apr 26, 2011 at 4:15 PM, Michael Mc Donnell <michael(a)mcdonnell.dk>wrote: > > > Completely unimplemented: > > - ConvertPointRepsToAdjacency > > - ConvertAdjacencyToPointReps > > - UpdateSemantics > > Ok so I can still work on ConvertPointRepsToAdjacency and > ConvertAdjacencyToPointReps? > > Yes. I had no plans on working on them. Nor do I plan on fully implementing CloneMesh, so I'll try to submit what I have in order to let you can build on it.

April 26, 2011

Re: GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9

by Michael Mc Donnell

On Tue, Apr 26, 2011 at 6:34 AM, Dylan Smith <dylan.ah.smith(a)gmail.com> wrote: > On Sun, Mar 20, 2011 at 1:09 PM, Michael Mc Donnell > <michael(a)mcdonnell.dk> wrote: >> I would like implement some of the missing mesh functions in Wine's >> D3DX9 for Google Summer of Code 2011. I would like to implement the >> following functions: >> - CloneMesh >> - CloneMeshFVF >> - ConvertPointRepsToAdjacency >> - ConvertAdjacencyToPointReps >> - GenerateAdjacency > > Hi Michael, > > Sorry for not noticing your before, but it seems as if some work that > I have been doing as some overlap with your proposed Google Summer of > Code project. I have implemented GenerateAdjacency, and partially > implemented CloneMesh{,FVF} for the basic case where the vertex > formats are exactly the same, but I am still trying to incrementally > submit my work to wine-patches. That's ok Dylan, better now than in a couple of months :-). I only picked those functions because I had a good idea about how to implement them. I just got accepted into GSoC 2011, so I'll try to find some other mesh functions in D3DX9 to implement. > I'll try to avoid stepping on your toes in future. Don't worry about it. No offence taken :-) > Completely unimplemented: > - ConvertPointRepsToAdjacency > - ConvertAdjacencyToPointReps > - UpdateSemantics Ok so I can still work on ConvertPointRepsToAdjacency and ConvertAdjacencyToPointReps? > There are also plenty of other functions. Just try `grep stub > d3dx9_36.spec | grep Mesh` for Mesh related functions. There are also > some unimplemented functions to create meshes for certain shapes (e.g. > D3DXCreateTorus, D3DXCreatePolygon). Thanks for the suggestions. It seems like Misha Koshelev is working on D3DXCreateTorus, and David Adam is working on D3DXCreatePolygon? I'll have a look around and see if there are any other good functions. Any other suggestions from anyone are of course welcome. Cheers, Michael

April 26, 2011

Re: winealsa.drv: Add mmdevapi driver.

by Andrew Eikum

On 04/26/2011 11:26 AM, Andrew Eikum wrote: >> dump_fmt >> + TRACE("cbSize: %u\n", fmt->cbSize); >> Old Wine code contains several comments about never ever reading cbSize >> in the WAVE_FORMAT_PCM case because it's a potential read past the structure >> and may cause a segmentation fault. Is it not a valid concern anymore? >> >> WAVEFORMATEX contains the cbSize slot. However if the winmm:wave* functions >> pass through their argument to mmdevapi, it may well end up to be the smaller >> PCMWAVEFORMAT only. > > You're right, and I wasn't careful enough about this. WinMM has a test > for it, and I'll add a similar one to mmdevapi. > Hm, to my surprise it seems MS no longer does this check as of Win7. When cbSize is out of bounds, it returns a strange error on Vista (AUDCLNT_E_DEVICE_INVALIDATED) and crashes on Win7: https://testbot.winehq.org/JobDetails.pl?Key=10587 When cbSize is in bounds, everything works fine: https://testbot.winehq.org/JobDetails.pl?Key=10588 So, I think I'll leave it crashing. We'll just have to be careful in WinMM to pass a valid structure through.

April 26, 2011

Re: winealsa.drv: Add mmdevapi driver.

by Andrew Eikum

Thanks for your comments, Jörg. On 04/26/2011 06:00 AM, Joerg-Cyril.Hoehle(a)t-systems.com wrote: > + fmt->Format.nSamplesPerSec = 41100; > + fmt->nSamplesPerSec != 41100&& > 44100. IIRC, there was an error exactly like this somewhere in the old drivers. Silly typo. Thanks. > But why does your IsFormatSupported only accept 48kHz, 44.1, 22.050, etc.? > Do the native drivers behave like this? Is this a reasonable subset such > that Wine behaves the same on most HW (disregarding CONTINUOUS_RATE)? ALSA is a giant practical joke of an API, and one of its many punchlines is that it doesn't actually give you any information about what sample rates are supported. On my desktop, for example, it reports the minimum sample rate as 4 kHz, and the maximum sample rate is MAX_INT kHz. Of course if you try to set a device with MAX_INT kHz sample rate (or anything over 48 kHz on my machine), it fails. So, simply checking that the requested value is within the range doesn't work. If you provide an invalid rate, ALSA doesn't give you a preferred rate back. Instead, it just fails. At this point I got pretty tired of ALSA's brand of humor and just went with the easy and probably good enough solution of only supporting a few common rates. > dump_fmt > + TRACE("cbSize: %u\n", fmt->cbSize); > Old Wine code contains several comments about never ever reading cbSize > in the WAVE_FORMAT_PCM case because it's a potential read past the structure > and may cause a segmentation fault. Is it not a valid concern anymore? > > WAVEFORMATEX contains the cbSize slot. However if the winmm:wave* functions > pass through their argument to mmdevapi, it may well end up to be the smaller > PCMWAVEFORMAT only. You're right, and I wasn't careful enough about this. WinMM has a test for it, and I'll add a similar one to mmdevapi. > IsFormatSupported > MSDN says that CoTaskMemFree will be used to free the output > variable ppClosestMatch. Wine uses clone_format=>HeapAlloc to allocate > it. Does CoTaskMemFree match HeapAlloc? I'd have expected > CoTaskMemAlloc, but I've never used these OLE functions. I suspect it doesn't matter, as it works in every case I've tried, but perhaps that should be changed. I'll change it for consistency, but for clarity, would anyone more familiar with CoTaskMem* want to comment? > + switch(fmt->wBitsPerSample){ > + case 64: > + if(!snd_pcm_format_mask_test(formats, SND_PCM_FORMAT_FLOAT64_LE)){ > vs. > + if(fmt->wBitsPerSample != 32){ > + WARN("Unsupported float size: %u\n", fmt->wBitsPerSample); > IsFormatSupported may accept 64 bit fp samples, but Initialize will refuse it. > Did you add that code to hear about sound cards that process > 64 bits so we know they exist? You're right, Initialize should know how to map 64-bit floats to SND_PCM_FORMAT_FLOAT64_LE. Just an oversight, and I'll queue a fix. I'll also go through the other drivers and improve them in the same ways. Thanks again, Andrew

April 26, 2011

Re: [PATCH 3/4] dsound: Implement capture buffer based on mmdevapi, try 2

by Andrew Eikum

It would be nice if you used more descriptive variable names. For example: +struct IDirectSoundCaptureBufferImpl +{ + DWORD buf_size; + DWORD pos; What units are these sizes and positions in? Frames? Bytes? Time? What position is being represented here, read, write, or something else? Using more descriptive names helps when understanding and verifying code like this: + pos1 = This->pos; + if (This->playing) + { + pos2 = This->format->nSamplesPerSec / 100; + pos2 *= This->format->nBlockAlign; + pos2 += pos1; + if (!This->looping && pos2 > This->buf_size) + pos2 = 0; + else + pos2 %= This->buf_size; + } + else + pos2 = pos1; + pos2 %= This->buf_size; Are all of these positions in Bytes? I hope so... (Remember this has tripped things up in the past, see bbbf72ddcb). If everything is always in bytes, maybe make a note of that near the variable declarations, and then verify that it's true throughout the code. Also, why is pos1 a separate variable here? These patches are all missing quite a lot of error handling, which really makes me hesitate. Especially on some important calls: + IAudioCaptureClient_GetBuffer(buf->cap_dev, &data, &read, &flags, &pos, 0); + IAudioClient_GetDevicePeriod(This->dev, &default_period, &min_period); + IAudioClient_Start(This->dev); Knowing when these functions fail will help debugging if something goes wrong. Much worse to suddenly crash four function calls later due to invalid default_period value than to just error out appropriately when the error occurs. This doesn't matter a whole lot, but I think it would be more clear to use a separate object here, instead of a separate refcount: struct IDirectSoundCaptureBufferImpl { IDirectSoundCaptureBuffer8 IDirectSoundCaptureBuffer8_iface; - LONG ref; + IDirectSoundNotify IDirectSoundNotify_iface; + LONG ref, notify_ref; If not, at least a comment explaining why two refcounts are needed. Obviously a test would improve it even more, if one doesn't already exist.

April 26, 2011

Re: cmd: handle spaces in directory names in del /s

by Alexandre Julliard

Dan Kegel <dank(a)kegel.com> writes: > @@ -771,13 +771,16 @@ BOOL WCMD_delete (WCHAR *command, BOOL expectDir) { > > DIRECTORY_STACK *nextDir; > WCHAR subParm[MAX_PATH]; > + static const WCHAR quoteW[] = { '"', 0 }; > > /* Work out search parameter in sub dir */ > - strcpyW (subParm, thisDir); > + strcpyW (subParm, quoteW); > + strcatW (subParm, thisDir); > strcatW (subParm, fd.cFileName); > strcatW (subParm, slashW); > strcatW (subParm, fname); > strcatW (subParm, ext); > + strcatW (subParm, quoteW); That's ugly. File names should not go through command processing again. -- Alexandre Julliard julliard(a)winehq.org

April 26, 2011

Re: requesting review and/or testing for directsound changes

by Stefan Dösinger

Hi, I did some testing with the shiny new sound code. I tested with and without pulseaudio, with current dsound, native(win7) dsound and your precompiled binary. Pulseaudio + current code: Sound effects are sometimes garbled or partially played, but are on time and not repeated No Pulseaudio + current code: not tested Pulseaudio + maarten's binary: Old sound effects played over and over again, after a few seconds the summed up effects morph into static No Pulseaudio + maarten's binary: Crashed once, on a 2nd try it also loops effects all over, sums up to static after a few seconds Pulseaudio + native dsound: Effects play OK, but sometimes the sound is interruped and afterwards delayed. Delays sum up No pulseaudio + native: works perfectly. BF1942 had a mouse regression recently. I tried to disable xinput(by commenting out the HAVE_XINPUT*_H defines in config.h) and recompiling but this did not help. I also tried native dinput(with and without xinput), but this did not change anything. The symptom is that the mouse is mostly moving at the edges of the screen and can be moved away from there only very carefully. This worked two weeks ago. I'll try to run a regression test. On Tuesday 26 April 2011 12:50:52 Maarten Lankhorst wrote: > Hi all, > > with http://repo.or.cz/w/wine/multimedia.git and > http://repo.or.cz/w/openal-soft.git you should be able to get the > benefits of openal-soft's mixer while continuing to use whatever driver > you want for mmdevapi. As a result directsound will only support > openal-soft, but multi channel is suddenly supported, as is support for > the floating point format. 24-bits and 32-bits int are currently not, > but as soon as that capability is added to openal-soft.git wine will > have a nice working dsound implementation with support for a lot of > things that are missing now. The resampling code will also be a lot > better and you should expect a higher quality when resampling is used. > > The capture changes should work nicely, and I don't expect a problem > with that, since it's based on openal. The rendering code is essentially > reviving the old dsound-openal, and outputting it to mmdevapi. > > Note: 24-bits and 32-bits int are unsupported and will most likely cause > a crash, disable the #if 1 in get_fmtstr_EXT to prevent lying about > support. It was put in place so the wine dsound tests would pass. > > A dsound.dll.so binary with openal-soft.git statically linked in can be > found at: http://www.astro.rug.nl/~lankhorst/dsound.dll.so > > If you're using pulseaudio, patch your 32-bits alsa-plugins with the > attached patch, or silence may occur when using the new mmdevapi drivers. > > Cheers, > Maarten

April 26, 2011