September 2011 - Wine-Devel

Re: Using ApiTrace to improve D3D/OpenGL performance

by Emanuele Oriani

I guess if you can reproduce the same exact frames, then probably you can get real FPS your videocard might crunch, duplicated operation and maybe improve/exclude paths of code which slow down the 'real' rendering? Cheers On 30/09/11 21:15, Henri Verbeet wrote: > On 30 September 2011 22:07, Emanuele Oriani<emaentra(a)ngi.it> wrote: >> This might be useful to understand where some bottlenecks of wined3d might >> be? >> What do you think? >> > Yeah, I'm aware of apitrace, through Mesa. I haven't used it for > debugging wined3d so far, but I probably will at some point. I'm not > sure it's really suited for profiling wined3d much though, other than > for creating something reproducible to profile. (That's useful, but > doesn't solve the entire problem.) >

Sept. 30, 2011

Re: Using ApiTrace to improve D3D/OpenGL performance

by Henri Verbeet

On 30 September 2011 22:07, Emanuele Oriani <emaentra(a)ngi.it> wrote: > This might be useful to understand where some bottlenecks of wined3d might > be? > What do you think? > Yeah, I'm aware of apitrace, through Mesa. I haven't used it for debugging wined3d so far, but I probably will at some point. I'm not sure it's really suited for profiling wined3d much though, other than for creating something reproducible to profile. (That's useful, but doesn't solve the entire problem.)

Sept. 30, 2011

Using ApiTrace to improve D3D/OpenGL performance

by Emanuele Oriani

Dear all, Just wanted to bring to your attention ApiTrace 2.0, http://zrusin.blogspot.com/2011/09/apitrace-20.html . Apparently this tool is quite fast and should allow to play back GL commands, to analyse performance and replay commands. This might be useful to understand where some bottlenecks of wined3d might be? What do you think? Cheers

Sept. 30, 2011

design comments in code or in tests?

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, here's another one you WineConf folks may want to discuss. I've already expressed that there are not enough comments in mmdevapi's code. I thought about adding some, but wondered whether there's any value in using the header format that old code in Wine uses/used for automated doc. Generation (whatever the exact format was). For instance, comments ought to document GetPosition's contract in sufficient detail: - 0 <= GetPosition <= sum of written samples (modulo Frequency) - underruns don't count, it's no wall clock - monotically increasing(?) - should reflect speaker position, not buffering (MSDN says that) Don't look up MSDN. If that were complete enough, I would not have had the need to write as many tests as I did. Then I thought about placing comments in dlls/*/tests/ instead, because the test code is thrown away less often than the dll code. Seriously. Regards, Jörg Höhle

Sept. 30, 2011

Subject: [PATCH 1/2 (try2)] mmdevapi: Don't fail if dwChannelMask is not set correctly

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, Andrew Eikum writes: >(try2): Remove the test found by testbot. My Win7 Home VM passed that >test, so it seems we can expect any behavior. I object to the removal of the test like that. It should be replaced with a comment to explain that the behaviour of IsFormatSupported is very surprising, hence skipped. Actually, that behaviour begs for even more tests to understand what's going on. So far I believed in the invariant: IsFormatSupported == S_OK <=> Initialize == S_OK which is verified using all standard formats (1-2 channels), with one exception on testbot: render.c:396: Initialize (1, 48000x16x1) returns 8889000f unlike IsFormatSupported ^1^ means in exclusive mode, and only there. Now you experienced A. on testbot: IsFormatSupported(dwChannelMask==FFFF) == S_OK, like Initialize which conforms to the above invariant and simply suggests that ChannelMask is not checked at all, therefore this code in Wine seems too much: + fmtex->dwChannelMask != 0 && + fmtex->dwChannelMask != get_channel_mask(pwfx->nChannels)) B. your own Win7 Home system, with dwChannelMask=ffff, IsFormatSupported returns + ok(hr == S_FALSE || hr == AUDCLNT_E_UNSUPPORTED_FORMAT while Initialize returns + ok(hr == S_OK, which is weird. When does IFS return UNSUPPORTED_FORMAT? When does it return S_FALSE? In the latter case, is the suggested format anything else than GetMixFormat? What does exclusive mode return? Unlike in Wine, the shared mode "audio engine" mixer is a completely different SW entity than the exclusive mode "audio device", so it's important to check both. This needs more testing. In particular, tests performed on HW that supports more than 2 channels are welcome. Based on your surprising test result, I'd guess yours is such a system. Unlike DSound, mmdevapi has no GetSpeakerConfig that I'm aware of (short of Device Topology), so I don't know how apps find out about multi-channel abilities. BTW, I believe + fmtex->dwChannelMask != get_channel_mask(pwfx->nChannels)) in Wine is bogus anyway, because it's arbitrary. There exist different 3/4/5/6 channel configurations. Regards, Jörg Höhle

Sept. 30, 2011

Re: winscard

by Mounir IDRASSI

On 9/30/2011 4:47 PM, Marcus Meissner wrote: >> + State = pStates[i].dwEventState& (~SCARD_STATE_CHANGED); >> > + rgReaderStates[i].cbAtr = pStates[i].cbAtr; >> > + memcpy(rgReaderStates[i].rgbAtr, pStates[i].rgbAtr, MAX_ATR_SIZE); > The "MAX_ATR_SIZE" size looks wrong. Should it be perhaps pStates[i].cbAtr > which seems to be the bytecount? I'll answer this since these patches are taken from my original big patch: copying cbAtr bytes makes more sens but copying MAX_ATR_SIZE is not wrong since the two buffers are of the same size and here we are just transferring all bytes from pcsclite side to the WIN32 side. That being said, maybe putting pStates[i].cbAtr will help the patches be accepted. By the way, I want to thank Vincent for taking the time to try to incorporate the winscard code into Wine. Without his dedication, this could languish for many years more! Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr

Sept. 30, 2011

Re: user32: Prioritize focus for dialog owner on EndDialog.

by Erich Hoover

On Fri, Sep 30, 2011 at 8:36 AM, Marvin <testbot(a)testbot.winehq.org> wrote: > ... > === W7PROX64 (64 bit msg) === > Timeout > > === TEST64_W7SP1 (64 bit msg) === > Timeout It seems that these 64-bit tests have been failing for a while (it's clearly not related to my patch). Is anyone already looking into this issue? If not then I'll take a crack at it. Erich Hoover ehoover(a)mines.edu

Sept. 30, 2011

Re: winscard

by Marcus Meissner

On Fri, Sep 30, 2011 at 11:42:26AM +0200, Vincent Hardy wrote: > Hi all, > > Here are four patches that are a partial but functional > implementation of winscard. > > I installed "Belgian Electronic Identity Card MiddleWare" > (http://eid-mw.googlecode.com/files/BeidMW35-6995.msi) > > I tested winscard by starting beid35gui.exe and I can see my > identity card data. > > Moreover, this should help to solve this bug > http://bugs.winehq.org/show_bug.cgi?id=26978. > > Are these 4 patches good enough to be sent to wine-patch ? Patch looks largely good to me. 1 comment I have on quick review below. It is probably hard to write testcases that work without hardware, but if you can think of any, they would be welcome. .... > + State = pStates[i].dwEventState & (~SCARD_STATE_CHANGED); > + rgReaderStates[i].cbAtr = pStates[i].cbAtr; > + memcpy(rgReaderStates[i].rgbAtr, pStates[i].rgbAtr, MAX_ATR_SIZE); The "MAX_ATR_SIZE" size looks wrong. Should it be perhaps pStates[i].cbAtr which seems to be the bytecount? With that clarified you could already send them to wine-patches as-is. Ciao, Marcus

Sept. 30, 2011

Re: user32: Prioritize focus for dialog owner on EndDialog.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=14644 Your paranoid android. === W7PROX64 (64 bit msg) === Timeout === TEST64_W7SP1 (64 bit msg) === Timeout

Sept. 30, 2011

Re: winscard

by Jeff Latimer

On 30/09/11 19:42, Vincent Hardy wrote: > > Are these 4 patches good enough to be sent to wine-patch ? Vincent, normally you would start by adding tests that can confirm the same behaviour in Windows. If you can do that and get the test accepted then you are a long closer to get your patches accepted too. As you start with the tests you need to code the tests for functions you have not implemented in the same patch as a todo wine so that the test will not break the wine test suite.

Sept. 30, 2011

Re: winscard

by Bruno Jesus

On Fri, Sep 30, 2011 at 06:42, Vincent Hardy <vincent.hardy.be(a)gmail.com> wrote: > Hi all, > > Here are four patches that are a partial but functional implementation of > winscard. Congratulations =) > I installed "Belgian Electronic Identity Card MiddleWare" > (http://eid-mw.googlecode.com/files/BeidMW35-6995.msi) > > I tested winscard by starting beid35gui.exe and I can see my identity card > data. I can help you test this (although currently I'm lacking the time to), I have 8 different contact and contactless readers and dozens of different card types. And several demo applications and full fledged hsm applications that run with over 200 smartcards at the same time =) > Moreover, this should help to solve this bug > http://bugs.winehq.org/show_bug.cgi?id=26978. > > Are these 4 patches good enough to be sent to wine-patch ? > > winscard is really useful for me and probably for other people too. I'm not used to patch reviewing but here are my comments: You don't need to check for invalid parameters on the functions, at least in most of them. pcsclite should do that by itself and for example in the SCardListreaders you don't need to interpret AUTOALLOCATE because pcsclite handles that [1]. In SCardConnect you are also checking and returning the invalid parameters error but pcsclite checks that [1]. Again with SCardStatus, I guess it should be as simple as a forward to pcsclite. You're defining MAX_ATR_SIZE 36 but the standard ISO 7816 value is 33 bytes and both pcsclite and windows winscard use 33. At least once you do HeapAlloc + memset zero, usually this can be done by passing a flag HEAP_ZERO_MEMORY to HeapAlloc. > > Vincent > [1] = http://pcsclite.alioth.debian.org/api/winscard__clnt_8c_source.html Best wishes, Bruno

Sept. 30, 2011

Re: Buildbot status

by Frédéric Delanoy

On Fri, Sep 30, 2011 at 00:33, Jerome Leclanche <adys.wh(a)gmail.com> wrote: > On Thu, Sep 29, 2011 at 8:59 PM, Dan Kegel <dank(a)kegel.com> wrote: >> Do you object to Greg's existing testbot emails, too > > Kinda, yeah. I read wine-devel for developer comments, insights, > development about wine, etc. Bot emails feel kind of wrong here; I > especially dislike WTB's because a lot of them are timeout-sort of > spam on one odd machine. Well as long as the test failures remain available from http://source.winehq.org/patches/ (e.g. http://source.winehq.org/patches/data/79447.testfail) I don't see why the list should receive automatic replies/mails. That should probably be opt-in so interested people can still receive messages on their private email address. Don't know if that's currently possible for WTB, though, or if it's a hardcoded list of recipients. Maarten probably knows better

Sept. 30, 2011

winscard

by Vincent Hardy

Hi all, Here are four patches that are a partial but functional implementation of winscard. I installed "Belgian Electronic Identity Card MiddleWare" (http://eid-mw.googlecode.com/files/BeidMW35-6995.msi) I tested winscard by starting beid35gui.exe and I can see my identity card data. Moreover, this should help to solve this bug http://bugs.winehq.org/show_bug.cgi?id=26978. Are these 4 patches good enough to be sent to wine-patch ? winscard is really useful for me and probably for other people too. Vincent

Sept. 30, 2011

Re: Favorite bug: deadlock preventing backtraces?

by Maarten Lankhorst

Hey Dan, On 09/29/2011 06:00 AM, Dan Kegel wrote: > On one of my boxes, if I run winmm/midi.ok in a loop, it will > eventually deadlock/crash > ( http://bugs.winehq.org/show_bug.cgi?id=28388 ): > err:ntdll:RtlpWaitForCriticalSection section 0x110060 "heap.c: main > process heap section" wait timed out in thread 0022, blocked by 001f, > retrying (60 sec) > wine: Critical section 00110060 wait failed at address 0x7bc3484a > (thread 0022), starting debugger... > err:ntdll:RtlpWaitForCriticalSection section 0x110060 "heap.c: main > process heap section" wait timed out in thread 0022, blocked by 001f, > retrying (60 sec) > > Sadly, no backtrace follows ( http://bugs.winehq.org/show_bug.cgi?id=28265 ). > Since I'm not around when it finally happens, I haven't tried btall yet. > > I suppose I should write a shell script to watch for that error > message in the log, > and run btall then... any better ideas? > > (I did try giving winedbg a private heap, didn't seem to prevent the deadlock.) > > I'm wondering if it's because of the lock in virtual_handle_stack_fault, what if you remove that? :P

Sept. 30, 2011

Re: [1/3] kernel32: Reset LastError if GetModuleFileName() succeeds.

by Francois Gouget

On Fri, 30 Sep 2011, Francois Gouget wrote: > This is necessary because LastError may already be set to > ERROR_INSUFFICIENT_BUFFER which would mislead the caller. And of course the older versions of Windows (up to XP SP3!) don't reset lasterror so the test bit of the patch cannot go in. I'd still argue that GetModuleFileNameW() should reset LastError though. -- Francois Gouget <fgouget(a)codeweavers.com>

Sept. 30, 2011

Re: [1/3] kernel32: Reset LastError if GetModuleFileName() succeeds.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=14640 Your paranoid android. === WNT4WSSP6 (32 bit module) === module.c:50: Test failed: LastError was not reset: -559038737 module.c:58: Test failed: LastError was not reset: -559038737 module.c:50: Test failed: LastError was not reset: -559038737 module.c:58: Test failed: LastError was not reset: -559038737 === W2KPROSP4 (32 bit module) === module.c:50: Test failed: LastError was not reset: -559038737 module.c:58: Test failed: LastError was not reset: -559038737 module.c:50: Test failed: LastError was not reset: -559038737 module.c:58: Test failed: LastError was not reset: -559038737 === WXPPROSP3 (32 bit module) === module.c:50: Test failed: LastError was not reset: -559038737 module.c:58: Test failed: LastError was not reset: -559038737 module.c:50: Test failed: LastError was not reset: -559038737 module.c:58: Test failed: LastError was not reset: -559038737

Sept. 30, 2011

Re: Buildbot status

by Jerome Leclanche

On Thu, Sep 29, 2011 at 8:59 PM, Dan Kegel <dank(a)kegel.com> wrote: > Do you object to Greg's existing testbot emails, too Kinda, yeah. I read wine-devel for developer comments, insights, development about wine, etc. Bot emails feel kind of wrong here; I especially dislike WTB's because a lot of them are timeout-sort of spam on one odd machine.

Sept. 29, 2011

Re: gdiplus: Include an alpha channel in HBITMAPs created from Bitmaps.

by Vincent Povirk

Don't commit this. Seems I forgot about top-down vs. bottom-up dibs. On Thu, Sep 29, 2011 at 12:03 PM, Vincent Povirk <madewokherd(a)gmail.com> wrote: > For bug 55549. >

Sept. 29, 2011

Re: Buildbot status

by Dan Kegel

On Thu, Sep 29, 2011 at 1:25 PM, Octavian Voicu <octavian.voicu(a)gmail.com> wrote: > On Thu, Sep 29, 2011 at 12:59 PM, Dan Kegel <dank(a)kegel.com> wrote: >> Do you object to Greg's existing testbot emails, too? > > They're annoying when they are spurious... Yes. That's why I've been focusing on reducing the spurious email rate, and won't turn email to wine-devel on until there have been no spurious emails for five days.

Sept. 29, 2011

Status for the ID3DXEffect interface

by Rico Schüller

Hi, I'd like to say a word for the effect interface in d3dx9_xx.dll, what's already done and what's on the todo list. The parser for binary effects works pretty much. It should nearly parse the effect files completely, but it should fail on effect files which contain functions (if anyone has a binary effect with a function, I'd be interested in it). It is also possible to Get/Set some values, but not yet all, because there are some tricky cases which I haven't figured out completely yet (an example is GetVector() on an D3DXPT_INT). I'm currently working on the correct applying for the states and making some progress with that. But it seems to me that there are a lot of special cases in that. Todo: - Apply the states - Handle parameter blocks - State savings: State saving and restoring in Begin/End is needed. - ASCII effects: The effect could be supplied as byte code or as ASCII text. - ID3DXEffectPool: The support for effect pools is needed. I'm not sure if it might be useful to post an example of a commented binary effect file to make the format "visible" without reading the code. At least it could help when writing the ASCII effect parser. Cheers Rico

Sept. 29, 2011

Re: Buildbot status

by Octavian Voicu

On Thu, Sep 29, 2011 at 12:59 PM, Dan Kegel <dank(a)kegel.com> wrote: > Do you object to Greg's existing testbot emails, too? They're annoying when they are spurious... Octavian

Sept. 29, 2011

[PATCH 0/5] CMD command line parsing (try 5)

by Martin Wilck

Contrary to what I said before, here is another attempt for my CMD patch series. Thanks to Frederic for reviewing this again, I made the suggested changes. Martin Wilck (5): cmd/tests: add tests for command line parsing cmd: use GetCommandline() rather than argv cmd: improve parsing of quotes in command line cmd: fix handling of special characters in command line cmd: fix parameter parsing of quotes and special chars programs/cmd/batch.c | 83 ++++++--- programs/cmd/tests/rsrc.rc | 6 + programs/cmd/tests/test_builtins.cmd.exp | 8 +- programs/cmd/tests/test_cmdline.cmd | 158 +++++++++++++++++ programs/cmd/tests/test_cmdline.cmd.exp | 77 +++++++++ programs/cmd/wcmdmain.c | 276 ++++++++++++------------------ 6 files changed, 407 insertions(+), 201 deletions(-) create mode 100644 programs/cmd/tests/test_cmdline.cmd create mode 100644 programs/cmd/tests/test_cmdline.cmd.exp -- 1.7.3.4

Sept. 29, 2011

Re: [PATCH 0/5] (4th attempt) CMD command line parsing

by Martin Wilck

>> This will also be my last attempt to get this merged. > > Saying this is the best way to ensure that they won't be merged. Why > would people spend time reviewing your code if you've already decided > that you are not going to address the issues they find? I also said that I'd address issues with my code, and I will. Anyway, I was lucky that Dan and Frédéric did review my code again, and so I'll take another shot, contrary to what I said before. Regards Martin

Sept. 29, 2011

Re: Buildbot status

by Dan Kegel

Do you object to Greg's existing testbot emails, too? Well before I flip the switch to turn on email to wine-devel, I will have a nice history of those emails for viewing, so people can judge the actual added noise level for themselves. On Thu, Sep 29, 2011 at 12:20 PM, Jerome Leclanche <adys.wh(a)gmail.com> wrote: > How about just sending error emails to the wine-bots list, AJ and the > patch author? To be really honest I hate reading all the testbot > emails on wine-devel. > > J > > On Thu, Sep 29, 2011 at 7:43 PM, Dan Kegel <dank(a)kegel.com> wrote: >> The buildbot is alive and well and has been finding real >> problems of various sorts roughly once a day for some time. >> I'm not spending much time on it anymore, just watching >> and tweaking occasionally. >> >> The number of spurious failures is tapering off as I >> slowly expand the blacklist and polish up the scripts. >> I plan to turn on email notifications to wine-devel once >> there have been no spurious failure reports for five days, >> probably sometime in October. >> >> http://wiki.winehq.org/BuildBot is up to date in case >> anyone's interested in details. >> >> >> >

Sept. 29, 2011

Re: Buildbot status

by Jerome Leclanche

How about just sending error emails to the wine-bots list, AJ and the patch author? To be really honest I hate reading all the testbot emails on wine-devel. J On Thu, Sep 29, 2011 at 7:43 PM, Dan Kegel <dank(a)kegel.com> wrote: > The buildbot is alive and well and has been finding real > problems of various sorts roughly once a day for some time. > I'm not spending much time on it anymore, just watching > and tweaking occasionally. > > The number of spurious failures is tapering off as I > slowly expand the blacklist and polish up the scripts. > I plan to turn on email notifications to wine-devel once > there have been no spurious failure reports for five days, > probably sometime in October. > > http://wiki.winehq.org/BuildBot is up to date in case > anyone's interested in details. > > >

Sept. 29, 2011