March 2014 - Wine-Devel - list.winehq.org

Re: how to build wine with USB support ?

by Uwe Bonnes

>>>>> "Alois" == Alois Schlögl <alois.schloegl(a)gmail.com> writes: Alois> Hi I'm trying to use USB devices for Data acquisition on Alois> wine. The recording software is proprietary, but runs on Alois> wine. (It IgorPro with some binary called FPulse, and MultiClamp Alois> Commander 700B). The problem occurs only when trying to connect Alois> to the recording device through USB. How is the device accessed? Is it offering a serial device (comX)? Is it perhaps using the FTDI device and the ftd2xx driver? Or is it using an own kernel mode driver? Only when using an own kernel mode driver, [1] is needed. If it is a serial device, add the device to the wine configuration. If it is using the ftd2xx driver, I can send you a patch to add a wine dll that translates the windows ftd2xx calls to linux ftd2xx calls. Perhaps run a "WINEDEBUG=+relay log" to see how the device is accessed. Alois> I've already found the page [1] and trying to build wine with the Alois> recommended patch. Unfortunately, the current patches [2] do not Alois> apply cleanly to the most recent version of wine-git. Therefore, Alois> I'm asking what the recommended approach is ? Alois> Is there a more recent set up patches ? The once from [2] have Alois> been updated last in Jun 2012 ? Or would you recommend using the Alois> sources of wine from that date ? Probably using a equal old wine would be best if you need [1]. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

March 17, 2014

how to build wine with USB support ?

by Alois Schlögl

Hi I'm trying to use USB devices for Data acquisition on wine. The recording software is proprietary, but runs on wine. (It IgorPro with some binary called FPulse, and MultiClamp Commander 700B). The problem occurs only when trying to connect to the recording device through USB. I've already found the page [1] and trying to build wine with the recommended patch. Unfortunately, the current patches [2] do not apply cleanly to the most recent version of wine-git. Therefore, I'm asking what the recommended approach is ? Is there a more recent set up patches ? The once from [2] have been updated last in Jun 2012 ? Or would you recommend using the sources of wine from that date ? Kind regards, Alois [1] http://wiki.winehq.org/USB [2] ftp://ftp.etersoft.ru/pub/people/amorozov/usb/current/

March 17, 2014

Re: [PATCH 5/5] wined3d: Remove the version parameter.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-03-17 11:34, schrieb Stefan Dösinger: > Although we could think this one step further and consider removing > the key and instead implement this functionality with an > opengl32.dll = disabled override. Actually, this might not be a good idea. There's still the use case of using our ddraw on Windows with 2D only support where dll overrides are not available. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTJulkAAoJEN0/YqbEcdMw7VQP/Aw0dNTVwrLvHSh7V8Z8qzQe RZfjbvb4BfcpdwtJBh2qRO5rCLqc127WbID8rq032WVxKohKGfWq+yMFdIk6XJCV nUo6E/a4jhYE/02zPrN5hjquxD4jV4VGhb4kHh72Lj1gs6aDqgXQzEqEy7ct7EXK fFlQLwLdaeEeRbsv13a/gwuW99wG6tRkYopgdMZU2neYdA6Ps39DOOz/y3kWwW+o +gTyQHbm2BSZfoDK902UFbknQZ+Gq8JhJn0Q+GgEAA839kixLmUvxj+3vABUw7C6 Y+Jf5LJ6ueLlOtglVDDqCniXRM6Pfu8PEaYACY+75pdU88Q5OT0ZTlfJGadnsw55 WXs7w4QSD4BoZuHC8Z6DPCxCaFc0xM6BfkmhoOzgaaU6ncP2nYX4llEf7zKLvsXj BgR1/VC7PfNv0WPb7s8mqV7f+ZmO/M6jJzZoWjuHSG7lgG20eT78PrJUPtEFn/uk qUC99oliodxKtKr5lgCYFFdyZeFkdeMPDGmJCq7WZeWicxbVdT2o1Fr6x6r1EJXA byI6h8jLjZ51ldlKNNvTIgVCJ7BQxi+WJ02TS7oYIhtzlJbL5U3Ov5NJ50qDMPoN lGrZTIcKJeiklTai2bE0hYzlYp/5EZTz+mGASEu9t7k52WtSSQZoc3LHDYD7ZzwM qoUhn+QhMf5rj2BDH2mF =6hcr -----END PGP SIGNATURE-----

March 17, 2014

Re: Cross-regressions between wine and mesa: how to handle them?

by Ruslan Kabatsayev

Hello all. More than a month has passed since the bug report, and Mesa devs haven't said anything. What should my further actions be? I suppose some of the following: 1. Wait more 2. File a bug at winehq and hope that something could be done as a (automatic) workaround 3. Not rely on this being fixable and tell all users with i915 and similar chips to patch either wine or mesa, or maybe use some registry overrides in wine (UseGLSL and the like) 4. Something better? Regards, Ruslan On Sun, Feb 2, 2014 at 5:34 PM, Ruslan Kabatsayev <b7.10110111(a)gmail.com> wrote: > On Fri, Jan 31, 2014 at 1:47 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: >> On 31 January 2014 09:45, Ruslan Kabatsayev <b7.10110111(a)gmail.com> wrote: >>> Without glPointParameter() calls I don't have those errors after >>> "[snip repeating messages]", but still do have CopyTexSubImage ones >>> (although I didn't notice such a serious slowdown as was before; and >>> these have also been before bisected wine commit). >> If the CopyTexSubImage ones aren't repeating after initial loading, >> they may be from the wined3d GL quirk detection code or the FBO caps >> detection code, in which case they would be harmless. > > They indeed don't repeat after loading. They appear after this commit: > > 7b0ba5153f3e42f31b922e5eb997d5e1d0cb44d4 is the first bad commit > commit 7b0ba5153f3e42f31b922e5eb997d5e1d0cb44d4 > Author: Matteo Bruni <mbruni(a)codeweavers.com> > Date: Thu Nov 3 15:26:36 2011 +0100 > > wined3d: Test more thoroughly for post-pixelshader blending > support, try on more texture formats. > > :040000 040000 4ccfbad52a0797cdd96f4efccafeac45c6ce688a > 026bd6e57c4cbbf8c906eddcb43527ffdbe233f7 M dlls

March 17, 2014

Re: [PATCH 5/5] wined3d: Remove the version parameter.

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-03-17 10:41, schrieb Henri Verbeet: > Do we really need this? It's perhaps unfortunate that setting > "DirectDrawRenderer" to "gdi" would also prevent 3D in d3d8+, but > I'm not sure if avoiding that is really worth an extra flag. Maybe not. Although we could think this one step further and consider removing the key and instead implement this functionality with an opengl32.dll = disabled override. Please ignore this patch for now. I'll investigate how well the opengl32 override works for this purpose. There's the theoretical possibility that an application uses d3d8 for main rendering and ddraw for GPU detection that fails for some reason without DirectDrawRenderer=gdi, but that would be a bug that needs a fix elsewhere. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTJs+fAAoJEN0/YqbEcdMwRJEP/jRSnlEWx3FLLniEANnPPNan hjjTQhnz1xozpuy6gK77scq7fbmtrzCnQkn3UH1vtDZUMTCLqAcwTOeTRoxI7rFN +dGXw/wfx0TDWcy6ppRtymGt0mHFvwmWb3R1RlH0j0YpspLNfDfB+DzG7n9j8qAU Ebr12OL5C2kkXBHxhH1+QtCtQIFnQmuCnTqUeOkuMT7Tm+OKmXKmAB6zWhjoXvCS IvP/y3KPErV2wMKeyd2phJLcZARtIrYzZj+u+KXvWZJCMgtXRf2PLmLTn7vFcjjX 0OY1uantYfUFIQa0GfXBDse3eyNCvClntTa858H4jthkudXznCDDxovCiOFM+6dC PKwoGsKzJFYUSyAeTFPoJBZo86W1S3Sm4eDtbfS1Omu/l+VJzvI3Jixt7nDPaZzt RB2tKeTCzBQJAyRfTcNndtiOW5y6gr5vOQk3ItCdtKsFrrASQNQcR98XMTkyxjqT UNTQPdGBn9cDQ6jJ/MJVbZOECQRk36kHrXog/YU6bkfTaaE6UWaHIEW+ORJJD2Hu 4ujmBU1qDyewDVYDkoBR3Di7r10LEB7ZcE3ek8vsxDSmJUiauDKR0wdI0CfS+CJH Wn+I3hoGXrmqvD4TcmlYGztP9orUfMj7WmLxf6rQSYh+UVsqICTS/LEi9YEGEb3G vsRm7iV1Dm8vKGEkeZ+2 =MlBb -----END PGP SIGNATURE-----

March 17, 2014

Re: FYI Re: wined3d_mutex

by Stefan Dösinger

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 2014-03-15 21:17, schrieb Max TenEyck Woodbury: > If anybody has an idea about what might be causing these delays, > please tell me. Sorry, no idea :-( . Maybe perf or oprofile show something. > Note that my review of the use of this mutex indicates that it is > of very questionable value. In my opinion it should be replaced by > a set of read/write locks built into the individual data > structures. I have to give the infamous answers "it depends" and "this needs tests". It's best to use the same lock granularity as native, everything else is asking for trouble. My very hacky testing suggests that native does not do any locking unless D3DCREATE_MULTITHREADED is passed. Applications can still call d3d from multiple threads without that flag, but then they have to do their own locking. If they don't, the application crashes sooner rather than later. Ddraw has one global DLL lock. That can be demonstrated easily with the various enum callbacks in the API. Native does not bother to release the lock when calling the application callback. I suspect d3d8/9 has a per device lock, but I have not done any testing to confirm this. IDirect3DResource9::SetPrivateData is your ticket to finding out. It's the only way you can make native d3d8/9 call your code (IUnknown::AddRef/Release, thanks to D3DSPD_IUNKNOWN). Maybe Microsoft was careful enough to release the lock before calling those methods, but I'd bet a beer that they weren't. The other thing to consider wrt locking is the multithreaded command stream. Some fields need synchronization. We can't use the wined3d lock for that. My general goal is to avoid sharing resource / device / whatever fields between the main and worker thread as much as possible, and if I do (e.g. (sub)resource.locations) set up CS and resource idle waits in such a way that the main thread knows no command is scheduled or being executed while it operates on those fields. Right now there are plenty of bugs in my preview code (e.g. struct wined3d_buffer.flags). -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTJs5kAAoJEN0/YqbEcdMwpMkP/jy5crUdlP6NOUjhOKPR8fd0 Hoy8bdxgkexPHgRFm7hDgFfSrfEDvOKRuwgD8cpFC+AtC1pwMdstPo7/VrwI7CWH diNyytRt+lvK74BR0zyXeTW7KAkw2+doCc28o8IWSEn9HtexdYmnlyBLRoMwHT4/ WRCtQb+mriLctnMRpp3LVOTJhwESTA74heSOsE11YtkqRYflMlKh7/8iLSHnRt6l FkHyY1ajLYkIB8NsbUWkXXTHkG9VC59pVpkQvOBdKQDXiEYCELNR7FTP9OqqHt2U DtG8LSUvuSRjMuL9ozBU5aF/EFeevIXjeMyi30f5mb2cT+yGDP/P/QKZNXyDVqD0 J95FvvIuitw5iLAQ1RzNQpMvHgwMsZZ0YpHCW+8hpAmI30HO7sHpOREXmCGt6OfV GZlmSIVP7fDqF2tF3SaFEABFd6XNeVj4APG1LgFOeE16Jl5RYaIqfMYCCWjyi5YQ vsa1GY1cIp4/ZkdG/nZvVOHYhqv6eTuske2QdzpLHR5nvhY3KB8UnPHzWwatHjkH e6FJquUPNbqzgEDgK0w/HJ9X/Kq9StKYC6uUDi0bkHrJ8ouDxcySFM9nNsMyfWix S0SerY5h8FfVdmk8MAV4xu+j3N87eorsMMnTJj40LcTQU6G0vCvAMYIT7PqgpaVf 68CqGerjMAzLUl3RJ3ng =vlfU -----END PGP SIGNATURE-----

March 17, 2014

Re: [PATCH 5/5] wined3d: Remove the version parameter.

by Henri Verbeet

On 16 March 2014 20:39, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > diff --git a/include/wine/wined3d.h b/include/wine/wined3d.h > index 7bb37d6..df725e2 100644 > --- a/include/wine/wined3d.h > +++ b/include/wine/wined3d.h > @@ -1221,6 +1221,7 @@ enum wined3d_display_rotation > #define WINED3D_NO3D 0x00000002 > #define WINED3D_VIDMEM_ACCOUNTING 0x00000004 > #define WINED3D_PRESENT_CONVERSION 0x00000008 > +#define WINED3D_ALLOW_3D_DISABLE 0x00000010 > Do we really need this? It's perhaps unfortunate that setting "DirectDrawRenderer" to "gdi" would also prevent 3D in d3d8+, but I'm not sure if avoiding that is really worth an extra flag.

March 17, 2014

Re: [PATCH] widl: Fix default value types

by Alexandre Julliard

Nikolay Sivov <nsivov(a)codeweavers.com> writes: > http://bugs.winehq.org/show_bug.cgi?id=35778 > > --- > tools/widl/write_msft.c | 29 +++++++++++++++++++++++++---- > 1 file changed, 25 insertions(+), 4 deletions(-) This is causing warning: can't write value of type 29 yet during the build, that's probably not good. -- Alexandre Julliard julliard(a)winehq.org

March 17, 2014

Re: rpcrt4/tests: Add a couple of tests for marshalling an array of strings.

by Nikolay Sivov

On 3/17/2014 07:36, Dmitry Timoshkov wrote: > This is because of broken code generated by widl. That means widl should be fixed first, otherwise we get a bunch of failing tests on all platforms.

March 17, 2014

Re: rpcrt4/tests: Add a couple of tests for marshalling an array of strings.

by Dmitry Timoshkov

Marvin <testbot(a)winehq.org> wrote: > === w2000pro (32 bit server) === > server.c:1241: Test failed: expected Hello, got H# > server.c:1243: Test failed: expected World!, got W# > server.c:1253: Test failed: expected Hello, got L"H#\0178#\4d4c\4d45\86b8#\8640#" > server.c:1255: Test failed: expected World!, got L"W" > server.c:1241: Test failed: expected Hello, got H# > server.c:1243: Test failed: expected World!, got W# > server.c:1253: Test failed: expected Hello, got L"H#\0178#\4d4c\4d45\6868#\67c0#" > server.c:1255: Test failed: expected World!, got L"W" > server.c:1241: Test failed: expected Hello, got H# > server.c:1243: Test failed: expected World!, got W# > server.c:1253: Test failed: expected Hello, got L"H#\0198#\4d4c\4d45\7280#\6288#\7280#\0003\0004\0100\000c" > server.c:1255: Test failed: expected World!, got L"W" > > === wxppro (32 bit server) === > server.c:1241: Test failed: expected Hello, got H > server.c:1243: Test failed: expected World!, got W$ > server.c:1253: Test failed: expected Hello, got L"H$\01b8$\4d4c\4d45\0008" > server.c:1255: Test failed: expected World!, got L"W" > server.c:1241: Test failed: expected Hello, got H$ > server.c:1243: Test failed: expected World!, got W$ > server.c:1253: Test failed: expected Hello, got L"H$\0178$\4d4c\4d45\0008" > server.c:1255: Test failed: expected World!, got L"W" > server.c:1241: Test failed: expected Hello, got H$ > server.c:1243: Test failed: expected World!, got W$ > server.c:1253: Test failed: expected Hello, got L"H$\0408$\4d4c\4d45\0008" > server.c:1255: Test failed: expected World!, got L"W" > > === wvista (32 bit server) === > server.c:1241: Test failed: expected Hello, got H > server.c:1243: Test failed: expected World!, got W > server.c:1253: Test failed: expected Hello, got L"H" > server.c:1255: Test failed: expected World!, got L"W" > server.c:1241: Test failed: expected Hello, got H > server.c:1243: Test failed: expected World!, got W > server.c:1253: Test failed: expected Hello, got L"H" > server.c:1255: Test failed: expected World!, got L"W" > server.c:1241: Test failed: expected Hello, got H > server.c:1243: Test failed: expected World!, got W > server.c:1253: Test failed: expected Hello, got L"H" > server.c:1255: Test failed: expected World!, got L"W" > > === wvistau64 (32 bit server) === > server.c:1241: Test failed: expected Hello, got H > server.c:1243: Test failed: expected World!, got W > server.c:1253: Test failed: expected Hello, got L"Hdow\4d4c\4d45\0008" > server.c:1255: Test failed: expected World!, got L"Wem3\4d4c\4d45\0008" > server.c:1241: Test failed: expected Hello, got H > server.c:1243: Test failed: expected World!, got W > server.c:1253: Test failed: expected Hello, got L"Hem3\4d4c\4d45\0008" > server.c:1255: Test failed: expected World!, got L"W;C:\4d4c\4d45\0008" > server.c:1241: Test failed: expected Hello, got H > server.c:1243: Test failed: expected World!, got W > server.c:1253: Test failed: expected Hello, got L"Hdow\4d4c\4d45\0008" > server.c:1255: Test failed: expected World!, got L"Wem3\4d4c\4d45\0008" > > === w2008s64 (32 bit server) === > server.c:1241: Test failed: expected Hello, got H > server.c:1243: Test failed: expected World!, got W > server.c:1253: Test failed: expected Hello, got L"H" > server.c:1255: Test failed: expected World!, got L"W" > server.c:1241: Test failed: expected Hello, got H > server.c:1243: Test failed: expected World!, got W > server.c:1253: Test failed: expected Hello, got L"H" > server.c:1255: Test failed: expected World!, got L"W" > server.c:1241: Test failed: expected Hello, got H > server.c:1243: Test failed: expected World!, got W > server.c:1253: Test failed: expected Hello, got L"H" > server.c:1255: Test failed: expected World!, got L"W" > > === w7pro64 (32 bit server) === > server.c:1241: Test failed: expected Hello, got H > server.c:1243: Test failed: expected World!, got W > server.c:1253: Test failed: expected Hello, got L"H" > server.c:1255: Test failed: expected World!, got L"W" > server.c:1241: Test failed: expected Hello, got H > server.c:1243: Test failed: expected World!, got W > server.c:1253: Test failed: expected Hello, got L"H" > server.c:1255: Test failed: expected World!, got L"W" > server.c:1241: Test failed: expected Hello, got H > server.c:1243: Test failed: expected World!, got W > server.c:1253: Test failed: expected Hello, got L"H" > server.c:1255: Test failed: expected World!, got L"W" > > === w8 (32 bit server) === > server.c:984: Test failed: get_ranged_enum() returned 1997012995 instead of RE3 > server.c:1241: Test failed: expected Hello, got H > server.c:1243: Test failed: expected World!, got W > server.c:1253: Test failed: expected Hello, got L"H" > server.c:1255: Test failed: expected World!, got L"W" > server.c:984: Test failed: get_ranged_enum() returned -65533 instead of RE3 > server.c:1241: Test failed: expected Hello, got H > server.c:1243: Test failed: expected World!, got W > server.c:1253: Test failed: expected Hello, got L"H" > server.c:1255: Test failed: expected World!, got L"W" > server.c:984: Test failed: get_ranged_enum() returned 1997012995 instead of RE3 > server.c:1241: Test failed: expected Hello, got H > server.c:1243: Test failed: expected World!, got W > server.c:1253: Test failed: expected Hello, got L"H" > server.c:1255: Test failed: expected World!, got L"W" > > === wvistau64 (64 bit server) === > server.c:1241: Test failed: expected Hello, got H > server.c:1243: Test failed: expected World!, got W > server.c:1253: Test failed: expected Hello, got L"H" > server.c:1255: Test failed: expected World!, got L"W" > server.c:1241: Test failed: expected Hello, got H > server.c:1243: Test failed: expected World!, got W > server.c:1253: Test failed: expected Hello, got L"H" > server.c:1255: Test failed: expected World!, got L"W" > server.c:1241: Test failed: expected Hello, got H > server.c:1243: Test failed: expected World!, got W > server.c:1253: Test failed: expected Hello, got L"H" > server.c:1255: Test failed: expected World!, got L"W" > > === w2008s64 (64 bit server) === > server.c:1241: Test failed: expected Hello, got H > server.c:1243: Test failed: expected World!, got W > server.c:1253: Test failed: expected Hello, got L"H" > server.c:1255: Test failed: expected World!, got L"W" > server.c:1241: Test failed: expected Hello, got H > server.c:1243: Test failed: expected World!, got W > server.c:1253: Test failed: expected Hello, got L"H" > server.c:1255: Test failed: expected World!, got L"W" > server.c:1241: Test failed: expected Hello, got H > server.c:1243: Test failed: expected World!, got W > server.c:1253: Test failed: expected Hello, got L"H" > server.c:1255: Test failed: expected World!, got L"W" > > === w7pro64 (64 bit server) === > server.c:1241: Test failed: expected Hello, got H > server.c:1243: Test failed: expected World!, got W > server.c:1253: Test failed: expected Hello, got L"H" > server.c:1255: Test failed: expected World!, got L"W" > server.c:1241: Test failed: expected Hello, got H > server.c:1243: Test failed: expected World!, got W > server.c:1253: Test failed: expected Hello, got L"H" > server.c:1255: Test failed: expected World!, got L"W" > server.c:1241: Test failed: expected Hello, got H > server.c:1243: Test failed: expected World!, got W > server.c:1253: Test failed: expected Hello, got L"H" > server.c:1255: Test failed: expected World!, got L"W" This is because of broken code generated by widl. -- Dmitry.

March 17, 2014