February 2008 - Wine-Devel - list.winehq.org

? on Repositories for Unaccept Patches and (work in Progress).

by Joseph Stein

Is there a Git Repositories for Unaccept Patches or (work in Progress)? If not (which i think is the case and why I posting here instead of the user mailing list.), could you create one(along with a text file explain what need to be done to be accepted)? Here are some reason I think It is Needed. 1.) It would allow developer and users to see what the source done. I have read a very good article about usb support in wine an winehq.org here http://www.winehq.org/?issue=331 wich said that >An ntoskrnl.exe was written a couple of years ago to load drivers, >specifically the Safedisc Windows kernel driver, but it still hasn't been >accepted. Apparently there's some low-level internal Wine issues >and Alexandre wants those fixed before accepting the patch. 2.) Allow people two git possibly some things work that would other wise not work. using the patch for ntoskrnl.exe that was not accept as an example, (please correct me if i wrong), could possible git some drivers working (usb driver may be?) program to work. which is currently not possible with wine from what i read. Yes It dose cause other wine problem which is not big deal, if you compile and run wine form the source directory from which it is compiled instead of installing it (the multiple wine install way). In other words you code use the patch version of wine just for the program that need the patch to work .(Is it not better to have a broken wine (with partal diver) support, then a stable wine with-out (partal diver) support when The program you are running requires a driver.) 3.)If done right in my humble opinion would help prevent developer from getting discurage becuase all there work has be chuck out the window. Giving more Light to what i said above, What I mean buy "if done right",Is that if a developer(who is looking for something to do) would go look at what patches Have not be accepted (but have almost all basic done) and help the developer git it accepted ,Would in my humble opinion encourage more developer to join which is need for a complicated project such as wine. Basically threat unaccepted patch as bugs(while keeping the patch out of wine), instead of chucking it out the window. This type of thing is done in boost project i be-leave, but I taking it one step further and asking for a text file on "what need to be done to be include which each unaccepted patches". Thank you for any reply, Please forgive me if I got any of what i said above wrong, I'm not a real good developer and only have a real basic idea of wine and have not work on wine because it to confusing to me(but have download and looked at from git Repositories) --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.

Feb. 10, 2008

Re: WineD3D: split framebuffer -> texture path from LoadLocation

by Stefan Dösinger

Am Sonntag, 10. Februar 2008 17:37:25 schrieb Roderick Colenbrander: > Hi, > > This patch puts the framebuffer -> texture from LoadLocation in a separate > function in a similar way to read_from_framebuffer. It borrows some code > from LoadLocation and read_from_framebuffer. > > Regards, > Roderick Colenbrander You're mixing tabs and spaces in this patch

Feb. 10, 2008

Re: pdh[3:3]: remove unnecessary tests done in PdhLookupPerfNameByIndexW

by Dmitry Timoshkov

"Jeff Latimer" <lats(a)yless4u.com.au> wrote: > --- a/dlls/pdh/pdh_main.c > +++ b/dlls/pdh/pdh_main.c > @@ -837,14 +837,7 @@ PDH_STATUS WINAPI PdhLookupPerfNameByIndexA( LPCSTR machine, DWORD index, LPSTR > > TRACE("%s %d %p %p\n", debugstr_a(machine), index, buffer, size); > > - if (machine) > - { > - FIXME("remote machine not supported\n"); > - return PDH_CSTATUS_NO_MACHINE; > - } > - > if (!buffer || !size) return PDH_INVALID_ARGUMENT; > - if (!index) return ERROR_SUCCESS; Changelog mentions PdhLookupPerfNameByIndexW by the change is in PdhLookupPerfNameByIndexA. Why are you removing the checks in one place by leave the same in other one? Why the tests are unnecessary? -- Dmitry.

Feb. 10, 2008

Re: Is wine reporting the right value for MaxVertexBlendMatrices ?

by Stefan Dösinger

Am Sonntag, 10. Februar 2008 11:27:22 schrieb Julio Fernandez: > So my question is: is there any reason to not have wine return > MaxVertexBlendMatrices=4 (as it works regardless of what opengl > reports), and if so is it any other way for people willing to use some > programs (like Everquest) to 'hack' it's value than modify > IDirect3DDevice9Impl_GetDeviceCaps manually to make it return 4 Returning 4 makes Everquest happy, but will break other apps. I think the only way to fix this properly is to complete Henri's fixed function pipeline replacement shader in order to implemen vertex blending using shaders. This is major task unfortunately.

Feb. 10, 2008

Re: Is wine reporting the right value for MaxVertexBlendMatrices ?

by Julio Fernandez

Alex Jackson escribió: > > That said, GL_ARB_vertex_blend is not very common. Only MacOS > supports it, and > > it is software emulated there. The Linux ATI driver used to support > it until > > ATI switched to a different codebase. So this constant ends up beeing 0 > > almost everywhere. The extension was dropped in favor of vertex > programs, > > since vertex programs appeared shortly after vertex blending and no > gl app > > was using it at this time. On Windows drivers emulate vertex blending > using > > vertex shaders. > > > > I am not sure if 0 is the correct value to return in case of no vertex > > blending support. What happens if you set it to 1? 1 would be a > reasonable > > default as well, because we're still able to transform vertices with one > > matrix(ie, unblened transformation). It could also be that this game > silently > > expects vertex blending to be supported: For one part, all dx8+ cards > support > > this feature on Windows, and on older cards Windows has software vertex > > processing which can perform blending in a slow, but working fashion. > > > > I have a patch for software emulated vertex blending somewhere, but I > dropped > > it because I didn't come across an app which uses this function. > Maybe its > > time to revive it, and continue the work on a fixed function replacement > > shader. > > Even on Windows, no OpenGL implementation that I know of supports > GL_ARB_vertex_blend other than ATI's (and as you've pointed out, the new > OpenGL stack that the Radeon HD's use on Windows and that all Radeons > now use on Linux has dropped it). > > History lesson: Both GL_ARB_vertex_blend and D3D vertex blending are > historically tied to a specific piece of hardware: the original ATI > Radeon (GL_ARB_vertex_blend started out as GL_ATI_vertex_blend). > Presumably, due to ATI's historically spotty OpenGL driver performance > (okay, "historically" is being kind to ATI), any game developer who > wanted to use the Radeon's capabilities targeted their game for D3D > rather than OpenGL. Consequently, when nVidia released the GeForce 3 > (the first video card with vertex shaders) they did implement D3D vertex > blending via shaders in their D3D driver (since games were using it, and > it wouldn't do if the "new" GF3 couldn't handle effects that the "old" > Radeon could), but they didn't bother to implement it in their OpenGL > driver, even though ATI had gotten it ARB-approved some months before > the GF3 came out, since no games/apps were using it. The other video > hardware makers (the few that were left by the DX8 era) followed NV's > example: implement D3D vertex blending via shaders or in software (for > entry-level and onboard hardware without vertex shaders), but don't > bother with GL_ARB_vertex_blend since no one uses it. > > The upshot is that GL_ARB_vertex_blend is an ARB extension In Name Only; > it's effectively ATI-only--and even ATI has abandoned it now. On the > other hand, D3D vertex blending is universally available on modern and > semi-modern hardware regardless of maker, and it looks like even some > D3D9 games still use it instead of using vertex shaders. So it's better > for WINE to implement vertex blending via vertex programs rather than > depending on GL_ARB_vertex_blend. > > --AWJ-- > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > I am a bit lost now, but then, for a fast recap: 1- Theres some programs that call ConvertToIndexedBlendedMesh at d3d9x_30.dll 2- wine returns (from opengl) MaxVertexBlendMatrices=0 3- d3d9x_30.dll misbehaves and generates vertex declarations with odd type codes and offsets when MaxVertexBlendMatrices=0 4- when we hack wine at IDirect3DDevice9Impl_GetDeviceCaps to return 4 d3d9x_30.dll works properly and the programs run right So my question is: is there any reason to not have wine return MaxVertexBlendMatrices=4 (as it works regardless of what opengl reports), and if so is it any other way for people willing to use some programs (like Everquest) to 'hack' it's value than modify IDirect3DDevice9Impl_GetDeviceCaps manually to make it return 4

Feb. 10, 2008

Re: Is wine reporting the right value for MaxVertexBlendMatrices ?

by Alex Jackson

> That said, GL_ARB_vertex_blend is not very common. Only MacOS supports it, and > it is software emulated there. The Linux ATI driver used to support it until > ATI switched to a different codebase. So this constant ends up beeing 0 > almost everywhere. The extension was dropped in favor of vertex programs, > since vertex programs appeared shortly after vertex blending and no gl app > was using it at this time. On Windows drivers emulate vertex blending using > vertex shaders. > > I am not sure if 0 is the correct value to return in case of no vertex > blending support. What happens if you set it to 1? 1 would be a reasonable > default as well, because we're still able to transform vertices with one > matrix(ie, unblened transformation). It could also be that this game silently > expects vertex blending to be supported: For one part, all dx8+ cards support > this feature on Windows, and on older cards Windows has software vertex > processing which can perform blending in a slow, but working fashion. > > I have a patch for software emulated vertex blending somewhere, but I dropped > it because I didn't come across an app which uses this function. Maybe its > time to revive it, and continue the work on a fixed function replacement > shader. Even on Windows, no OpenGL implementation that I know of supports GL_ARB_vertex_blend other than ATI's (and as you've pointed out, the new OpenGL stack that the Radeon HD's use on Windows and that all Radeons now use on Linux has dropped it). History lesson: Both GL_ARB_vertex_blend and D3D vertex blending are historically tied to a specific piece of hardware: the original ATI Radeon (GL_ARB_vertex_blend started out as GL_ATI_vertex_blend). Presumably, due to ATI's historically spotty OpenGL driver performance (okay, "historically" is being kind to ATI), any game developer who wanted to use the Radeon's capabilities targeted their game for D3D rather than OpenGL. Consequently, when nVidia released the GeForce 3 (the first video card with vertex shaders) they did implement D3D vertex blending via shaders in their D3D driver (since games were using it, and it wouldn't do if the "new" GF3 couldn't handle effects that the "old" Radeon could), but they didn't bother to implement it in their OpenGL driver, even though ATI had gotten it ARB-approved some months before the GF3 came out, since no games/apps were using it. The other video hardware makers (the few that were left by the DX8 era) followed NV's example: implement D3D vertex blending via shaders or in software (for entry-level and onboard hardware without vertex shaders), but don't bother with GL_ARB_vertex_blend since no one uses it. The upshot is that GL_ARB_vertex_blend is an ARB extension In Name Only; it's effectively ATI-only--and even ATI has abandoned it now. On the other hand, D3D vertex blending is universally available on modern and semi-modern hardware regardless of maker, and it looks like even some D3D9 games still use it instead of using vertex shaders. So it's better for WINE to implement vertex blending via vertex programs rather than depending on GL_ARB_vertex_blend. --AWJ-- _________________________________________________________________

Feb. 10, 2008

Re: gecko download not robust?

by Austin English

On Feb 9, 2008 5:17 PM, marco <marco(a)mandrivaclub.nl> wrote: > > > > > Hmm. gecko download hung for me once. I saw > > fixme:urlmon:ProtocolStream_Read Read failed: 800c0008 > > in the log, which makes me wonder if our download code > > doesn't handle transient network errors well. > > > > Time to get rid of the download, and just bundle gecko outright, I say... > > I make the mandriva rpms for wine. > This would make the rpms 30% bigger. > And you would download the same gecko binary over and over again with > every new version. > > But if that is not a problem than it can be easily done. > > Why not have package maintainers package gecko like most do development files. So you could have for example on ubuntu: $ sudo apt-get install wine wine-dev wine-gecko Where wine-gecko wouldn't have to be upgraded very often. -Austin

Feb. 10, 2008

re: gecko download not robust?

by marco

> > Hmm. gecko download hung for me once. I saw > fixme:urlmon:ProtocolStream_Read Read failed: 800c0008 > in the log, which makes me wonder if our download code > doesn't handle transient network errors well. > > Time to get rid of the download, and just bundle gecko outright, I say... I make the mandriva rpms for wine. This would make the rpms 30% bigger. And you would download the same gecko binary over and over again with every new version. But if that is not a problem than it can be easily done.

Feb. 9, 2008

Re: Is wine reporting the right value for MaxVertexBlendMatrices ?

by Julio Fernandez

First my deep apologize for the multiple/double post, I am not too used to post on news and I was not seeing my posts so I though they were getting 'lost' somewhere As for system specs I run 2x Geforce 7900GS on SLI configuration with Nvidia 169.07 driver, x64 architecture, Debian etch, XOrg 7.1.1 Stefan Dösinger escribió: > I am not sure if 0 is the correct value to return in case of no vertex > blending support. What happens if you set it to 1? 1 would be a reasonable > default as well, because we're still able to transform vertices with one > matrix(ie, unblened transformation). It could also be that this game silently > expects vertex blending to be supported: For one part, all dx8+ cards support > this feature on Windows, and on older cards Windows has software vertex > processing which can perform blending in a slow, but working fashion. 1 won't work as d3dx9_30 does <2 (or <=2, I cant rememeber the exact asm comparison) check against the returned value so both 0 and 1 will work the same way The game made a requirement to have DX9c many months ago The odd part of it all is the own d3dx9_30 declaring type '0xfe' vertexes and odd offsets when receiving a 0 as value On a side note, what's the status of 2.0 and 1.4 shaders in wine? wine reports fixme:d3d:IWineD3DDeviceImpl_CreateVertexBuffer Out of memory! trying to D3DCREATERESOURCEOBJECTINSTANCE(object, VertexBuffer, WINED3DRTYPE_VERTEXBUFFER, Size) when loading data from some zones, and then freezing the screen (although the rest of wine and the game keeps running in the background)

Feb. 9, 2008

Re: Is wine reporting the right value for MaxVertexBlendMatrices ?

by Stefan Dösinger

Am Samstag, 9. Februar 2008 16:00:51 schrieb Julio Fernandez: > At the moment is set in wine as *pCaps->MaxVertexBlendMatrices = > GL_LIMITS(blends) which results in a value of 0 (at least in my Linux > > computer/build), while under Windows (XPSP2 DX9c) results in a value of 4 What we return depends on the features of the OpenGL implementation. If GL_ARB_vertex_blend is not supported, we return 0, otherwise we return the limited reported to us by OpenGL, which is 4 on implementations that support it. That said, GL_ARB_vertex_blend is not very common. Only MacOS supports it, and it is software emulated there. The Linux ATI driver used to support it until ATI switched to a different codebase. So this constant ends up beeing 0 almost everywhere. The extension was dropped in favor of vertex programs, since vertex programs appeared shortly after vertex blending and no gl app was using it at this time. On Windows drivers emulate vertex blending using vertex shaders. I am not sure if 0 is the correct value to return in case of no vertex blending support. What happens if you set it to 1? 1 would be a reasonable default as well, because we're still able to transform vertices with one matrix(ie, unblened transformation). It could also be that this game silently expects vertex blending to be supported: For one part, all dx8+ cards support this feature on Windows, and on older cards Windows has software vertex processing which can perform blending in a slow, but working fashion. I have a patch for software emulated vertex blending somewhere, but I dropped it because I didn't come across an app which uses this function. Maybe its time to revive it, and continue the work on a fixed function replacement shader.

Feb. 9, 2008