- Wine-Devel - list.winehq.org

Resent: [opengl] fix last wgl regression
by Raphael Dec. 22, 2005

Dec. 22, 2005

Resent resync patch with little correction Regards, Raphael On Thursday 15 December 2005 23:59, Raphael wrote: > Hi, > > Thix patch should fix last wgl patch regression > anyway i don't understand why ATI drivers don't support older GLX 1.3 specs > (as 1.4 is already here). > > For glXGetFBConfigs i don't plan to support a compatibility code, > it should be too buggy (on pixel format selection) as was older opengl code > as we can't query visuals > > Changelog: > - fix wgl regression: test glx server version and extensions to use (and > not use glXQueryDrawable on older glx implementations) > > Regards, > Raphael

1 0

Poser label issue [Bug 2737]
by Vik Kumar Dec. 22, 2005

Dec. 22, 2005

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

1 0

Need help fixing deadlock (GDI)
by Cihan Altinay Dec. 22, 2005

Dec. 22, 2005

Hi, I have spent days finding the reason for PowerPoint 2000 causing a deadlock if a file is opened that contains a preview which itself contains a bitmap >90x90 pixels (ie. on the first slide). After inserting some more traces I feel I am pretty close but I'm stuck now. The problem is connected to GDI's StretchBlt (bitblt.c). It calls MFDRV_StretchBlt and then the trouble begins as can be seen from the output: <snip> trace:bitblt:StretchBlt --Start-- trace:gdi:GDI_GetObjPtr (0x3b0c): enter 1 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3b0c): leave 1 trace:gdi:GDI_GetObjPtr (0x3aec): enter 1 trace:dc:DC_GetDCPtr trace:gdi:GDI_GetObjPtr (0x3b0c): enter 2 trace:dc:DC_GetDCPtr trace:bitblt:StretchBlt 0x3aec 0,0 160x120 -> 0x3b0c 0,0 960x720 rop=cc0020 trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 trace:gdi:GetObjectW 0x3af8 24 0x7fc2f760 trace:gdi:GDI_GetObjPtr (0x3af8): enter 3 trace:gdi:GDI_ReleaseObj (0x3af8): leave 3 trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 trace:gdi:GDI_GetObjPtr (0x3aec): enter 3 trace:dc:DC_GetDCPtr trace:gdi:GDI_ReleaseObj (0x3aec): leave 3 trace:metafile:MFDRV_StretchBlt MF_StretchBltViaDIB->len = 20292 rop=cc0020 PixYPM=3780 Caps=96 trace:bitmap:GetDIBits trace:dc:CreateCompatibleDC --Checking lock-- hdc=0x3aec err:syslevel:_CheckNotSysLevel Holding lock 0x7fad49e0 level 3 </snip> Yes well... hdcDst and hdcSrc aren't freed yet from within StretchBlt. There is this comment "FIXME: there is a race condition here"... is that the cause? Btw. this might be the same problem as bug #3125. Can somebody give me a hint on how to tackle this? If you need more output please let me know. Thanks a lot, Cihan

1 0

_itow tests in ntdll/tests
by Paul Vriens Dec. 21, 2005

Dec. 21, 2005

Hi, I was just diving into this as there is failure for months with this test on Winxp-SP2 and W2K3. We call _itow, like this: result = p_itow(ulong2str[0].value, NULL, 10); This however seems not be allowed anymore. Changing it to WCHAR buffer[LARGE_STRI_BUFFER_LENGTH + 1]; result = p_itow(ulong2str[0].value, buffer, 10); make the test succeed, but I don't know what the author wanted with these tests. Any ideas ? Cheers, Paul.

1 0

Poser label issue [Bug 2737]
by Vikram Kumar Dec. 21, 2005

Dec. 21, 2005

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

1 0

Re: sound enabled but no driver checked
by Cihan Altinay Dec. 21, 2005

Dec. 21, 2005

Robert Reif wrote: > Cihan Altinay wrote: > >> Quoting Robert Reif <reif(a)earthlink.net>: >> >> >> >>> Cihan Altinay wrote: >>> >>> >>> >>>> With a fresh wine prefix sound is enabled but I can't >>>> see which driver is used because none of them is checked >>>> in the new winecfg sound dialog. >>>> Did we forget to initialize the boxes on first run? >>>> >>>> Cheers, >>>> Cihan >>>> >>>> >>> >>> Use regedit to show HKCU/Software/wine/Drivers/Audio. >>> Chances are it's empty (no drivers checked) so sound is >>> disabled. It could be set to a driver that is not available >>> but winecfg checks for that and should give you an error. >>> >> >> >> Well... the key doesn't exist unless I run winecfg at least once >> and change something. In that case it's not really important because >> a user will probably do that anyway. >> The only minor issue would be that someone runs winecfg for the first >> time and is satisfied with the defaults (no driver checked -> sound off) >> so without any changes he dismisses winecfg. And in this case it seems >> one of the drivers is used by default (sound on). >> >> Cheers, >> Cihan >> >> >> >> > I have a patch to fix this. OSS is the default if there is no registry > key. Great! Will you submit it?

1 0

has the LGPL licence fell through ?
by Tom Wickline Dec. 21, 2005

Dec. 21, 2005

Yes I have read the licence just re read it for that matter... So why no patches from SpecOps? should Wine move to GPL to keep from being robbed of its code? If your wondering why I'm ranting : http://news.inq7.net/infotech/index.php?index=1&story_id=60585 Tom

10 15

Re: has the LGPL licence fell through ? (forw)
by Joerg Mayer Dec. 21, 2005

Dec. 21, 2005

as a simple reply isn't sent to the list.... ----- Forwarded message from Joerg Mayer <jmayer(a)loplof.de> ----- Date: Wed, 21 Dec 2005 09:22:11 +0100 From: Joerg Mayer <jmayer(a)loplof.de> To: Aric Cyr <Aric.Cyr(a)gmail.com> Subject: Re: has the LGPL licence fell through ? In-Reply-To: <loom.20051221T082013-24(a)post.gmane.org> On Wed, Dec 21, 2005 at 07:48:09AM +0000, Aric Cyr wrote: > Maybe I'll fire off an email to Turbolinux to see what they have to say, > although technically unless I purchase or receive their product I am not > directly entitled to the GPL/LGPL code from them. Anyone have a copy of Can you please let me know why you think that? ---------------------------- 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. ... ------------------------------- So I guess if they are using some code of yours that you provided to them under LGPL, you are entiteld to request the source. In case this goes to court you'll need a copy, but for now it is sufficient to be sure that they are distributing a product based on your code which is covered by the LGPL. Again: It is *you* who granted them the right to use your code, and by putting it under LGPL you made sure that you are entitled to any changes they make to *the* code once they start distributing your code (or derivatives) to thrid parties. That way you can reqeust the changes even when the new product costs $10M. Ciao Joerg -- Joerg Mayer <jmayer(a)loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ----- End forwarded message ----- -- Joerg Mayer <jmayer(a)loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology.

2 1

Bug 3885
by Tom Spear Dec. 21, 2005

Dec. 21, 2005

Hi, I was working on bug 3885 tonight, and am stuck now.. Could someone take a look and test a couple of things? I'm running 2.6 series kernel, and it keeps dieing into the debugger before the main window opens. I think that it will sart with builtin msvcrt with 2.4 series kernel, but not 2.6, but since I'm in the middle of another project, I cant reboot to find out. It will at least start under both series for sure with native msvcrt. Louis Lenders removed a trace line from wine and recompiled and it started, even with builtin, which is kinda weird, since he didnt run it with any traces. So it may be a combination of a bug in that trace, and a bug in the 2.6 kernel.. Once running the app, with either builtin or native msvcrt, it goes thru the first benchmark and then spits out an error dialog box when it goes to start the next one, regardless of which benchmarks the app is told to test.. IOW, you can tell it to run #1 and #2, and it will spit out the error before starting #2, and take you back to the main app window. Or you can tell it to run #1 and #3, and same happens, or you can tell it to run #2 and #3, and same happens, so its not something to do with the way wine is handling the benchmark itself. Louis also hard coded D3D_OK into wine in the right spot and managed to get the program to go thru all benchmarks from 1-16, so wine is mis-reporting something there. If someone could take a look and propose a fix, it would be appreciated, seems to me that the 2 fixes should be fairly trivial to come up with since those 1 line hacks worked to get around the aforementioned problems. If we can get it to start on 2.4 and 2.6 with builtin and get it to go all the way to mark 16 before it spits out an error, then that will be another bug closed, and I will file a separate one for mark 16.. Tom

2 1

[wined3d] Code questions
by Aric Cyr Dec. 21, 2005

Dec. 21, 2005

I just have a couple wined3d code questions/comments that I'd like to clear up and possible submit patches if my understanding is correct. If I am misunderstanding the code please correct me. 1) basetexture.c:BindTexture() Just _before_ we call glBindTexture we call glTexParameteri and either set GL_TEXTURE_MAX_LEVEL or GL_TEXTURE_MIN_FILTER. The comment in the code is: "Always need to reset the number of mipmap levels when rebinding as it is a property of the active texture unit, and another texture may have set it to a different value" However, this doesn't make any sense to me and I believe it to be incorrect. glTexParameter affects the currently bound texture object. If the current and next texture to be bound have different mipmaps levels or parameters it should not be necessary to change these settings as all the state is encapsulated correctly in the OpenGL texture object, which should have been initialized correctly in Device::CreateTexture or BaseTexture::ApplyStateChanges. The reason the current code is bad is two-fold: 1) unneeded state changes on a performance critical path, as texture binding is very frequent and 2) changing the state of a _previous_ texture object, not the current one. The next time we go to use that texture object we will have to reapply all of it's state again, another waste of time. I spent a lot of the weekend debugging wined3d (trying to get anisotropic working in World of Warcraft) and just commenting out the block of code greatly cut down on d3d trace messages and makes the code easier to understand (and faster). 2) device.c::SetupTextureStates() Similar to my previous remark, there seems to be an incorrect state change here as well. glTexEnvf(TEXTURE_FILTER_CONTROL, LOAD_BIAS), glBlendColor() and then glTexEnvfv(TEXTURE_ENV, TEXTURE_ENV_COLOR) are called. All of these are called for each texture state update. However these are all global render states, not per-texture contrary to the comment in the code. Since these states are already being set in Device::SetRenderState() I'm pretty sure they don't need to be set here as well. Well that's all for now. Having started to really dig into wined3d, it seems that some effort in cleaning it up (coding style is way off) and stablizing it before it gets much more unwieldy is due. I'm also willing to help with such a task if there is a consensus that it should be done. Regards, Aric

2 2