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

OpenGL _client regression with ATI.

by Oliver Stieber

Hi, after the whole _client, _window changes for VisualID's DirectX started displaying a bit of garbage at the top of the screen, which I toughed was because the window frames weren't taken into account in the view-port. This is sort of what's happening but it's worse. When I'm using ATI's driver, the viewport comes up as the whole screen, so as I move the window from the top left of my desktop so the clipping changes. It also affects non-DirectX stuff, e.g. with a desktop set in ~/.wine/config some windows come up centred as if the whole screen is taken into account and not just the desktop view, and sometimes a window that should be a given size resizes to the whole screen. With mesa the openGL problems don't appear. I haven't had any problems with any other openGL applications so I can only assume that it's a problem in wine. Send instant messages to your online friends http://uk.messenger.yahoo.com

Feb. 28, 2005

Patch 16316 causes regression in Irfan View

by Ron Jensen

Patch 16316 causes regression in Irfan View. When I attempt to put Irfan View ( http://appdb.winehq.org/appview.php?appId=163 ) into slide show mode (Menu: File -> Slideshow, add some files and Play) Irfan View locks up and needs a control-c at the console to kill it. I will investigate further tomorrow... ChangeSet ID: 16316 CVSROOT: /opt/cvs-commit Module name: wine Changes by: julliard(a)wine.codeweavers.com 2005/02/24 13:42:08 Modified files: dlls/user : painting.c Log message: Repaint the non-client area to work around broken WM_PAINT handlers also when doing a synchronous update with RDW_UPDATENOW. Patch: http://cvs.winehq.org/patch.py?id=16316 Old revision New revision Changes Path 1.19 1.20 +19 -3 wine/dlls/user/painting.c ________________________________________________________________________

Feb. 28, 2005

Re: invisible desktops - major pain in the testing process

by Chris Morgan

> Yes. I don't argue that testing on a visible desktop is a > must. Some people are actually doing that, it seems. Or > maybe that's just you alone... :) Anyway, I tried to make > such results visually distinctive so that we shouldn't drop > all the rest. Too bad it doesn't work. > > > figuring out why it doesn't work is completely useless > > IMO, since the results of the tests running on an > > invisible desktop can't be used for a reasonable > > comparison. > > I see your point, even if find it a bit strong. Ivan's > suggestion is nice, but that requires a probably not so > trivial change in winrash. I wonder if Chris will do it. > What change do you want? The ability for winetest to be able to interact with the desktop? I've tried enabling this before but it didn't seem to have any effect. I've been quite busy lately and haven't had the time to keep on on winrash development. I'd like to turn over maintenance on winrash to someone else, if anyone is interested feel free to email me and I can set you up as an admin on the project. Chris

Feb. 28, 2005

Re: dsound questions

by Ove Kaaven

man, 28,.02.2005 kl. 11.23 -0600, skrev Jeremy White: > In other words, afaict, the current code computes the difference > between the number of bytes that have been played from the input > source stream (buf_writepos) and the end of the data the app has > written (probably_valid_to). It then clips the mixing length to > that size. > > But what it should really be interested is the amount of as yet > unmixed data in the source stream buffer, and that would be > properly computed by taking the difference of probably_valid_to > and dsb->buf_mixpos. It is true that probably_valid_left is the distance between writepos and probably_valid_to, and that this is used to cut off the mixlen. But the original mixlen (before cutting it) is *also* measured from the writepos (in the primary buffer's frame of reference, of course). The value you're apparently after, the amount of as yet unmixed data, is computed from the mixlen shortly after this, by subtracting primary_done (done above the "remaining mixlen" trace). So this should already be taken care of.

Feb. 28, 2005

Re: Tools for identifying what a DLL provides?

by Bill Medland

On February 28, 2005 08:55 am, Andreas Mohr wrote: > Hi, > > On Mon, Feb 28, 2005 at 09:48:40AM -0600, David D. Hagood wrote: > > I have a DLL from a manufacturer that I don't have the source for, nor do > > I have the header or the import library for. > > > > Since Wine developers frequently have to reverse engineer what a given > > DLL provides, does anybody have a good recommendation for a tool that can > > scan the DLL and report what functions it exports, and their arg types > > and return types? > > You really want http://www.dependencywalker.com/ , trust me. > > But probably http://www.pe-explorer.com/ is very useful, too... > > Or maybe even winedump... > > Andreas Mohr Yes, but they aren't going to throw the arguments and return types out are they? The only way to do that, surely, is disassembly to see what is referenced off the stack and returned? -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

Feb. 28, 2005

Re: dsound questions

by Jeremy White

Ove Kaaven wrote: > tor, 24,.02.2005 kl. 22.56 -0600, skrev Jeremy White: > >>Case 1: In the first case, in DSOUND_MixOne, we compute >>a 'probably_valid_to' based on the 'write_pos', which seems quite >>wrong; I believe the logic should be testing whether or not >>there is sufficient data in the mixing buffer, not whether or >>not there is sufficient room in the buffer overall. > > > The probably_valid_to check is for whether there's likely to be > sufficient data in the *source* streaming buffer to warrant filling the > destination buffer. If the app has only half-filled the streaming > buffer, then it's a better idea to only mix what we know it put there, > and mix the rest of the buffer only after the app has written more stuff > to the buffer, rather than mix everything we can, including invalid > data, then having to backtrack and do a full mix reset when the app > overwrites the invalid data with valid data. The existing code should be > correct. Whoops; I think I see the source of the confusion. I meant to say that the computation of 'probably_valid_left' was incorrect (which is what my patch addressed); the use and computation of 'probably_valid_to' is correct afaict. In fact, I believe my code more properly enforces the use of 'probably_valid_to'. In other words, afaict, the current code computes the difference between the number of bytes that have been played from the input source stream (buf_writepos) and the end of the data the app has written (probably_valid_to). It then clips the mixing length to that size. But what it should really be interested is the amount of as yet unmixed data in the source stream buffer, and that would be properly computed by taking the difference of probably_valid_to and dsb->buf_mixpos. Does that make sense? Cheers, Jeremy

Feb. 28, 2005

Re: Tools for identifying what a DLL provides?

by Andreas Mohr

Hi, On Mon, Feb 28, 2005 at 09:48:40AM -0600, David D. Hagood wrote: > I have a DLL from a manufacturer that I don't have the source for, nor do > I have the header or the import library for. > > Since Wine developers frequently have to reverse engineer what a given DLL > provides, does anybody have a good recommendation for a tool that can scan > the DLL and report what functions it exports, and their arg types and > return types? You really want http://www.dependencywalker.com/ , trust me. But probably http://www.pe-explorer.com/ is very useful, too... Or maybe even winedump... Andreas Mohr

Feb. 28, 2005

Re: Wine cabinet.dll FDI Conformace Test Patch

by Andreas Mohr

Hi, On Sun, Feb 27, 2005 at 10:21:15PM -0800, Rizwan Kassim wrote: > Folks, > > Aleksandr Liber and I have put together a set of tests for > cabinet.dll. Before we submit them to wine-patches, can anyone offer > any critiques/input? We plan to submit in a day or two. Cool stuff! It's wonderful to have people work on OSS projects such as Wine during study tasks. (your project has been announced before, but I'm commenting on this now only) > Any advice you can offer will be greatly appreciated! It's an unspoken rule that preprocessor directives (#ifdef, ...) always start at the very beginning of a line to make sure one recognizes immediately which parts of the code are being processed and which ones aren't. AFAICS you're not using wine test suite infrastructure, e.g. ok() etc. Using printf() directly strikes me as being quite bad, too... Apart from that it appears to be very good. Thanks! Andreas Mohr

Feb. 28, 2005

Re: dsound questions

by Ove Kaaven

tor, 24,.02.2005 kl. 22.56 -0600, skrev Jeremy White: > Case 1: In the first case, in DSOUND_MixOne, we compute > a 'probably_valid_to' based on the 'write_pos', which seems quite > wrong; I believe the logic should be testing whether or not > there is sufficient data in the mixing buffer, not whether or > not there is sufficient room in the buffer overall. The probably_valid_to check is for whether there's likely to be sufficient data in the *source* streaming buffer to warrant filling the destination buffer. If the app has only half-filled the streaming buffer, then it's a better idea to only mix what we know it put there, and mix the rest of the buffer only after the app has written more stuff to the buffer, rather than mix everything we can, including invalid data, then having to backtrack and do a full mix reset when the app overwrites the invalid data with valid data. The existing code should be correct. > Then, to my great joy, I found two separate apparent OSS bugs on > two different systems. In one, the result of DSP_GETOPTR would > temporarily 'go backwards' when doing mmaped transfers; in the other, > my laptop would just stop reading data out of an mmapped buffer, > for no apparent reason. Questions: 1) Is there a good set of OSS > test programs (particularly for mmap) I could/should use to simply validate that > my system is rational wrt OSS? 2) Are the performance gains from > DMA mmap really worthwhile? I wonder if mmap mode is buggy and if we wouldn't > be better off swtiching to a pure 'write' approach. In my experience mmap is the only way to get all of good latency, good precision, minimal sound choppage, reduced CPU usage, and reduced Linux scheduler issues. But Cedega's wineoss still have mmap disabled by default since a lot of OSS drivers have bugs. Since ALSA is supposed to be better, mmap is enabled by default for its winealsa.

Feb. 28, 2005

Re: vartest.c - major pain in the build process

by Ivan Leo Puoti

Dimitrie O. Paun wrote: > > >Don't need to do that, there are plenty of tests that run fine >with an invisible desktop, there's enough value in having some >automated tests. Maybe we need to separate the results... > > > I don't really care at all, I just think winrash should be kept and should be improved to run interactive tests too. Ivan.

Feb. 28, 2005