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

Re: x11drv glx deadlocks.

by Raphael

On Tuesday 02 August 2005 01:17, Oliver Stieber wrote: > --- Oliver Stieber <oliver_stieber(a)yahoo.co.uk> wrote: > > Hi, > > Somewhere between 20-07-2005 and 26-07-2005 I've been getting deadlocks > > when I call some glx functions e.g. glXMakeCurrent, I've tracked to > > problem down to a deadlock, prior to calling glXMakeCurrent wined3d calls > > wine_tsx11_lock_ptr, but the call to glXMakeCurrent is raising an event > > in x11drv on a different thread that then tries to call > > wine_tsx11_lock_ptr, resulting in a > > deadlock. > > > > I've looked through the patches send in between 20-07-2005 and 26-07-2005 > > but nothing looked obvious. Should I be calling wine_tsx11_lock_ptr > > before glXMakeCurrent? or should I try to find out what patch caused the > > problem? > > I've removed all the calls to wine_tsx11_lock_ptr in wined3d and it looked > like the problem was desktop mode, > So I switched off desktop mode, and now only one thread is running but > calls to getDC are causing the same problem: > 0009:err:ntdll:RtlpWaitForCriticalSection section 0x7fee5420 > "x11drv_main.c: X11DRV_CritSection" wait timed out in thread 0009, blocked > by 0000, retrying (60 sec) > Are you sure you removed all x11drv locks form d3d9/d3d8/wined3d ? else can you provide all stacks for all threads ? Anyway ENTER_GL() / LEAVE_GL() calls must be used only for Xlib/openGL calls (i have done a long time ago a mini cleanup for that). Example in IWineD3DDeviceImpl_CreateAdditionalSwapChain, this is incorrect <snip> ENTER_GL(); /* Create a new context for this swapchain */ template.visualid = (VisualID)GetPropA(GetDesktopWindow(), "__wine_x11_visual_id"); /* TODO: change this to find a similar visual, but one with a stencil/zbuffer buffer that matches the request (or the best possible if none is requested) */ TRACE("Found x visual ID : %ld\n", template.visualid); object->visInfo = XGetVisualInfo(object->display, VisualIDMask, &template, &num); if (NULL == object->visInfo) { ERR("cannot really get XVisual\n"); LEAVE_GL(); return D3DERR_NOTAVAILABLE; <snip> It should be like that <snip> /* Create a new context for this swapchain */ template.visualid = (VisualID)GetPropA(GetDesktopWindow(), "__wine_x11_visual_id"); /* TODO: change this to find a similar visual, but one with a stencil/zbuffer buffer that matches the request (or the best possible if none is requested) */ TRACE("Found x visual ID : %ld\n", template.visualid); ENTER_GL(); object->visInfo = XGetVisualInfo(object->display, VisualIDMask, &template, &num); LEAVE_GL(); if (NULL == object->visInfo) { ERR("cannot really get XVisual\n"); return D3DERR_NOTAVAILABLE; <snip> Regards, Raphael

Aug. 3, 2005

Re: Help debugging GLXUnsupportedPrivateRequest failure

by Lionel Ulmer

On Wed, Aug 03, 2005 at 12:13:00PM -0500, Alex Villacís Lasso wrote: > No luck. The patch did not change a thing in my configuration. It still > fails with the exact same failed request. Did you test any other OpenGL application (except 'glxinfo') with your set-up to see if this is Wine specific or generic to GL ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

Aug. 3, 2005

Re: fr-025

by Oliver Stieber

--- Andreas Schneider <andreas.schneider(a)linux-gamers.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > fr-25 doesn't display only a white bar in the middle. You can see the "demo" on > the top, where normally a black bar is. And in the middle you se some colored > vertical stripes. > > fixme:d3d:IWineD3DDeviceImpl_SetRenderState (0x403b50a0)->(161,1) not handled yet > fixme:d3d:IWineD3DStateBlockImpl_Apply Unrecognized state block type 0 > fixme:d3d:IWineD3DStateBlockImpl_Apply Unrecognized state block type 0 > fixme:d3d:IWineD3DStateBlockImpl_Apply Unrecognized state block type 0 > fixme:d3d:IWineD3DStateBlockImpl_Apply Unrecognized state block type 0 > fixme:d3d:IWineD3DStateBlockImpl_Apply Unrecognized state block type 0 > fixme:d3d:IWineD3DStateBlockImpl_Apply Unrecognized state block type 0 > fixme:d3d:IWineD3DStateBlockImpl_Apply Unrecognized state block type 0 > fixme:d3d:IWineD3DStateBlockImpl_Apply Unrecognized state block type 0 > > This is the output which loops. > There are two issues, I've found one and a patch is pending, the other is being a bit more of a pain to locate. > > -- andreas > > - -- > http://www.linux-gamers.net - your online gaming resource > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.0 (GNU/Linux) > > iD8DBQFC8NmVf94+j/M+P8YRAr3VAJ9QNCaK/vjcE53NQXi3+BqeFoIIQgCff//3 > 6ytQscKf03IRxeSIRSoDDiM= > =Ov44 > -----END PGP SIGNATURE----- > > ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com

Aug. 3, 2005

threats from MS over Wine's CD/DVD recognition??

by johan kdks

My friend has a Linux PC and when he inserts a CD or DVD, it popups up the cover art automatically and displays all sorts of extended data, like the actors in the film, the studio that released the cd, etc. And we tried 100 or so discs and it recognized every one perfectly, just as good as Windows XP Media Center does, and it even seems to cache the entries since the 2nd time you insert the disc the recognition is instant (first time takes a few seconds). None of the other Linux media players I've used do this--they all use freedb which doesn't work for DVD's, doesn't have extended attributes, and doesn't display any cover art. I've been poking around all day to figure out how it's done. Someone said it seems this Linux project is pulling the data from Microsoft's Windows media server, like XP MC. If that's true, I'm sure Bill isn't too happy. But anyway I figured that code must have been lifted from Wine--part of your "emulation". But I've been digging into Wine and it seems Wine doesn't do this either, at least not anymore. In fact it's conspicuously missing since Wine is a Windows emulator, and under Windows you put a movie in the drive and see the cover art and all the info on the disc, and with Wine you don't. Was this in Wine at some point, and then got yanked because of threats from Microsoft? I actually see no reference to it anywhere. If it's another one of those modules like libdvdcss that every needs to have, but nobody wants to host, it's buried so far underground I can't find it. If Plutohome.org is going to have to pull it soon, somebody should mirror that stuff soon so it doesn't get lost. -- _______________________________________________ NEW! Lycos Dating Search. The only place to search multiple dating sites at once. http://datingsearch.lycos.com

Aug. 3, 2005

Re: WRT: Links and Timeout

by Francois Gouget

On Wed, 3 Aug 2005, Felix Nawothnig wrote: > Francois Gouget wrote: [...] >> However I believe that some people have put up automated replacements based >> on the automated test framework. So pointing to this set of pages would be >> nice (sorry I don't have the URL handy). > > You mean http://test.winehq.com/data/ ? Yes, that looks like it. Doesn't it have a nice global page? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Linux, WinNT, MS-DOS - also known as the Good, the Bad and the Ugly.

Aug. 3, 2005

Re: secur32: add first SSPI test to actually see what work needs to be done

by Stefan Leichter

Am Mittwoch, 3. August 2005 12:05 schrieb Kai Blin: > * Kai Blin <blin(a)gmx.net> [03/08/05, 02:03:27]: > > + sec_status = QuerySecurityPackageInfo( sec_pkg_name, &pkg_info); > > + > > + ok((long)sec_status >= 0L, "Return value of QuerySecurityPackageInfo > > should be >= 0, but is %ld\n", (long)sec_status); + > > Never mind that. After running the tests on Win32, I realized I needed > to check for SEC_E_OK, not 0. I'll resubmit the patch. > > Kai Hello Kai, you have to include your test into programs/winetest/Makefile.in too, to get your test into the winetest.exe, which delivers the results for http://test.winehq.org/data/ . Please write the test either for QuerySecurityPackageInfoA or QuerySecurityPackageInfoW. Bye Stefan

Aug. 3, 2005

Re: WRT: Links and Timeout

by Detlef Riekenberg

Am Mittwoch, den 03.08.2005, 11:18 +0200 schrieb Francois Gouget: > > On the WRT-Page "http://www.astro.gla.ac.uk/users/paulm/WRT/wrt.php", > > the link for "current status of Wine's conformance tests" is dead > > ("http://fgouget.free.fr/wine/tests-en.shtml"). > > The list of tests was really a pain to manage by hand and as it has > grown a lot since then it would be much worse now. So I discontinued > that page a long time ago (more than a year). I found the dead link and just want to inform. > However I believe that some people have put up automated replacements > based on the automated test framework. So pointing to this set of pages > would be nice (sorry I don't have the URL handy). On the Page, mentioned by Felix ("http://test.winehq.com/data/"), the links "Previous Build" and "Next Build" does not work. -- By By ... ... Detlef

Aug. 3, 2005

Re: Help debugging GLXUnsupportedPrivateRequest failure

by Alex Villacís Lasso

Oliver Stieber wrote: >--- Alex Villacís Lasso <a_villacis(a)palosanto.com> wrote: >It looks like you running mesa which should work, I've just sent in a patch that fixes a problem >I' getting which is very similar to yours '[x11drv] backout d3d-stencil-support-os-2'. This may >correct the problem you are having. > > No luck. The patch did not change a thing in my configuration. It still fails with the exact same failed request. Alex Villacís Lasso

Aug. 3, 2005

Re: DSOUND: prevent assertion in mixer.c

by Alex Villacís Lasso

Felix Nawothnig wrote: > Alex Villacís Lasso wrote: > >> wine-pthread: mixer.c:386: DSOUND_MixInBuffer: Assertion >> `adjusted_remainder >= 0' failed. >> wine: Unhandled exception (thread 000a), starting debugger... >> WineDbg starting on pid 0x8 > > > I guess this is preluded by some "length not a multiple of block size" > errors? I've been experiencing those errors with the same failed > assertion in another game and came up with a similar patch but didn't > submit since I think this just hides another bug as it should *not* > happen that buf_mixpos becomes greater than buflen (and this >= above > should probably be ==) at any time. > > IMHO you should at least add an ERR to that branch. > >> --- wine-20050725-cvs/dlls/dsound/mixer.c 2005-06-21 >> 04:43:29.000000000 -0500 >> +++ wine-20050725-cvs-patch/dlls/dsound/mixer.c 2005-08-01 >> 02:16:42.000000000 -0500 >> @@ -491,6 +491,7 @@ >> if (dsb->leadin && (dsb->startpos <= dsb->buf_mixpos)) >> dsb->leadin = FALSE; /* HACK: see above */ >> } >> + else dsb->buf_mixpos = 0; /* %= dsb->buflen; */ > > > And shouldn't it be "%= dsb->buflen;"? I'd think that this causes > looping until new stuff is mixed in... > > Felix > The patch I sent earlier was a tad incorrect: dsb->buf_mixpos == dsb->buflen is a valid state and should be allowed (miscorrection results in some samples being incorrectly looped). The attached patch will now only correct the situation when dsb->buf_mixpos > dsb->buflen, and will now display an ERR before doing so. In addition, the correction sets buf_mixpos back to buflen instead of wrapping or setting to zero, in order to be consistent with the dsb->buf_mixpos == dsb->buflen condition. BTW, I think I located the source of the original assertion: a possible bug in DSOUND_MixerNorm() in dlls/dsound/mixer.c, which is returning one sample more than required to fill the buffer. I think the problem is the "different sample rate" scenario, but I was too tired to hunt for the bug last night. Is the patent babble in DSOUND_MixerNorm() about PerfectPitch for real, or is it just a joke? It would be sad to remove functionality from Wine because of patent issues. Or it could be that I don't have a sense of humor... Changelog: * Correction to earlier assertion patch to allow for buf_mixpos == buflen in non-looping case, fixes looping of one-off mixed samples introduced by previous patch.

Aug. 3, 2005

Re: Move Win16 relay messages to the relay16 channel

by Uwe Bonnes

>>>>> "Richard" == Richard Cohen <richard(a)daijobu.co.uk> writes: Richard> Uwe Bonnes wrote: >> Go ahead with implementing ;-) >> Richard> Here is a implementation that can exclude relay calls from Richard> builtin dlls. I used '<builtin>' as the magic word because '%' Richard> is possible in file names. Richard> Calls to window procedures and DLL attach/detach are still Richard> shown, but that is the same as the original nrelay patch. >> And let's add %deferred% Richard> What do mean by 'deferred'? Don't output anything, until some signal is sent or some key pressed. -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Aug. 3, 2005