wine-devel October 2013

wine-devel@winehq.org

60 participants
246 discussions

Request for a possible inclusion of the Wineasio driver?
by Joakim Hernberg 15 Oct '13

15 Oct '13

I am the maintainer of a driver for Wine on Linux called Wineasio. I'd like to find a home for the code and am hoping to convince you of adding it to the Wine codebase. ASIO is an API developed by Steinberg for supporting low latency audio hardware under Windows. Each hardware manufacturer uses Steinberg's SDK to create a driver supporting their own hardware. Software using the API is normally audio related such as Digital Audio Workstations, virtual instruments and other music production software. On Linux, Wineasio interfaces directly with the Jack audio API, and runs on all hardware supported by Jack, which nowdays is the vast majority on audio hardware supported in linux. On OS/X a derrived driver called Coreasio has been created, and is in use by Image-line's FLS port. Jack runs on Linux, Solaris, FreeBSD, OS/X, iOS and Windows, so in theory it ought to be possible to support Wineasio on all platforms supported by Wine. I don't know the details on how Coreasio works, but in the case of Wineasio, the driver links directly to the Jack server's client libs, so there is no need to alter any existing parts of Wine's audiostack nor to reimplement and maintain a Jack driver for Wine itself. The only change needed is to include the driver in the source tree. The driver implements all the core functionality of the API, only some optional and obscure parts of the API are missing. It has been in use for years on 32 bit Wine and does not appear to have any showstopping bugs, if any at all. I've personally used it for over a year on 64 bit Wine, and I know of some other people who use it without problems on 64 bit too. The API is stable and hasn't been changed nor expanded by Steinberg for many years. It has been tested with audio production software like Reaper and FLS, with virtual instruments, amp simulations and other FX software from companies like Native Instruments, Ik Multimedia, Toontracks, Celemony and many others. The biggest problem is that the ASIO API is defined in the asio.h header file distributed by Steinberg in their ASIO SDK, and that the license explicitly forbids the distribution of any component by a third party. I imagine that this situation is not new to the Wine project and similar to other SDKs needed. I have a header file which I have created by compiling the driver without including asio.h, and then typing in the needed defines and structures while consulting asio.h. The header makes the driver work in both 32 and 64 bit wine. I propose to undertake the following: 1. Fix up the Wineasio code to confirm to Wine conventions and coding practices. 2. Merge it into Wine for conditional compilation on linux with Jack as a dependency. 3. Work together with the Wine project to merge in coreasio support for use on OS X. The latest sourcecode of the project is available at: git://git.code.sf.net/p/wineasio/code wineasio-git or as a tarball from: http://sourceforge.net/projects/wineasio/ Is this something that has any chance of getting accepted into Wine? -- Joakim

2 1

We're in at FOSDEM!
by Jeremy White 15 Oct '13

15 Oct '13

Hey folks, I thought I'd let everyone know that I applied for and we have been granted a room at FOSDEM again this year. I'm going to send a 'Call for Papers' separately. Cheers, Jeremy

1 0

Video Mixing Renderer 7
by Michael Müller 15 Oct '13

15 Oct '13

Hi, I am wondering what would be the best way to handle programs which rely on the Video Mixing Renderer 7 (quartz.dll) as it's supposed to be available on XP and later, but Wine contains only an implementation of version 9. The program I am speaking of is Silverlight which uses the VMR 7 Interface to create a filter graph and then queries for the IAMCertifiedOutputProtection interface. I am currently using a hack fix to get around this by returning a VMR9 instance when a VMR7 is requested and implementing the missing subinterfaces (which are only part of VMR7). This solution is clearly not perfect and I am searching for a better way to get around this issue. The most similar way to Windows would be to completely rewrite the current implementation of the VMR9 as VMR7 using DirectDraw, which would take a lot of time and most probably end up in having a lot of duplicate code. I am wondering whether using d3d9 for VMR7 would also be an acceptable solution. We could move all the d3d9 related stuff to a separate file so that VMR7.c and VMR9.c only offer the version specific interfaces and use the same code internally. This shouldn't be a big problem since the differences between the VMR7 and VMR9 interfaces are often only very small. Though it would not completely fit the behavior of windows. I am open for other ideas on how to solve the problem, but as Silverlight does not even use the VMR7 object for playing the video but only to check for the graphic driver certificate I don't think it would justify to rewrite everything using Direct Draw if there are no other programs needing this interface. Best Regards, Michael Müller

1 0

Re: wined3d: Initialize map_desc in wined3d_surface_map
by Marvin 15 Oct '13

15 Oct '13

1 0

Re: d3d9: update locked_rect only if wined3d_surface_map succeeded (try 3)
by Nikolay Sivov 15 Oct '13

15 Oct '13

On 10/15/2013 18:57, Lasse Rasinen wrote: > According to debugging output, Artemis Spaceship Bridge Simulator 2.0 > calls LockRect twice on the same texture (for whatever reason) and crashes. > > http://bugs.winehq.org/show_bug.cgi?id=34271 > > The return values are cleared explicitly --- game is playable. > > Now with appropriate assignments and test output. > --- > dlls/d3d9/surface.c | 9 +++++++-- > dlls/d3d9/tests/device.c | 4 ++++ > 2 files changed, 11 insertions(+), 2 deletions(-) > > diff --git a/dlls/d3d9/surface.c b/dlls/d3d9/surface.c > index 99f0b0f..20ccc68 100644 > --- a/dlls/d3d9/surface.c > +++ b/dlls/d3d9/surface.c > @@ -293,8 +293,13 @@ static HRESULT WINAPI d3d9_surface_LockRect(IDirect3DSurface9 *iface, > hr = wined3d_surface_map(surface->wined3d_surface, &map_desc, rect, flags); > wined3d_mutex_unlock(); > > - locked_rect->Pitch = map_desc.row_pitch; > - locked_rect->pBits = map_desc.data; > + if (SUCCEEDED(hr)) { > + locked_rect->Pitch = map_desc.row_pitch; > + locked_rect->pBits = map_desc.data; > + } else { > + locked_rect->Pitch = 0; > + locked_rect->pBits = NULL; > + } > > return hr; > } > diff --git a/dlls/d3d9/tests/device.c b/dlls/d3d9/tests/device.c > index 02b4174..90d5c38 100644 > --- a/dlls/d3d9/tests/device.c > +++ b/dlls/d3d9/tests/device.c > @@ -5404,6 +5404,10 @@ static void test_lockrect_invalid(void) > ok(SUCCEEDED(hr), "Failed to lock surface with rect NULL, hr %#x.\n", hr); > hr = IDirect3DSurface9_LockRect(surface, &locked_rect, NULL, 0); > ok(hr == D3DERR_INVALIDCALL, "Got unexpected hr %#x.\n", hr); > + locked_rect.pBits = (BYTE *)0xdeadbeef; > + hr = IDirect3DSurface9_LockRect(surface, &locked_rect, NULL, 0); > + ok(!SUCCEEDED(hr) && locked_rect.pBits == NULL, "Failed to clear pBits (%p)\n", > + locked_rect.pBits); > hr = IDirect3DSurface9_UnlockRect(surface); > ok(SUCCEEDED(hr), "Failed to unlock surface, hr %#x.\n", hr); > It looks like you could use existing LockRect() call that's already tested as failing. Also I think FAILED() is a preferred way to test HRESULT value for failure, but as existing code does - you could also test for exact failure code.

2 1

Re: d3d9: update locked_rect only if wined3d_surface_map succeeded (try 3)
by Marvin 15 Oct '13

15 Oct '13

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 https://newtestbot.winehq.org/JobDetails.pl?Key=2783 Your paranoid android. === w864 (32 bit device) === device.c:5409: Test failed: Failed to clear pBits (DEADBEEF) device: unhandled exception c0000005 at 742814C8 === w864 (64 bit device) === device.c:5409: Test failed: Failed to clear pBits (00000000DEADBEEF) device: unhandled exception c0000005 at 000007F84EDD90EB

2 1

Re: d3d9: update locked_rect only if wined3d_surface_map succeeded (try 3)
by Stefan Dösinger 15 Oct '13

15 Oct '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2013-10-15 16:57, schrieb Lasse Rasinen: > - locked_rect->Pitch = map_desc.row_pitch; - > locked_rect->pBits = map_desc.data; + if (SUCCEEDED(hr)) { + > locked_rect->Pitch = map_desc.row_pitch; + > locked_rect->pBits = map_desc.data; + } else { + > locked_rect->Pitch = 0; + locked_rect->pBits = NULL; + } You can handle this in wined3d/surface.c, wined3d_surface_map. Also, please follow the code style of the existing code. Curly brackets go in their own line. > + locked_rect.pBits = (BYTE *)0xdeadbeef; + hr = > IDirect3DSurface9_LockRect(surface, &locked_rect, NULL, 0); + > ok(!SUCCEEDED(hr) && locked_rect.pBits == NULL, "Failed to clear > pBits (%p)\n", + locked_rect.pBits); For the sake of completeness, please also test locked_rect.Pitch and port the test to d3d8. Ddraw already has a test in dsurface.c. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSXVwzAAoJEN0/YqbEcdMw1CQP/2Lk2v78Ws8BGh1x4MvaXj/x YhJQ1d44bqP9B8+H7E3NKWuwZ6ywNmxvH+Mq59nbNKdfBrxvTezIA2PDLEsNwWJa hl/Q4St61K1XkExmu+48tyxtT3BS8P2g60Z50V8VIfrUh/3qqquXq79tki9XqYSr vtuFLuJyHECzYq7hQ+BZqbudwSSf42ZQfX0wNpa4wuZ2uX/PzA4ku0R/zvHzaMTh HoOrlIxX9hvCF/y5y7v0SAeYT83nMCkUBOZ8EMoDqv81btLDCqdFedtlFz2gTO0P O2vaGzSH0NPU+umIU9rEXUwq3H2gJdFcTG4FujQNsoVSaliXz24OzVTCEc1PvuWz eo+zMhxfG05xNSsb6Yh+fATnOPP6YDWYukS42kmalZ+V5WGlwxxKd4jgfONjCqzH JsIcqbmlxkWN9bPB9k3mIMMDHZ1PClI3GFm1XVMnc4Vas2/FF/IAAK/yPpIV2O/R fJkz4PKcha8P9V/yNlGJrmHYq/Dy7mW9xANmQ4gKv9wm0iqHoUGrDorX7OptskHL ua0pOFmWIXHRtzFysctZ/w6QkKX/e9Vwh/hRWIBhN2JOliu5AZuqQESbqe/rCwZR Flje6p9RaxlqgIzxxK1GQawpQ05NP3y8oS1MIe+mGr4c6sk8KO5d6aUgNVo4jcdY 4OAnKqN3lNbqDZgNEg91 =32E8 -----END PGP SIGNATURE-----

1 0

Re: d3d9: update locked_rect only if wined3d_surface_map succeeded (try 2)
by Marvin 15 Oct '13

15 Oct '13

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 https://newtestbot.winehq.org/JobDetails.pl?Key=2776 Your paranoid android. === w864 (32 bit device) === device.c:5409: Test failed: Failed to clear pBits (DEADBEEF)device.c:5588: Tests skipped: Failed to create surface for format D3DFMT_R8G8B8 (hr 0x8876086c), skipping tests. device: unhandled exception c0000005 at 740D14C8 === w864 (64 bit device) === device.c:5409: Test failed: Failed to clear pBits (00000000DEADBEEF)device.c:5588: Tests skipped: Failed to create surface for format D3DFMT_R8G8B8 (hr 0x8876086c), skipping tests. device: unhandled exception c0000005 at 000007F84EDD90EB

1 0

Re: [00/11] msi/tests: Prepare action.c for the switch to -D__WINESRC__.
by Marvin 15 Oct '13

15 Oct '13

1 0

Re: [10/11] msi/tests: Prepare msi.c for the switch to -D__WINESRC__.
by Marvin 15 Oct '13

15 Oct '13

1 0

← Newer
1
...
12
13
14
15
16
17
18
...
25
Older →

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 October 2013