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

Re: [2/2] imagehlp: Implement (parts of) BindImageEx (try 8)

by Marvin

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://testbot.winehq.org/JobDetails.pl?Key=7391 Your paranoid android. === wvistau64 (64 bit image) === image.c:426: Test failed: Expected StatusRoutine to be called once with reason BindImportProcedure, but it was called 0 times === w2008s64 (64 bit image) === image.c:426: Test failed: Expected StatusRoutine to be called once with reason BindImportProcedure, but it was called 0 times

June 2, 2014

Re: [1/2] imagehlp: Implement (parts of) BindImageEx (try 8)

by Marvin

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://testbot.winehq.org/JobDetails.pl?Key=7390 Your paranoid android. === wvistau64 (64 bit image) === image.c:426: Test failed: Expected StatusRoutine to be called once with reason BindImportProcedure, but it was called 0 times === w2008s64 (64 bit image) === image.c:426: Test failed: Expected StatusRoutine to be called once with reason BindImportProcedure, but it was called 0 times

June 2, 2014

Re: [PATCH 1/4] Use <poll.h> instead of <sys/poll.h>

by Juan Lang

Hi Felix, On Sun, Jun 1, 2014 at 1:16 AM, Felix Janda <felix.janda(a)posteo.de> wrote: > This patch changes includes of <sys/poll.h> to <poll.h>, removes > the configure test for <sys/poll.h> and makes the whitespace of > the includes consistent. > Patches should be sent to wine-patches(a)winehq.org, not wine-devel(a). See http://wiki.winehq.org/SubmittingPatches. Also, the maintainer is on vacation, so don't expect a quick response. Best, --Juan

June 2, 2014

Re: Re: Recognize cards that expose GLSL 1.30 as DX10 capable even if they don't support EXT_GPU_SHADER4

by Andrei Slavoiu

> On 27 May 2014 17:35, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > > No, I'd say use something like if (EXT_gpu_shader4 || ( > > ARB_shader_texture_lod && glsl_version >= 1.30). > > That's just wrong, GLSL 1.30 + ARB_shader_texture_lod doesn't imply > SM4, only SM3. Actually, it does. No SM3 card can expose GLSL 1.30. > On 28 May 2014 21:48, Andrei Slăvoiu <andrei.slavoiu(a)gmail.com> wrote: > > Actually, d3d_level_from_gl_info is misleading (broken even), as it will > > check for SM3 capability and then return that the card is capable of > > directx 10 > EXT_gpu_shader4 adds (among others) support for "native" integers and > bitwise operations. It can't be supported (in hardware) on a SM3 GPU. > The specific extensions used in d3d_level_from_gl_info() are somewhat > arbitrary, we could have used e.g. ARB_geometry_shader4 instead of > EXT_gpu_shader4 here as well. Like you say, the extensions are arbitrary, so why not use GLSL version as well? GLSL 1.30 also adds support for integers and bitwise operations. All functionality of EXT_gpu_shader4 is exposed by either GLSL 1.30 or ARB_shader_texture_lod. > Note that the intention of the code this function is a part of is to > come up with a somewhat reasonable card to report to the application > in case of unrecognized GL implementations, while e.g. > shader_glsl_get_caps() is meant to report actual capabilities. It > would perhaps be nice to use the actual shader backend etc. caps for > d3d_level_from_gl_info(), but note that that wouldn't necessarily be > easy, or make the situation much better. For the Mesa case you mention > in the original patch it would arguably make the situation worse, > since we can't currently properly do shader model 4 on Mesa. I'm not actually interested in using DirectX 10 (yet). The reason I started messing with this part of the code is that World of Warcraft renders complete garbage when the card is presented as Radeon 9500. Changing this to Radeon X1600 improves things a bit, only the background is broken, characters and menus appear fine. Finally, with Radeon HD 2900 the only broken rendering is with the shadows. Those remain broken even when using the PCI ID of my real card, a KAVERI, so it's probably a mesa bug. The reason I prefer to improve the fallback instead of simply adding the PCI ID for my card to the list of known cards is that with the current model there will always be cards that are not recognized by wine and a good fallback will prevent the experience for a newbie being "nothing works, wine sucks".

June 2, 2014

Re: Video memory size detection in D3D

by Matteo Bruni

2014-06-02 17:45 GMT+02:00 Henri Verbeet <hverbeet(a)gmail.com>: > On 30 May 2014 15:25, Ruslan Kabatsayev <b7.10110111(a)gmail.com> wrote: >> Hmm, this is an interesting point. But, for GLX_MESA_query_renderer, >> which appeared relatively recently, one can't say it's experimental or >> cannot return the total memory. Can its use be accepted by Wine? Maybe >> at some point Nvidia/AMD will implement it too (looks unlikely >> though), but at least for Mesa-powered drivers it would work. >> > Yes, we'd like to use GLX_MESA_query_renderer for this. Do you happen > to know if it's supported by the r600g driver yet? The last time I > looked into it there were some patches on the mailing list, but > nothing committed yet. > It's advertised on r600g (REDWOOD, although I doubt it matters), Mesa 10.1.3, I haven't tried to actually use it though.

June 2, 2014

Re: wined3d: Recognize cards that expose ARB_shader_texture_lod as DX10 capable even if they don't support EXT_gpu_shader4 (try 3)

by Henri Verbeet

On 29 May 2014 10:56, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > There's also GLX_MESA_query_renderer. It gives us the PCI IDs and > video memory size directly, without all the string parsing guesswork. But note that the PCI IDs aren't that useful, because you still need some information from gpu_description_table[] and driver_version_table[]. This means you need to match either the PCI ID to a known list, or match the renderer string against some known list, like we currently do. With vendors using several PCI IDs for the same card, matching the renderer string may be the easier approach. (Although on the other hand matching PCI IDs could perhaps be shared with Mesa somehow, or perhaps use something like udev hwdb properties.)

June 2, 2014

Re: Video memory size detection in D3D

by Henri Verbeet

On 30 May 2014 15:25, Ruslan Kabatsayev <b7.10110111(a)gmail.com> wrote: > Hmm, this is an interesting point. But, for GLX_MESA_query_renderer, > which appeared relatively recently, one can't say it's experimental or > cannot return the total memory. Can its use be accepted by Wine? Maybe > at some point Nvidia/AMD will implement it too (looks unlikely > though), but at least for Mesa-powered drivers it would work. > Yes, we'd like to use GLX_MESA_query_renderer for this. Do you happen to know if it's supported by the r600g driver yet? The last time I looked into it there were some patches on the mailing list, but nothing committed yet.

June 2, 2014

Re: Recognize cards that expose GLSL 1.30 as DX10 capable even if they don't support EXT_GPU_SHADER4

by Henri Verbeet

On 23 May 2014 00:23, Andrei Slăvoiu <andrei.slavoiu(a)gmail.com> wrote: > already part of OpenGL 3.0. This causes all cards that are not explicitly > recognized by wine (for example all GCN cards) to be treated as DX9 cards and > presented to Windows apps as Radeon 9500. > TAHITI, PITCAIRN and CAPE VERDE should be recognized, newer cards aren't. On 27 May 2014 17:35, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > No, I'd say use something like if (EXT_gpu_shader4 || ( > ARB_shader_texture_lod && glsl_version >= 1.30). That's just wrong, GLSL 1.30 + ARB_shader_texture_lod doesn't imply SM4, only SM3. On 28 May 2014 21:48, Andrei Slăvoiu <andrei.slavoiu(a)gmail.com> wrote: > Actually, d3d_level_from_gl_info is misleading (broken even), as it will check > for SM3 capability and then return that the card is capable of directx 10 EXT_gpu_shader4 adds (among others) support for "native" integers and bitwise operations. It can't be supported (in hardware) on a SM3 GPU. The specific extensions used in d3d_level_from_gl_info() are somewhat arbitrary, we could have used e.g. ARB_geometry_shader4 instead of EXT_gpu_shader4 here as well. Note that the intention of the code this function is a part of is to come up with a somewhat reasonable card to report to the application in case of unrecognized GL implementations, while e.g. shader_glsl_get_caps() is meant to report actual capabilities. It would perhaps be nice to use the actual shader backend etc. caps for d3d_level_from_gl_info(), but note that that wouldn't necessarily be easy, or make the situation much better. For the Mesa case you mention in the original patch it would arguably make the situation worse, since we can't currently properly do shader model 4 on Mesa.

June 2, 2014

Re: New Wine patches

by Alois Schlögl

On 05/30/2014 02:08 PM, Bruno Jesus wrote: > On Mon, May 26, 2014 at 10:36 AM, Chakke, Neha (GE Oil & Gas) > <Neha.Chakke(a)ge.com> wrote: >> >> Hello , >> >> I am trying to run a GE software and hardware on Debian (Linux platform) using WineHQ. In order to run the hardware we need to install device drivers for USB (Cypress) . >> >> http://wiki.winehq.org/USB >> >> I have been trying to look for some solutions online since a week. Could you kindly send me the new wine patches and please guide me with the procedure. >> >> Thanks and regards, >> >> Miss Neha Chakke > > Hi, Wine is not an operating system and doesn't implement the "Windows > kernel" infrastructure needed to support various kind of hardware > driver classes. > > Depending on what kind of device it is you can make it work with the > Linux kernel and then use it inside wine, Cypress is known to make > USB->serial devices, if that is the case there is a chance it will > work in wine. See: > > http://www.winehq.org/docs/wineusr-guide/misc-things-to-configure#AEN715 > Dear Neha, The page http://wiki.winehq.org/USB states: "Drivers which depend on modules other than ntoskrnl.exe, hal.dll, usbd.sys will not work." USB seems to work only for keyboard and mouse, and serial interfaces connected through an USB2Serial adapter. A good example is MC700A. http://appdb.winehq.org/objectManager.php?sClass=version&iId=30086 1) Connect the Hardware with the serial interface. I've been using a Serial2USB converter, because the Laptop did not have a serial interface. The device was identified as /dev/ttyUSB0. 2) Configure the device in wine with this command ln -s /dev/ttyUSB0 ~/.wine/dosdevices/com1 3) Set permissions sudo chgrp dialout /dev/ttyUSB0 or alternatively sudo chmod a+rw /dev/ttyUSB0 This works because the interface looks like a serial interface to wine. Perhaps that will work for you too. If it does not work and it requires some USB driver on window, other than the ones mentioned above, your application will be just another one not supported by wine: http://bugs.winehq.org/buglist.cgi?quicksearch=usb As a way forward, it would certainly be useful to know which windows driver is actually used by your device. You will find this information in the windows registry (for details see http://wiki.winehq.org/USB) This information by useful for identifying the most common USB device drivers on windows. Have a nice weekend, Alois

June 2, 2014

Re: [PATCH 3/3] vbscript: Fixed CInt(try 2)

by Marvin

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://testbot.winehq.org/JobDetails.pl?Key=7387 Your paranoid android. === w2000pro (32 bit) === No test summary line found === wxppro (32 bit) === No test summary line found === wvistau64 (32 bit) === No test summary line found === w2008s64 (32 bit) === No test summary line found === w7u (32 bit) === No test summary line found === w8 (32 bit) === No test summary line found === wvistau64 (64 bit) === No test summary line found === w2008s64 (64 bit) === No test summary line found

June 2, 2014