wine-devel December 2005

wine-devel@winehq.org

147 participants
299 discussions

Re: Bug 3885
by Tom Spear 22 Dec '05

22 Dec '05

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. 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...

4 3

ATI Opengl regression (DRI?)
by Jesse Allen 22 Dec '05

22 Dec '05

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? Thanks, Jesse

3 5

Resent: [opengl] fix last wgl regression
by Raphael 22 Dec '05

22 Dec '05

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 22 Dec '05

22 Dec '05

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 22 Dec '05

22 Dec '05

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 21 Dec '05

21 Dec '05

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 21 Dec '05

21 Dec '05

1 0

Re: sound enabled but no driver checked
by Cihan Altinay 21 Dec '05

21 Dec '05

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

Re: has the LGPL licence fell through ? (forw)
by Joerg Mayer 21 Dec '05

21 Dec '05

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 21 Dec '05

21 Dec '05

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

← Newer
1
...
5
6
7
8
9
10
11
...
30
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel December 2005