April 2010 - Wine-devel - list.winehq.org

Re: Detecting patch sets
by Dan Kegel 13 Apr '10

13 Apr '10

Hi Ge, when I was running patchwatcher, taking the number of patches in the series helped more than it hurt. (It's fairly frequent for people to submit two patchsets, and fairly infrequent for the second patchset to have the same number of patches.) The darn interface needed babysitting, though, since there were always malformed and/or partial series. I think it'd be cool to have a UI where developers could correct their detected patchsets if they don't like what the automated extractor did. That could morph into a way of submitting patchsets in the first place later on. It'd also be cool if other tools - say, a buildbot or a patchwatcher - could monitor the detected patchset stream (to save them from having to maintain their own). - Dan

3 2

Working on "DOS" VGA.
by Morten Rønne 13 Apr '10

13 Apr '10

Hi Wine-devel My name is Morten and I would like for some of my old DOS/WIN95 games to work with wine. :) I know that I most likely could solve this by using DOSbox and/or DOSemu. But I don't consider either of them user friendly in it's raw form. And I hope in the future it could be more of a Go to this menu item, click a few choices and then play game thing. So I have been looking into what one of them is needing (XCOM Apocalypse). The first thing that needs work is the VGA screen driver. The game needs one of the unsupported video modes. After looking further into it, I can see that the current screen driver, needs to be more of an emulator than just a copy of the framebuffer/RAM window to/from the DirectDraw surface. But since I need to do a lot rewrite of the code, to get a emulator into things, I would of course like to test all the stuff that I don't touch (in term of videomodes). But there isn't a test catalog in dlls/krnl386.exe16. That could of course be due to the fact that it is pretty hard to write test for that old platform and get proper test on a live version. Or am I missing something here? Looking over the list of videomodes, I can see that a lot of them says supported. Is that really true or do they simply not break? Again is there anyway to test that those modes are truely supported in my code change (and in the current code)? Another problem that I am facing at a later stage is that most of the games needs to be installed in win95 mode. But I think that most people will run with something like XP, Vista or Win7 as default mode. That will break most of the old installers as DOS version becomes 5.0 or something "silly" like that. So I am thinking about having to create a wrapper program where you can install your old programs through so the mode gets set correctly during install. And perhaps also creates some proper shortcuts in the menu. And perhaps even into the new game database that new windows version have. And thoughts/ideas on this? Another way to handle this would be to do something like a MD5 on the install.exe (hoping that they differ) and then look up in the AppDB, to see which mode to use as installer mode (and run mode). Yes, that would most likely require changes to AppDB. But I can see a use for this even for the above wrapper program (Autodetect using AppDB). Once I get a new VGA "driver" running, I will most likely start looking into INT10h and others that try to interface to the VGA "driver". Best Regards Morten Rønne

7 8

Re: 1/3 d3d9: Add an initial ColorFill regression test.
by Stefan Dösinger 13 Apr '10

13 Apr '10

Ideas for future tests: * default pool textures * default pool rendertarget textures * default pool depth stencil textures * managed pool textures * default pool depthstencil surfaces Am 12.04.2010 um 21:06 schrieb Roderick Colenbrander: > > <0008-d3d9-Add-an-initial-ColorFill-regression-test.patch>

1 0

Re: winmm: MCI system commands are not eligible for auto-open. (try 2)
by Dmitry Timoshkov 13 Apr '10

13 Apr '10

<Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > + FIXME("(%04x) vkey %04X stub\n", dwFlags, lpParms->nVirtKey); That change is unwanted. > - if (dwFlags & MCI_NOTIFY) > - mciDriverNotify((HWND)lpParms->dwCallback, wDevID, > - (dwRet == 0) ? MCI_NOTIFY_SUCCESSFUL : MCI_NOTIFY_FAILURE); > - > + if (MMSYSERR_NOERROR==dwRet && (dwFlags & MCI_NOTIFY)) > + mciDriverNotify((HWND)lpParms->dwCallback, wDevID, MCI_NOTIFY_SUCCESSFUL); > return dwRet; > } > > @@ -1903,10 +1906,9 @@ static DWORD MCI_Sound(UINT wDevID, DWORD dwFlags, LPMCI_SOUND_PARMSW lpParms) > dwRet = sndPlaySoundW(lpParms->lpstrSoundName, SND_SYNC) ? MMSYSERR_NOERROR : MMSYSERR_ERROR; > else > dwRet = MMSYSERR_ERROR; /* what should be done ??? */ > - if (dwFlags & MCI_NOTIFY) > - mciDriverNotify((HWND)lpParms->dwCallback, wDevID, > - (dwRet == 0) ? MCI_NOTIFY_SUCCESSFUL : MCI_NOTIFY_FAILURE); > > + if (MMSYSERR_NOERROR==dwRet && (dwFlags & MCI_NOTIFY)) > + mciDriverNotify((HWND)lpParms->dwCallback, wDevID, MCI_NOTIFY_SUCCESSFUL); > return dwRet; > } Do you have a test case which shows that notofication is not sent is the failure case? Also 'if (MMSYSERR_NOERROR==dwRet' misses spaces, and having comparison reversed doesn't match the style of the surrounding code. -- 1.5.6.3 [text/plain (2B)] -- Dmitry.

4 8

Re: [PATCH 7/7] wined3d: Move A4L4 conversion to the formats table.
by winetestbot＠geldorp.nl 13 Apr '10

13 Apr '10

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://winetestbot.geldorp.nl/JobDetails.pl?Key=1399 Your paranoid android. === WINEBUILD (Wine build VM) === Patch failed

7 9

TestBot moved to new address
by Greg Geldorp 13 Apr '10

13 Apr '10

The TestBot has moved to a new location: http://testbot.winehq.org You will be automatically redirected if you use the old address. Thanks to Jeremy Newman who helped me set this up. Ge.

1 0

Re: [PATCH] d3dx9_36/tests: Move surface tests into surface.c (try 2)
by winetestbot＠geldorp.nl 12 Apr '10

12 Apr '10

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://winetestbot.geldorp.nl/JobDetails.pl?Key=1401 Your paranoid android. === WINEBUILD (Wine build VM) === Make failed

1 0

Re: winmm: MCI system commands are not eligible for auto-open. (try 2)
by Dmitry Timoshkov 12 Apr '10

12 Apr '10

[cc:ing wine-devel] <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > this is the second time that AJ commits a patch of mine despite > a comment of yours. I think that Alexandre has commited your patch slightly in a hurry, usually he waits at least several hours unless the patch is obviously correct (which is not the case here IMO). > Should I send a subsequent patch that takes > all your comments into consideration? In my opinion your patch should be reverted until all the changes have appropriate test cases, and that patch makes the tests pass (i.e. remove existing todo_wine statements). -- Dmitry.

1 0

Re: d3dx9: Implement D3DXDeclaratorFromFVF with tests
by Henri Verbeet 12 Apr '10

12 Apr '10

Formatting, among others.

2 2

Re: [PATCH 10/10] wined3d: Add BLT_OP_COLOR_FILL to blit_supported and use it in BltOverride.
by Henri Verbeet 12 Apr '10

12 Apr '10

On 12 April 2010 12:44, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > + if (ffp_blit.blit_supported(&myDevice->adapter->gl_info, BLIT_OP_COLOR_FILL, > + NULL, 0, 0, NULL, > + &dst_rect, This->resource.usage, This->resource.pool, This->resource.format_desc)) > + { > + return ffp_blit.color_fill(myDevice, This, &dst_rect, color); > } > > - return ffp_blit.color_fill(myDevice, This, &dst_rect, color); > + return cpu_blit.color_fill(myDevice, This, &dst_rect, color); > } > } > Going through struct blit_shader means that you should also check if cpu_blit can do that operation.

1 0