December 2005 - Wine-Devel - list.winehq.org

Re: ATI Opengl regression (DRI?)

by Raphael

On Friday 16 December 2005 02:26, Aric Cyr wrote: > Raphael <fenix <at> club-internet.fr> writes: > > On Thursday 15 December 2005 19:55, Jesse Allen wrote: > > > Hi, > > > > > > It seems that the patch > > > git-1399edb0925966a802a6a39835025c22c22c18e1.patch found here > > > http://www.winehq.org/pipermail/wine-cvs/2005-December/019731.html > > > causes an opengl regression on my system. With the patch loading War3 > > > causes X Error of failed request: GLXUnsupportedPrivateRequest > > > Major opcode of failed request: 143 (GLX) > > > Minor opcode of failed request: 17 (X_GLXVendorPrivateWithReply) > > > Serial number of failed request: 429 > > > Current serial number in output stream: 429 > > > > > > Which seems to stop the game loading thread and causes the game to use > > > the fail-safe thread "Please insert disc", so the game wont load. > > > Reversing the patch fixes the problem. > > > > > > I have a Radeon 9200 using DRI snapshots about 20051024. > > > > > > X Window System Version 6.8.99.901 (6.9.0 RC 1) (Minimal DRI build from > > > X.org tr ee) > > > Release Date: 18 October 2005 + cvs > > > X Protocol Version 11, Revision 0, Release 6.8.99.901 > > > Build Operating System: Linux 2.6.14-rc5 i686 [ELF] > > > Current Operating System: Linux tesore 2.6.15-rc4-git1 #1 PREEMPT Fri > > > Dec 2 17:0 3:32 MST 2005 i686 > > > Build Date: 28 October 2005 > > > > > > Is this a DRI problem? > > > > No, only that DRI don't implement GLX 1.3 > > i just sent a patch to fix (ie. by-pass) this regression. > > You really don't need to use glXQueryServerString() and > glXQueryClientString(). It would be better, easier (not strcmp) and more > correct to just use glXQueryVersion(). glXQueryVersion will automatically > report the version common to both the client and server (so in this case > 1.2). No, we cannot - glXGetFBConfigs is implemented by glx client (normally when glx client version > 1.2 but in many 1.2 implementations its provided by Xorg). - glXQueryDrawable is only implemented by glx server (when glx server version > 1.2) - for others calls we check if client version > 1.2 else we use SGIX extension > Another thing I don't understand in your patch is why you have wine_glx_t > and wine_glx defined at global scope. It looks like the only place in your > patch they are used is in wgl.c, so why not define wine_glx_t in wgl.c and > make wine_glx static? Sorry if I am missing something. It's for future use by wgl_ext.c. I don't like the idea to duplicate glx version/extensions checks and glXGetProcAddressARB pointer parameter on functions > (Also there is some DEPTH_BITS hack in internal_glGetIntegerv which I > assume is unrelated to this GLX patch?) yes i comment it (i use it for debug) > > i thought that DRI implemented GLX 1.3 specs but seems they use a too > > older x code :( > > http://cvs.sourceforge.net/viewcvs.py/dri/xc/xc/programs/Xserver/GL/glx/ > > Too old perhaps, but that what DRI (and hence ATI) are using. Both support > most of the 1.3 features so there really isn't much of an issue. The > problem is that we cannot assume 1.3 regardless of how old 1.2 is. The > reason for the glx version is so that we can do the right thing in any > case. Not really, many of GLX features are supported by glx clients. And only old clients (ie X versions) reports 1.2 caps (and generaly they support 1.3 extensions) I have only problems with "1.2 glx servers" (who don't support drawable queries), who is the DRI / ATI configuration :( > Also seems like we should be relying on glXGetProcAddress() but need to be > using glXGetProcAddressARB() since nVidia apparently doesn't export the > former. ??? where you see glXGetProcAddress use ? wgl.c:1044: p_glXGetProcAddressARB = wine_dlsym(opengl_handle, "glXGetProcAddressARB", NULL, 0); > Regards, > Aric Regards, Raphael

Dec. 22, 2005

Re: [lostwages] Remove winetools from download page

by wino＠piments.com

On Thu, 22 Dec 2005 02:59:57 +0100, Tom Wickline <twickline(a)gmail.com> wrote: > On 12/21/05, James Hawkins <truiken(a)gmail.com> wrote: >> >> As much as I appreciate the work you, Joachim, and others have put >> into winetools, we're getting closer to the point in time when >> winetools needs to be phased out by a better, more functional wine. Getting closer, sure, but it's not for tommorow >> Part of this process is removing it from the official download page. Part of this process "will be" removing winetool link. "is" implies the present and we are not at this stage with wine yet. > > Shouldn't Wine be fixed before it's removed? Isn't it kind of backwards > to say > we need to have Wine run everything out of the box and to accomplish > this were > going to remove a link to a user friendly tool that currently helps our > users. > I agree, I think there has to be an easy start method with at least half a chance of getting things running. Most new users , many probably new to linux as well will NOT even be aware of what an IRC channel is an probably never met a maiing list either. It seems some of the ppl posting on this thread dont even realise that they are living on a different plane to those actually using wine. If new users cant get some positive result quickly they will just conclude that wine is unusable, and from an average user point , they would be right. If they can be hooked by getting somethings to work they _may just_ go a bit further with some things that dont. Hell , they may even read the doc if they can find it. As for argueing that bugs wont get reported. I was not aware that there was a shortage of things to do in fixing Wine. If Wine scares off new users by expecting everyone to be a software developer it will fail in it's primary role of helping users to migrate to Linux. regards.

Dec. 22, 2005

Poser label issue [Bug 2737]

by Vik Kumar

Hi, I've been looking into Bug 2737 http://bugs.winehq.org/show_bug.cgi?id=2737 and kind of lost on where to go next. Testing on both Poser5 English and Poser6 Japanese versions, The labels (text) on the ui don't show up. As far as the rest of the app goes, Poser 5 seems to be working okay excpet for some redraw issues, so if the lables show up correctly, the app should be quite useable. Anyway, looking at the trace, it looks like it uses DrawTextEx to draw the lables, does something with regions which I can't quite figure out, and renders the ui. The issue seems to be that the label somewhere along the line becomes a 1bit DIB which seems to be wrong. x11drv/dib gives a warning saying: warn:bitmap:X11DRV_DIB_GetImageBits_1 from unknown 1 bit bitmap (ff0000,ff00,ff) to 1 bit DIB, direct color mapping What I tried was to force a negative image on x11drv/dib.c by changing line 901 to: -BYTE neg = 0; +BYTE neg = 1; The attached image shows the result. The black rectangles are where the labels are supposed to be (This is the Poser6 Japanese's register your name & serial number etc dialog) It looks like the DIB is all white (thus the blackness when negating). If I use the non-negated image, this part becomes the same color as the background(transparent?) What the lables are supposed to look like can be found here: http://bugs.winehq.org/attachment.cgi?id=768&action=view and how wine does it is: http://bugs.winehq.org/attachment.cgi?id=767&action=view I'm kind of stuck at this point, not knowing exactly what to do next. I'd aprreciate any help, since it will be nice to have this running. Poser6 demo is available here: http://downloads.e-frontier.com/us/user/product.php?productid=12045&cat=134… Also attached is a trace of WINEDEBUG="+font,+text,+gdi,+bitmap,+seh" wine PoserJ.exe Cheers, Vik

Dec. 22, 2005

Re: Bug 3885

by Raphael

Hi, On Thursday 22 December 2005 03:29, Aric Cyr wrote: > Tom Spear <speeddymon <at> gmail.com> writes: > > Aric Cyr wrote: > > >>>I took a look at the D3D_OK hack, and I believe the problem to be > > >>>CheckDeviceFormat in wined3d/directx.c. This function should return > > >>> an error if > > >>>D3DFMT_D32 is checked for on cards which don't support 32bit depth. > > >>>Currently > > >>>it just returns OK for most formats though. This code is really just > > >>> a stub as > > >>>it stands, and needs to be converted to check if there are any visuals > > >>> that meet > > >>>the requested format's requirements, and if there is, return D3D_OK, > > >>>otherwise > > >>>D3D_NOTAVAILBLE. > > >>> > > >>>To test my theory, try returning D3D_NOTAVAILABLE for the D3DFMT_D32 > > >>> case (you'll need to add it) in wined3d/directx.c in > > >>>IWineD3DImpl_CheckDeviceFormat() > > >>>and see if that fixes that issue or not. This would be just another > > >>> hack though, so a real patch would still be necessary as I decribed > > >>> above. > > > > Well I took a stab at adding the case for D3DFMT_D32, to the bottom of > > the other cases, and let it return the D3DERR_NOTAVAILABLE (as opposed > > to D3D_NOTAVAILABLE), and ran the benchmarks again.. Now it finishes > > the first one and then goes to do the second one, but crashes in a > > different spot, so it seems we also have some stack corrupion (as was > > mentioned in the bug).. So that hack works for now, I would suggest > > that since the rest of that code is stubbed out, we should probably go > > ahead and submit a patch so we can at least run the darn thing and then > > start debugging the stack corruption issue. > > Thanks for testing this out. You have proved my theory correct, so I'll > see about making a patch which will correct CheckDeviceFormat(). Basically > that whole function needs a re-write, so I'd rather do it that way than to > put this hack in there. Especially since, I assume, this problem is not > present on nVidia systems, only ATI. No, as x11 only handle 24 bpp buffers (instead of 32), GLX always reports 24 bpp on such cards (for depth buffers) and many games want 16 or 32 Depth Buffers (only few support 24 bits) for exemple in mine card, i have a lot of config as: id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat ---------------------------------------------------------------------- 0x21 24 tc 0 32 0 r y . 8 8 8 0 4 24 8 16 16 16 16 0 0 None ... 0x67 24 dc 0 32 0 r . . 8 8 8 0 4 24 8 16 16 16 16 4 1 Ncon ... always 24-bpp for Depth Buffer for 32-bpp Pixel Buffer (stupid limitation ?) I hate X11 limitations :( Maybe one day we will have a native alpha support and 32-bpp for buffers on X > > I should add that on the first run, I disabled the title screens between > > benchmarks, and changed the "Display and CPU Settings" so that I was > > using 32-bit textures and triple buffering, and it ran thru several of > > the tests, while on the 2nd and 3rd runs, I left all settings at > > defaults; during run 2, it died just after the title screen for mark #2, > > and during run 3, it died in the middle of mark #2... > > If I'm not mistaken, doesn't 3DMark change resolutions between benchmark > and title screens? If so, it is possible, and quite likely that there is a > resolution change bug in wine. If I recall, I had similar crashing > problems with World of Warcraft if I tried to change resolutions from > in-game. Wine cannot change resolution "in-game". as created window and associated context are managed by x11drv init we cannot handle this case (and never manage case you want to change bpp because of x11 limitations). Anyway i plan (when i'll have time, and when ddraw will use wined3d) to rethink x11drv glx init to only init glx window context on need (so in future only for opengl32 and wined3d) using wanted rendering options. > Regards, > Aric Regards, Raphael

Dec. 22, 2005

Typo on download page for debian packages

by Stefan Munz

Hi, I don't know who who is responsible for maintaining the website, but probably he will read wine-devel ;-) I found a little typo on the download site for the debian packages. The link to the repository works for me only without the space: deb http://wine.sourceforge.net/apt/ binary/ should be: deb http://wine.sourceforge.net/apt/binary/ cu, Stefan

Dec. 22, 2005

Poser label issue [Bug 2737]

by Vikram Kumar

Hi, I've been looking into Bug 2737 http://bugs.winehq.org/show_bug.cgi?id=2737 and kind of lost on where to go next. Testing on both Poser5 English and Poser6 Japanese versions, The labels (text) on the ui don't show up. As far as the rest of the app goes, Poser 5 seems to be working okay excpet for some redraw issues, so if the lables show up correctly, the app should be quite useable. Anyway, looking at the trace, it looks like it uses DrawTextEx to draw the lables, does something with regions which I can't quite figure out, and renders the ui. The issue seems to be that the label somewhere along the line becomes a 1bit DIB which seems to be wrong. x11drv/dib gives a warning saying: warn:bitmap:X11DRV_DIB_GetImageBits_1 from unknown 1 bit bitmap (ff0000,ff00,ff) to 1 bit DIB, direct color mapping What I tried was to force a negative image on x11drv/dib.c by changing line 901 to: -BYTE neg = 0; +BYTE neg = 1; The attached image shows the result. The black rectangles are where the labels are supposed to be (This is the Poser6 Japanese's register your name & serial number etc dialog) It looks like the DIB is all white (thus the blackness when negating). If I use the non-negated image, this part becomes the same color as the background(transparent?) What the lables are supposed to look like can be found here: http://bugs.winehq.org/attachment.cgi?id=768&action=view and how wine does it is: http://bugs.winehq.org/attachment.cgi?id=767&action=view I'm kind of stuck at this point, not knowing exactly what to do next. I'd aprreciate any help, since it will be nice to have this running. Poser6 demo is available here: http://downloads.e-frontier.com/us/user/product.php?productid=12045&cat=134… Also attached is a trace of WINEDEBUG="+font,+text,+gdi,+bitmap,+seh" wine PoserJ.exe Cheers, Vik

Dec. 22, 2005

SPARC assembly won't compile, problems with NT headers

by Troy Rollo

winegcc from the current WineHQ produces assembly output for SPARC systems that cannot be processed by the assembler. 1. "operation combines symbols in different segments" error. This problem arises because the imports code attempts to generate a relocation involving symbols in different segments (one in the text segment and one in the data segment). SPARC assemblers (including gas on a SPARC) cannot deal with relocations involving symbols in different segments. This only affects position independent code and can be avoided by changing the assembly code output in imports.c to something simpler. 2. "can't resolve `_end' {*UND* section} - `.L__wine_spec_rva_base' {.data section}" This problem is more sinister. It arises from the same limitation as the first problem, but is not susceptible to being worked around. The offending code is the code that attempts to generate the NT header of the executable - specifically the SizeOfImage element. I can't see any way at this point to provide for this calculation to be done until after the linker output is generated. I suspect the solution to this problem is to just output a zero in this location and have winegcc modify the executable image to insert the correct values after the linker has created it. Does anybody have any objections to this solution or another approach to suggest? -- Troy Rollo - wine(a)troy.rollo.name

Dec. 22, 2005

Re: [lostwages] Remove winetools from download page

by James Hawkins

On 12/21/05, Tom Wickline <twickline(a)gmail.com> wrote: > > Happy Holiday's > Happy Holidays to you too :) -- James Hawkins

Dec. 22, 2005

Re: [lostwages] Remove winetools from download page

by Tom Wickline

On 12/21/05, James Hawkins <truiken(a)gmail.com> wrote: > On 12/21/05, Tom Wickline <twickline(a)gmail.com> wrote: > > > > So you agree that is currently needed, I believe it should stay until 1.0 > > > > The link or the program? Whether the program itself is needed is up > to the users of winetools, and they show that it's useful in the very > least, which I agree. Whether winetools is useful or not is not in > question though. As I and others have stated in previous emails, wine > should not promote the use of winetools nor restrict its use. > winetools should be a completely separate entity with a separate > mailing list, bugzilla, etc, and the link should not be on wine's > download page. For the reasons stated previously, this is in the best > interest of the developers of wine, but more importantly the users of > wine in the long run. To sum my replies up, I hole heartily agree with you James it's just that we differ on when not if the link should be removed. Winetools helps people run programs that they might not be able to and it helps them do that now. And that's what 99.9% of end users care about, can I run what I want to now? If the answer is no 99.8% of them will leave while .1% might stick around and wait on a fix. Happy Holiday's Tom > > -- > James Hawkins >

Dec. 22, 2005

Re: [lostwages] Remove winetools from download page

by James Hawkins

On 12/21/05, Tom Wickline <twickline(a)gmail.com> wrote: > > So you agree that is currently needed, I believe it should stay until 1.0 > The link or the program? Whether the program itself is needed is up to the users of winetools, and they show that it's useful in the very least, which I agree. Whether winetools is useful or not is not in question though. As I and others have stated in previous emails, wine should not promote the use of winetools nor restrict its use. winetools should be a completely separate entity with a separate mailing list, bugzilla, etc, and the link should not be on wine's download page. For the reasons stated previously, this is in the best interest of the developers of wine, but more importantly the users of wine in the long run. -- James Hawkins

Dec. 22, 2005