wine-devel May 2011

wine-devel@winehq.org

79 participants
229 discussions

re: make "bisected" a keyword in bugzilla?
by Dan Kegel 08 Aug '11

08 Aug '11

I think it's a good idea. 'regression' isn't as strong as 'bisected'. Unless there are objections, I'll add the keyword on Monday.

11 15

Re: ws2_32: return an error in SO_CONNECT_TIME stub
by Dmitry Timoshkov 27 Jun '11

27 Jun '11

Austin English <austinenglish(a)gmail.com> wrote: > @@ -2554,7 +2554,7 @@ INT WINAPI WS_getsockopt(SOCKET s, INT level, > } > *(DWORD*)optval = pretendtime++; > *optlen = sizeof(DWORD); > - return ret; > + return SOCKET_ERROR; > } Filling out optval and optlen but returning SOCKET_ERROR doesn't make sense. Probably Eye-Fi doesn't change the return value. What kind of socket both of the applications do pass? -- Dmitry.

2 1

GSoC-2011: Implement Missing Mesh Functions in Wine’s D3DX9
by Michael Mc Donnell 17 Jun '11

17 Jun '11

Thanks for the comments Matteo! I have a few questions below. On Mon, May 30, 2011 at 2:45 PM, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > 2011/5/29 Michael Mc Donnell <michael(a)mcdonnell.dk>: >> On Sat, May 28, 2011 at 10:08 PM, Stefan Dösinger >> <stefandoesinger(a)gmx.at> wrote: >>> On Saturday 28 May 2011 19:55:55 you wrote: >>> >>>> It was implemented by setting the vertex declaration to null when the >>>> declaration is invalid. That seems to match what happens on Windows, >>>> because if a program has set an invalid declaration and then calls >>>> GetDeclaration or DrawSubset it will fail with an access violation. >>>> Should Wine also fail with an access violation or should it be >>>> slightly more graceful and return E_FAIL instead (which my new patch >>>> does)? >>> Yes, I think returning E_FAIL is a good idea, but write a WARN if >>> CreateVertexDeclaration fails or when you catch a NULL vdecl. A WARN will not >>> be shown by default(unlike a FIXME), it is used when the app does something >>> fishy but you think you handled it correctly. >>> >>>> + if (FAILED(hr)) >>>> + new_vertex_declaration = NULL; >>>> + >>>> + /* Free old vertex declaration */ >>>> + if (This->vertex_declaration) >>>> + IDirect3DVertexDeclaration9_Release(This->vertex_declaration); >>> In this situation you can just release the old decl before calling >>> CreateVertexDeclaration and pass &This->vertex_declaration to CreateVdecl. >>> That simplified the code a bit. Don't forget to set This->vertex_declaration to >>> NULL in case of an error though >> >> Ok I've simplified the code. I've also inserted three WARNs. I've >> skipped a WARN when freeing the mesh because that works fine on >> Windows with an invalid declaration. >> >>>> + /* Set the position type to color instead of float3 (invalid >>> declaration) */ >>>> + hr = mesh->lpVtbl->UpdateSemantics(mesh, declaration_wrong_type_color); >>>> + todo_wine ok(hr == D3D_OK, "Test UpdateSematics wrong type color, " >>>> + "got %#x expected D3D_OK\n", hr); >>> Is this really invalid? I don't know it on top of my head, but in general >>> types and usage are independent, especially with shaders. I don't see a check >>> in d3d9 or wined3d for this case. >> >> You're right it isn't invalid. It doesn't crash, it just doesn't draw >> anything. I've change that comment and re-ordered the tests. >> >>> Beyond that I think the patches look OK. I'd recommend to send them to wine- >>> devel one more time and then next week to wine-patches. Henri is on Vacation >>> this week, and he's usually more picky than I am. I also hope some of the >>> people who regularly contribute to d3dx9 will have a look and comment. >> >> Ok, I've attached the newest version. I'll let the patches sit here >> for a week, and start working on the other functions in the mean time. >> > > The patches are OK with me, just some nitpicking: That sounds great :-) > + testContext = HeapAlloc(GetProcessHeap(), 0, sizeof(struct TestContext)); > > We usually use something like HeapAlloc(GetProcessHeap(), 0, > sizeof(*testContext)); instead. Ok, I guess that's better in case the type of the variable changes at some point? > I think you can remove some obvious comments (like /* Create the test > mesh */). Also, check your whitespaces. Is it too much or too little whitespace? Could you give me an example? Thanks!

5 13

GSoC: dinput8 Action Mapping
by Lucas Zawacki 06 Jun '11

06 Jun '11

Hey guys. So last week I finally got a good understanding of dinput as a whole and nailed some trivial cases of action mapping, the ones with the keyboard. I'm sending a series of patches so everyone can take a look before I try commiting them. Please note that these contain a partial implementation of EnumDevicesBySemantics, BuildActionMap and SetActionMap, and also they're only the A versions. There are some tests for EnumDevicesBySemantics. I'm not too sure of how to code the tests that require user input... I hope it's not a nuisance to read the code split in 7 files, if you guys want I can merge it in one big diff. On a bright note, this patchset results in the input working for these two games: * http://appdb.winehq.org/objectManager.php?sClass=application&iId=3678 * http://appdb.winehq.org/objectManager.php?sClass=application&iId=7919 Cheers :)

3 3

CD-ROM ioctl support on MacOS?
by Joerg-Cyril.Hoehle＠t-systems.com 06 Jun '11

06 Jun '11

Hi, what's the state of CD-ROM support on the Mac? ntdll/cdrom.c contains quite a few #ifdef apple. I'm asking because the mcicda currently uses these ioctl: 1. READ_RAW 2. READ_TOC 3. READ_Q -> POSITION MCICDA could be changed to avoid the third one entirely -- when using the dsound output. Would that be enough to use mcicda on MacOS to play music? Thanks for your help, Jörg Höhle

2 3

Re: [1/8] d3d8: Use D3DPOOL <-> WINED3DPOOL enum conversion functions instead of implicit conversions (clang)
by Alexandre Julliard 05 Jun '11

05 Jun '11

Frédéric Delanoy <frederic.delanoy(a)gmail.com> writes: > +static inline D3DPOOL d3dpool_from_wined3dpool(WINED3DPOOL type) > +{ > + switch (type) > + { > + case WINED3DPOOL_DEFAULT: return D3DPOOL_DEFAULT; > + case WINED3DPOOL_MANAGED: return D3DPOOL_MANAGED; > + case WINED3DPOOL_SYSTEMMEM: return D3DPOOL_SYSTEMMEM; > + case WINED3DPOOL_SCRATCH: return D3DPOOL_SCRATCH; > + case WINED3DPOOL_FORCE_DWORD: return D3DPOOL_FORCE_DWORD; > + } > + return (D3DPOOL) type; > +} > + > +static inline WINED3DPOOL wined3dpool_from_d3dpool(D3DPOOL type) > +{ > + switch (type) > + { > + case D3DPOOL_DEFAULT: return WINED3DPOOL_DEFAULT; > + case D3DPOOL_MANAGED: return WINED3DPOOL_MANAGED; > + case D3DPOOL_SYSTEMMEM: return WINED3DPOOL_SYSTEMMEM; > + case D3DPOOL_SCRATCH: return WINED3DPOOL_SCRATCH; > + case D3DPOOL_FORCE_DWORD: return WINED3DPOOL_FORCE_DWORD; > + } > + return (WINED3DPOOL) type; > +} I still don't see the point of that kind of switch statement. To be honest I don't see either why we even need different enum types in the first place. -- Alexandre Julliard julliard(a)winehq.org

4 7

Re: wineoss.drv: Add mmdevapi driver.
by Gerald Pfeifer 04 Jun '11

04 Jun '11

I believe commit be332326ba8fc3def406c5f29adf04fbe9a83976 Author: Andrew Eikum <aeikum(a)codeweavers.com> Date: Wed Apr 27 09:12:36 2011 -0500 is causing the following build failures on my nightly FreeBSD testers: mmdevdrv.c:463:20: error: 'AFMT_S24_PACKED' undeclared (first use in this function) mmdevdrv.c:476:16: error: 'AFMT_FLOAT' undeclared (first use in this function) mmdevdrv.c:854:24: error: 'AFMT_FLOAT' undeclared (first use in this function) mmdevdrv.c:863:24: error: 'AFMT_S24_PACKED' undeclared (first use in this function) mmdevdrv.c:1084:24: error: 'SNDCTL_DSP_HALT' undeclared (first use in this function) Looks like some autoconfigury is not working or incomplete? Gerald

3 6

Re: wineoss.drv: Support platforms that do not feature AFMT_FLOAT.
by Andrew Eikum 04 Jun '11

04 Jun '11

On 05/07/2011 07:46 PM, Gerald Pfeifer wrote: > As we have seen from a related thread on wine-devel, FreeBSD's > implementation of OSS is slightly, though not a lot, different from > what current Linux distributions feature. > > This patch addresses one such case, AFMT_FLOAT which does not exist > on FreeBSD (yet?), and I'm sure other non-Linux systems. I guess we can add this workaround. I don't know how far down this road we should be willing to go, though. I would consider the FreeBSD implementation broken: it deviates from the spec as stated by the authors. So this seems to be their bug, not ours. How far should we bend over backwards to accommodate their bug? Anyways this is a tiny hassle, so I'm fine with it. Perhaps you should consider filing a FreeBSD bug? Thanks Gerald. Andrew > I created this diff with more context so that it becomes immediate that > this patch is harmless in that AFMT_FLOAT is handled as an error case > for system not providing it. > > Gerald > > --- > dlls/wineoss.drv/mmdevdrv.c | 4 ++++ > 1 files changed, 4 insertions(+), 0 deletions(-) > > diff --git a/dlls/wineoss.drv/mmdevdrv.c b/dlls/wineoss.drv/mmdevdrv.c > index 789cb1e..254a119 100644 > --- a/dlls/wineoss.drv/mmdevdrv.c > +++ b/dlls/wineoss.drv/mmdevdrv.c > @@ -504,25 +504,27 @@ static int get_oss_format(const WAVEFORMATEX *fmt) > case 32: > return AFMT_S32_LE; > } > return -1; > } > > if(fmt->wFormatTag == WAVE_FORMAT_IEEE_FLOAT || > (fmt->wFormatTag == WAVE_FORMAT_EXTENSIBLE&& > IsEqualGUID(&fmtex->SubFormat,&KSDATAFORMAT_SUBTYPE_IEEE_FLOAT))){ > if(fmt->wBitsPerSample != 32) > return -1; > > +#ifdef AFMT_FLOAT > return AFMT_FLOAT; > +#endif > } > > return -1; > } > > static WAVEFORMATEX *clone_format(const WAVEFORMATEX *fmt) > { > WAVEFORMATEX *ret; > size_t size; > > if(fmt->wFormatTag == WAVE_FORMAT_EXTENSIBLE) > size = sizeof(WAVEFORMATEXTENSIBLE); > @@ -935,27 +937,29 @@ static HRESULT WINAPI AudioClient_GetMixFormat(IAudioClient *iface, > > if(This->dataflow == eRender) > formats = This->ai.oformats; > else if(This->dataflow == eCapture) > formats = This->ai.iformats; > else > return E_UNEXPECTED; > > fmt->Format.wFormatTag = WAVE_FORMAT_EXTENSIBLE; > if(formats& AFMT_S16_LE){ > fmt->Format.wBitsPerSample = 16; > fmt->SubFormat = KSDATAFORMAT_SUBTYPE_PCM; > +#ifdef AFMT_FLOAT > }else if(formats& AFMT_FLOAT){ > fmt->Format.wBitsPerSample = 32; > fmt->SubFormat = KSDATAFORMAT_SUBTYPE_IEEE_FLOAT; > +#endif > }else if(formats& AFMT_U8){ > fmt->Format.wBitsPerSample = 8; > fmt->SubFormat = KSDATAFORMAT_SUBTYPE_PCM; > }else if(formats& AFMT_S32_LE){ > fmt->Format.wBitsPerSample = 32; > fmt->SubFormat = KSDATAFORMAT_SUBTYPE_PCM; > }else if(formats& AFMT_S24_LE){ > fmt->Format.wBitsPerSample = 24; > fmt->SubFormat = KSDATAFORMAT_SUBTYPE_PCM; > }else{ > ERR("Didn't recognize any available OSS formats: %x\n", formats); > return E_FAIL; > >

2 1

RFC: d3d9: Increment the reference count of the IDirect3D9 instance when creating a device.
by Andrew Nguyen 01 Jun '11

01 Jun '11

The Pathologic demo in bug 21552 expects that the reference count of a IDirect3D9 instance is incremented after a successful call to CreateDevice with the instance. Does my proposed fix for d3d8 and d3d9 manage the reference count of the device parent appropriately? In particular, I'm concerned about the slightly cumbersome acquisition of the pointer to the parent instance within the Release call for the Direct3D device interface. Is the overall location of the AddRef/Release calls correct, and should I be doing something differently when the device tries to decrement the parent reference count?

2 1

Re: infosoft/tests: COM cleanup in infosoft.c.
by Marvin 01 Jun '11

01 Jun '11

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=11350 Your paranoid android. === WVISTAADM (32 bit infosoft) === infosoft.c:183: Test failed: failed infosoft.c:197: Test failed: failed === W2K8SE (32 bit infosoft) === infosoft.c:183: Test failed: failed infosoft.c:197: Test failed: failed === W7PRO (32 bit infosoft) === infosoft.c:183: Test failed: failed infosoft.c:197: Test failed: failed === W7PROX64 (32 bit infosoft) === infosoft.c:183: Test failed: failed infosoft.c:197: Test failed: failed === W7PROX64 (64 bit infosoft) === infosoft.c:183: Test failed: failed infosoft.c:197: Test failed: failed

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel May 2011