July 2002 - Wine-Devel - list.winehq.org

No X11 input events in DGA2 mode

by Andy MacLean

I was trying to run Starcraft under wine in using the X11 DGA2 mode to get a decent frame rate. I tried running it under various versions of wine and got the same result every time. The problem is that when wine runs the game using DGA2 it ignores all input from the keyboard and mouse and so appears to hang. When running the game with DGA2 support disabled (i.e. not running as root) everything works fine but I get a much lower frame rate. I'm new to wine but I had a stab at fixing the problem which as far as I can see is the following: -> wine creates one X11 display connection for each thread and one 'global' display connection to use for various things like DGA2 which it puts in the 'gdi_display' global variable. The thread specific connections get put in x11drv_thread_data structure pointed to by the driver_data pointer in each thread's thread specific structure. -> wine then switches to DGA2 mode if it can and does an 'XSelectInput' to turn on DGA2 input events. It switches to DGA2 mode using the gdi_display connection so all input events will now come through this connection. -> at some point something asks for new X11 events. It goes into the 'X11DRV_MsgWaitForMultipleObjectsEx' function to poll the X11 display connections for each thread. This ends up calling the 'process_events' function in dlls/x11drv/event.c with the 'x11drv_thread_data' structure for each thread. This is the only function that calls 'process_events', which is the only place that calls any X11 event fetching function outside of 'wineclipserv.c' and 'clipping.c' (which seem do something irrelevant to the dga2 problem). -> but process_events can only look at the thread specific X11 display connections since this is the data it gets passed. I cannot find any code which sets up an 'x11drv_thread_data' structure for gdi_display and XNextEvent is only ever called from inside process_events on data->display. Therefore we never poll gdi_display for X11 events at all so I never get any input. I tested this with some debug output code and wine deffinitely never polls gdi_display for events at any time while running the game. X11DRV_MsgWaitForMultipleObjectsEx explicitly does an XFlush on gdi_display as though it is expecting to have to poll it separately, but it never does ... I tried changing 'process_events' in dlls/x11drv/events.c to the following: static int process_events( struct x11drv_thread_data *data ) { XEvent event; int count = 0; wine_tsx11_lock(); while ( XPending( data->display ) ) { XNextEvent( data->display, &event ); wine_tsx11_unlock(); EVENT_ProcessEvent( &event ); count++; wine_tsx11_lock(); } #ifdef FIX_DGA2_INPUT while ( DGAUsed && gdi_display != NULL && data->display != gdi_display && XPending( gdi_display ) ) { XNextEvent( gdi_display, &event ); wine_tsx11_unlock(); EVENT_ProcessEvent( &event ); count++; wine_tsx11_lock(); } #endif wine_tsx11_unlock(); return count; } And this fixed the problem. What's bugging me though is that if this is the correct answer then how do any programs work at all in DGA2 mode? Wouldn't any program hang in the same way as soon as wine switched to DGA2 mode? It would be handy if this were fixed in the wine code so I don't have to keep downloading source and patching so can someone who knows more about the code please let me know if they think this is worth submitting as a patch or point me in the right direction if this is on the wrong track? Thanks in advance, A.

July 9, 2002

Re: malloc, heapalloc, etc

by Uwe Bonnes

>>>>> "John" == John Lightsey <john(a)nixnuts.net> writes: John> Hi all, I've been playing around with the wininet dll to get a John> windows app I developed running, and I've written a patch that John> fixes the problems with wininet that I've noticed, but it's an John> ugly fix and I'd like to get a little clarification about how heap John> memory is being used in Wine. John> In dlls/wininet/internet.c InternetOpenUrlA() malloc() is used to John> put together the HTTP host header in hostreq. The pointer is then John> passed to HttpAddRequestHeadersA() which creates a buffer with John> HeapAlloc, copies the contents pointed to by hostreq to it then John> frees the buffer with HeapFree. Control then passes back to John> InternetOpenUrlA which does not call free() on the hostreq John> pointer. John> So, my question is which is the encouraged way of doing things? John> HeapAlloc and HeapFree or malloc and free? Also, is the fact that John> free() was not called on hostreq a bug, or am I missing something? John> Please be gentle....I'm a Perl programmer, not a C programmer. If you require memory where there is even a slight chance you expose it to the application program, use HeapAlloc and friends. -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

July 8, 2002

Re: warcraft 3

by Rob Browning

"Jesse Allen" <uh_ja(a)gmx.net> writes: >> Hmm. Sounds suspiciously like the Baldur's Gate movie problem. >> > > Warcraft 3 uses Divx for it's movies. If Baldur's Gate uses it as well, > then it definately related. Not sure -- cd1's moviecd1.bif claims in the first chunk of the file that it's an "Interplay MVE File", whatever that is, and the first bytes claim BIFFV1. FWIW -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD

July 8, 2002

Re: warcraft 3

by Jesse Allen

> Hmm. Sounds suspiciously like the Baldur's Gate movie problem. > Warcraft 3 uses Divx for it's movies. If Baldur's Gate uses it as well, then it definately related. Because War3 uses Divx (http://www.divx.com) it might be easy to debug because I think it's open source. I might as well try fixing it. Another thing that's interesting to me, like nearly a year ago, I would guess, I and a couple other people were asking blizzard to release their trailers in a better format than quicktime. Most people in the forums would say quicktime was the best, and we would say, "have you ever heard of divx?" We suggested divx because of superior compression and quality. (And for me, it works in linux =) And a couple weeks later, they rerelease a bunch of trailers under divx, and announced they licensed it. Even on their website they list for the divx trailers "PC/Linux" which is a big deal for me =) And they like it so much they use it in their latest game. Maybe this is another reason I got the beta =) (and another thing, open the first page of the game manual, it lists they use divx, Freetype 2.0, and zlib. No wonder it works so well under linux. Maybe one of these days they will use SDL ? =) Jesse

July 8, 2002

Re: warcraft 3

by Bobby Bingham

On Mon, Jul 08, 2002 at 04:32:30PM -0500, Rob Browning wrote: > "Jesse Allen" <uh_ja(a)gmx.net> writes: > > >> Hmm. Sounds suspiciously like the Baldur's Gate movie problem. > >> > > > > Warcraft 3 uses Divx for it's movies. If Baldur's Gate uses it as well, > > then it definately related. > > Not sure -- cd1's moviecd1.bif claims in the first chunk of the file > that it's an "Interplay MVE File", whatever that is, and the first > bytes claim BIFFV1. All the movies in the "Movies" directory have extension .mpq, but they are just avi files with divx5 video. but instead of normal "DIVX" fourcc code, they use "BLZ0", but mplayer plays it fine once tweaked for the different fourcc.

July 8, 2002

Re: Debugger

by Eric Pouech

Massimo a écrit : > > Hmmm.... I fiddled a bit with winedbg and found it awful to use.... > Maybe I'm too comfortable with visual debuggers :-) > There's no plan to make a graphical front-end to it, for example extending DDD or > better GVD ? as I wrote some time ago, I have in my tree an implementation of the GDB remote protocol inside the wine debugger, which should let any well behaved gdb graphical front end debug a wine program (to some extent) A+

July 8, 2002

Re: warcraft 3

by Andreas Mohr

On Mon, Jul 08, 2002 at 10:54:53AM -0700, Jesse Allen wrote: > Hi, > > Here's how to get Warcraft 3 running under wine: Wrong place. This should have been appdb.codeweavers.com instead ;-) Well, OK, I'll better add a HOWTO note to it soon. Thanks for this description ! -- Microsoft Licensing 6.0: "Pay us now in advance, so that we can own you later."

July 8, 2002

about programming books

by Andreas Mohr

Hi all, I just created http://wine.codeweavers.com/fom-meta/cache/831.html to list all the Windows programming books I own (16 books ! ;-) I'd be happy if some other people could add an entry, too. That way we'd have an amazing information resource whenever needed. Hmm, I just hope you've got editing capabilities on this page. If you're unable to add something, then please tell me. (or just edit an entry in some FOM category where you're able to edit it, I'll move it there then) Of course I will add more details of the books to the page once I feel bored (actually a separate page per book within a sub category per author would probably be better). Thanks ! -- Microsoft Licensing 6.0: "Pay us now in advance, so that we can own you later."

July 8, 2002

Re: warcraft 3

by Rob Browning

"Jesse Allen" <uh_ja(a)gmx.net> writes: > 3. Close the install program. Go to the directory where war3 is > installed. mv the Movies folder to Movies backup. The game tries > to display a movie clip on start in the retail, and it hangs wine =( Hmm. Sounds suspiciously like the Baldur's Gate movie problem. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD

July 8, 2002

Support for 24bpp when DDBLT_KEYSRC etc are set

by Tony Lambregts

I am working on implementing the flags under DDBLTFX (Bug 841) and in order to do so I needed to understand how the current code worked. While researching this I came up with this patch for the flags DDBLT_KEYSRC/DDBLT_KEYDEST and company. This patch should be faster then the current code since the switch statement is outside the loop. It also adds support for 24bpp colour. The problem that I have with this is that it assumes stretching in both the x and y directions but from what I understand stretching should only be done if the flag DDBLTFX is set and has the operation DDBLTFX_ARITHSTRETCHY in dwDDFX. Is that right or can Marcus Meissner or Lionel Ulmer explain this to me. Change log: added support for 24bpp when the flags DDBLT_KEYSRC/DDBLT_KEYDEST and company are set. Tony Lambregts tony_lambregts(a)telusplanet.net Index: dib.c =================================================================== RCS file: /home/wine/wine/dlls/ddraw/dsurface/dib.c,v retrieving revision 1.11 diff -u -r1.11 dib.c --- dib.c 28 Jun 2002 17:32:25 -0000 1.11 +++ dib.c 8 Jul 2002 19:02:35 -0000 @@ -561,28 +561,54 @@ keyhigh = lpbltfx->ddckDestColorkey.dwColorSpaceHighValue; } - for (y = sy = 0; y < dstheight; y++, sy += yinc) { - sbuf = sbase + (sy >> 16) * sdesc.u1.lPitch; #define COPYROW_COLORKEY(type) { \ - type *s = (type *) sbuf, *d = (type *) dbuf, tmp; \ - for (x = sx = 0; x < dstwidth; x++, sx += xinc) { \ - tmp = s[sx >> 16]; \ - if (tmp < keylow || tmp > keyhigh) d[x] = tmp; \ - } \ - break; } + type *s = (type *) sbuf, *d = (type *) dbuf, tmp; \ + for (y = sy = 0; y < dstheight; y++, sy += yinc) { \ + (LPBYTE)s = sbase + (sy >> 16) * sdesc.u1.lPitch; \ + for (x = sx = 0; x < dstwidth; x++, sx += xinc) { \ + tmp = s[sx >> 16]; \ + if (tmp < keylow || tmp > keyhigh) d[x] = tmp; \ + } \ + (LPBYTE)d += ddesc.u1.lPitch; \ + } \ + break; } - switch (bpp) { - case 1: COPYROW_COLORKEY(BYTE) - case 2: COPYROW_COLORKEY(WORD) - case 4: COPYROW_COLORKEY(DWORD) - default: - FIXME("%s color-keyed blit not implemented for bpp %d!\n", - (dwFlags & DDBLT_KEYSRC) ? "Source" : "Destination", bpp*8); - ret = DDERR_UNSUPPORTED; - goto error; - } - dbuf += ddesc.u1.lPitch; + switch (bpp) { + case 1: COPYROW_COLORKEY(BYTE) + case 2: COPYROW_COLORKEY(WORD) + case 4: COPYROW_COLORKEY(DWORD) + case 3: { + int last_sy = -1; + for (y = sy = 0; y < dstheight; y++, sy += yinc) { + sbuf = sbase + (sy >> 16) * sdesc.u1.lPitch; + if ((sy >> 16) == (last_sy >> 16)) { + /* this sourcerow is the same as last sourcerow - + * copy already stretched row + */ + memcpy(dbuf, dbuf - ddesc.u1.lPitch, width); + } else { + LPBYTE s,d = dbuf; + for (x = sx = 0; x < dstwidth; x++, sx+= xinc) { + DWORD pixel; + + s = sbuf+3*(sx>>16); + pixel = (s[0]<<16)|(s[1]<<8)|s[2]; + d[0] = (pixel>>16)&0xff; + d[1] = (pixel>> 8)&0xff; + d[2] = (pixel )&0xff; + d+=3; + } + } + dbuf += ddesc.u1.lPitch; + last_sy = sy; + } + break;} + default: + FIXME("%s color-keyed blit not implemented for bpp %d!\n", + (dwFlags & DDBLT_KEYSRC) ? "Source" : "Destination", bpp*8); + ret = DDERR_UNSUPPORTED; + goto error; } #undef COPYROW_COLORKEY dwFlags &= ~(DDBLT_KEYSRC | DDBLT_KEYDEST | DDBLT_KEYSRCOVERRIDE | DDBLT_KEYDESTOVERRIDE);

July 8, 2002