March 2007 - Wine-Devel - list.winehq.org

Re: [try3, 1/4] msi: Added handlers for JScript/VBScript actions that call one script function.
by James Hawkins March 1, 2007

March 1, 2007

On 3/1/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > I am resending the entire patchset as James Hawkins suggested. The only > changes from my previous patchset are in patch #2 (add full IDL from > Windows Installer 3.0 vs 2.0 in the old patchset) and patch #3 (added > more proper variant handling using GetDispId as per Rob's suggestion and > removed unnecessary comments as per James' suggestion). > > Just as a reminder, these patches add JScript/VBScript support for > MSI (as the MSI specs specifically state that applications that need > this functionality must install Windows Script themselves) and partial > but easily expandable OLE automation functionality for MSI. As a proof > of concept, sufficient automation support is added to fix bug #7357. > > Patch #1 creates custom action handlers for all 8 script custom action > types using a framework similar to that used for calling DLL functions. > These custom action handlers all converge on one function that is passed > a script and a function to be called (if any), and it outputs these in a > FIXME. > > Changelog: > > * msi: Added handlers for JScript/VBScript actions that call one script > function. > +static DWORD WINAPI ACTION_CallScript( const LPGUID guid ) +{ + msi_custom_action_info *info; + MSIHANDLE hPackage; + UINT r = ERROR_FUNCTION_FAILED; + + info = find_action_by_guid( guid ); + if (!info) + { + ERR("failed to find action %s\n", debugstr_guid( guid) ); + return r; + } + + FIXME("function %s, script %s\n", debugstr_w( info->function ), debugstr_w( info->dllname ) ); + + hPackage = alloc_msihandle( &info->package->hdr ); + if (hPackage) + { + r = S_OK; + MsiCloseHandle( hPackage ); + } + else + ERR("failed to create handle for %p\n", info->package ); + + return r; +} Looks like you're leaking info. If you're going to go down this route, leaving a stub ACTION_CallScript, then just print the FIXME and be on your way. Each patch should be atomic, and assuming this patch gets applied but none of the others do, you're left with some weird code that allocates a handle then frees it for no apparent reason. + r = MSI_RecordReadStream(row, 2, buffer, &sz); + if (r != ERROR_SUCCESS) + { + msi_free(buffer); + return r; + } + + buffer[sz] = 0; + szw = MultiByteToWideChar(CP_ACP, MB_PRECOMPOSED, buffer, -1, bufferw, 0); + bufferw = msi_alloc(sizeof(WCHAR)*szw); + if (!szw) + { + msi_free(bufferw); + return ERROR_FUNCTION_FAILED; + } + + r = MultiByteToWideChar(CP_ACP, MB_PRECOMPOSED, buffer, -1, bufferw, szw); + msi_free(buffer); + if (!r) + { + msi_free(bufferw); + return ERROR_FUNCTION_FAILED; + } This would be a lot cleaner if you used a 'goto done;' at each of these error points. Also, is there a reason you're not using strdupAtoW? done: msi_free(bufferw) ... return r; -- James Hawkins

2 1

Re: Forum proposal
by Carl-Daniel Hailfinger March 1, 2007

March 1, 2007

On 01.03.2007 20:09, Luis C. Busquets Pérez wrote: > Why not having both? Running a forum does not exclude continuing with > the mailing lists and could add users and developpers who find more easy > coordinate through a forum. > > Configuring phpBB (www.phpbb.com) does not take more than 1 hour . I > have made a try in 30 minutes starting from not knowing anything about > this package: > > http://ns2.ilidium.com:8011/ > > Why not trying both systems? Simple. phpBB has had dozens of security holes in the past. Most other forum solutions have had the same share of problems. Now imagine a breakin on a site hosted on winehq. The consequences would be far worse than for the average toy project. Wine depends on people trusting us that the code is legally clean (especially due to various FUD campaigns claiming otherwise). A breakin will always result in claims that the codebase has been polluted with MS code. Such a PR disaster is not something we need. You're of course free to import all mails to this mailing list into your own private forum and make that somehow accessible. Regards, Carl-Daniel -- http://www.hailfinger.org/

2 2

re: Forum proposal
by Dan Kegel March 1, 2007

March 1, 2007

Wojciech wrote: >But there's one thing with forums that IMVHO mailing-lists can't do. TBMS >forums build better comunities than mailing-lists. Mailing lists are just >concentrated on the topics, disallowing any OT. Good. Let's keep it that way. I think we have a great community as it is. If you really want a web interface that makes posting to the mailing list easy, maybe we could get Google Groups to carry wine-devel. It's as close to a nice web interface as you're going to get, I think. The other gateways I've seen between 'forums' and mailing lists all sucked, IMHO. - Dan

1 0

Re: [final, sorry] msi: Expand IDL file to contain all OLE automation interfaces.
by James Hawkins March 1, 2007

March 1, 2007

On 3/1/07, Misha Koshelev <mk144210(a)bcm.tmc.edu> wrote: > Ok, sorry about posting patches to uncomitted patches, I have > reintegrated these changes back into my patches. The change in this > patch is the IDL file now contains all OLE automation interfaces as of > native installer version 3.0 (as opposed to 2.0). > > As a reminder this is part 2 of 4 of my patchset: > > 1. > http://www.winehq.org/pipermail/wine-patches/2007-February/036359.html > 2. This patch > 3. Next patch > 4. > http://www.winehq.org/pipermail/wine-patches/2007-February/036362.html > You need to resubmit the whole series if you resubmit parts of it. -- James Hawkins

2 3

Unknown issue with test.winehq.org
by Paul Vriens March 1, 2007

March 1, 2007

Hi, So finally we have a working winetest executable and the test.winehq.org scripts should be able to handle the new reports. Could someone have a look what the issue currently is on the webserver as I've sent several reports (a few hours ago) and they are not handled yet? Cheers, Paul.

3 5

Re: Re: Forum proposal
by brettholcomb＠bellsouth.net March 1, 2007

March 1, 2007

I fully agree with Jonathan - the mail lists that have gone to forums I've dropped off. I can check the mail lists quickly, easily, filter as necessary and get what I need without having to sign on and wade through a bunch of posts. If people really want forums setup a forum and let those who want it use it. > > From: Jonathan Allen <jonathan(a)barumtrading.co.uk> > Date: 2007/03/01 Thu AM 11:20:18 EST > To: wine-devel(a)winehq.org > Subject: Re: Forum proposal > > On Thu, Mar 01, 2007 at 05:15:03PM +0100, Luis Carlos Busquets Pérez wrote: > > Instead of having the mailing lists, I think that a "forum" would increase > > and facilitate the group working. > > I could agree less. IMHO a mailing list works well by making sure that > everyone gets everything, without them needing to go anywhere to get it. > A forum wil immediately disenfranchise all thsoe who have no immediate > need to go and visit the forum site every day and so will miss important > annoucements and so on. Bad idea. > > Jonathan > > >

2 1

Forum proposal
by Luis Carlos Busquets Pérez March 1, 2007

March 1, 2007

Dear all, Instead of having the mailing lists, I think that a "forum" would increase and facilitate the group working. I wonder if you share my view and who is in charge of the web serving so that trying to set up the forum. Luis C. Busquets Pérez T. +34 93 796 05 81 M. +32 473 353 128 M. +34 620501328

2 1

Error Invalid EXE Format when executing a exe.so built with winelib
by Roger Wimbert March 1, 2007

March 1, 2007

Here is the Debug output: warn:module:load_builtin_dll failed to load .so lib for builtin L"Z:\\bb\\s\\bc\\wine\\dmsw.exe.so": /bb/home/.wine/dosdevices/z:/bb/s/bc/wine/dmsw.exe.so: cannot allocate memory in static TLS block warn:module:load_dll Failed to load module L"Z:\\bb\\s\\bc\\wine\\dmsw.exe.so"; status=c000007b warn:module:load_builtin_dll failed to load .so lib for builtin L"Z:\\bb\\s\\bc\\wine\\dmsw.exe.so": /bb/home/.wine/dosdevices/z:/bb/s/bc/wine/dmsw.exe.so: cannot allocate memory in static TLS block warn:module:load_dll Failed to load module L"Z:\\bb\\s\\bc\\wine\\dmsw.exe.so"; status=c000007b wine: could not load L"Z:\\bb\\s\\bc\\wine\\dmsw.exe.so": Fehlerhaftes EXE-Format f³r It has something to do with TLS memory or threads, but the /lib/tls/libc.so is linked in: (rw 8 amd64) /bb/s/bc/wine 105>ldd dmsw.exe.so linux-gate.so.1 => (0xffffe000) libwine.so.1 => /usr/local/lib/libwine.so.1 (0x557be000) libm.so.6 => /lib/tls/libm.so.6 (0x558e8000) libc.so.6 => /lib/tls/libc.so.6 (0x5590a000) libdl.so.2 => /lib/libdl.so.2 (0x55a1f000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x56555000) Our system: (rw 8 amd64) /bb/s/bc/wine 106>uname -a Linux amd64 2.6.5-7.193-smp #1 SMP Wed Jul 20 14:39:18 UTC 2005 x86_64 x86_64 x86_64 GNU/Linux glibc has version 2.3.3 A simple program does work, but no program which uses threads. wine is created with the 32 bit libraries. If I use the original exe of my program with wine, it does work. Does anyone has an idea what is going wrong? The makefile is attached. Thanks a lot. ### Generated by Winemaker TOPSRCDIR = /bb/s TOPOBJDIR = /bb/s/bc/wine SRCDIR = . SUBDIRS = DLLS = EXES = dmsw.exe ### Common settings CEXTRA = -mno-cygwin -fno-pic -fno-PIC CXXEXTRA = -mno-cygwin CFLAGS = -D_DMSW RCEXTRA = RCFLAGS = -DBB_WINE INCLUDE_PATH = -I. -I/bb/nt/wine -I/bb/s/i -I/bb/fg/i -I/bb/ze/i -I/bb/fe/i -I/bb/pbm/i -I/bb/wb1/i DLL_PATH = LIBRARY_PATH = LIBRARIES = -lmsvcrt40 -lws2_32 -lversion -lnetapi32 -liphlpapi -lcomctl32 -lshlwapi -lwinmm ### dmsw.exe sources and settings dmsw_exe_MODULE = dmsw.exe dmsw_exe_C_SRCS = /bb/s/c/bbcrypt.c \ /bb/s/c/bbdes.c \ /bb/s/c/bbmalloc.c \ /bb/s/c/bbmd5.c \ /bb/s/c/bbo.c \ /bb/s/c/bbtwofish.c \ /bb/s/c/cmp.c \ /bb/s/c/costri.c \ /bb/s/c/cpy.c \ /bb/s/c/datec.c \ /bb/s/c/dfa.c \ /bb/fg/c/dgcode.c \ /bb/fg/c/dgvar.c \ /bb/s/c/dhinfo.c \ /bb/s/c/dholz.c \ /bb/fg/c/digcte.c \ /bb/fg/c/digecm.c \ /bb/fg/c/digranox.c \ /bb/fg/c/digvec.c \ /bb/s/c/dirview.c \ /bb/s/c/dirwalk.c \ /bb/s/c/dmsb.c \ /bb/s/c/dmsc.c \ /bb/s/c/dmsca.c \ /bb/s/c/dmse.c \ /bb/s/c/dmsf.c \ /bb/s/c/dmsfr.c \ /bb/s/c/dmsg.c \ /bb/s/c/dmsh.c \ /bb/s/c/dmshc.c \ /bb/s/c/dmsl.c \ /bb/s/c/dmsliz.c \ /bb/s/c/dmsm.c \ /bb/s/c/dmsmv.c \ /bb/s/c/dmsp.c \ /bb/s/c/dmsr.c \ /bb/s/c/dmss.c \ /bb/s/c/dmssb.c \ /bb/s/c/dmst.c \ /bb/s/c/dmstast.c \ /bb/s/c/dmsw.c \ /bb/s/c/dmswf.c \ /bb/s/c/dmswicon.c \ /bb/s/c/dmsy.c \ /bb/s/c/encode.c \ /bb/s/c/fileleng.c \ /bb/s/c/fordat.c \ /bb/s/c/gtypes.c \ /bb/fg/c/image.c \ /bb/fg/c/imgprint.c \ /bb/s/c/itoa.c \ /bb/fg/c/jpegconv.c \ /bb/s/c/lru.c \ /bb/s/c/ltoa.c \ /bb/s/c/map.c \ /bb/s/c/msleep.c \ /bb/s/c/packbits.c \ /bb/s/c/packdiff.c \ /bb/s/c/pfad.c \ /bb/fg/c/rgbtools.c \ /bb/s/c/rtt.c \ /bb/s/c/scrinfo.c \ /bb/s/c/set.c \ /bb/s/c/sockcom.c \ /bb/s/c/softdum.c \ /bb/s/c/swap.c \ /bb/s/c/syslog.c \ /bb/s/c/textino.c \ /bb/fg/c/tiffconv.c \ /bb/s/c/udpcom.c \ /bb/s/c/utoa.c \ /bb/s/c/vgl.c \ /bb/s/c/w32argv.c \ /bb/fg/c/w32bmp.c \ /bb/s/c/w32error.c \ /bb/s/c/w32font.c \ /bb/fg/c/w32ico.c \ /bb/s/c/w32macadr.c \ /bb/s/c/w32pfad.c \ /bb/s/c/w32pipe.c \ /bb/s/c/w32print.c \ /bb/s/c/w32puts.c \ /bb/s/c/w32reg.c \ /bb/fg/c/w32scalebmp.c \ /bb/s/c/w32screen.c \ /bb/s/c/w32scroll.c \ /bb/s/c/w32toolbar.c \ /bb/s/c/w32tools.c \ /bb/s/c/w32winms.c \ /bb/s/c/wsinit.c \ /bb/s/c/zeitc.c dmsw_exe_CXX_SRCS= dmsw_exe_RC_SRCS = /bb/nt/rc/dmsw/dmsw_wine.rc dmsw_exe_LDFLAGS = -mwindows \ -mno-cygwin dmsw_exe_DLL_PATH= dmsw_exe_DLLS = odbc32 \ ole32 \ oleaut32 \ winspool dmsw_exe_LIBRARY_PATH= dmsw_exe_LIBRARIES= uuid dmsw_exe_OBJS = $(dmsw_exe_C_SRCS:.c=.o) \ $(dmsw_exe_CXX_SRCS:.cpp=.o) \ $(dmsw_exe_RC_SRCS:.rc=.res) ### Global source lists C_SRCS = $(dmsw_exe_C_SRCS) CXX_SRCS = $(dmsw_exe_CXX_SRCS) RC_SRCS = $(dmsw_exe_RC_SRCS) ### Tools CC = winegcc CXX = wineg++ RC = wrc ### Generic targets all: $(SUBDIRS) $(DLLS:%=%.so) $(EXES:%=%.so) ### Build rules .PHONY: all clean dummy $(SUBDIRS): dummy @cd $@ && $(MAKE) # Implicit rules .SUFFIXES: .cpp .rc .res DEFINCL = $(INCLUDE_PATH) $(DEFINES) $(OPTIONS) .c.o: $(CC) -c $(CFLAGS) $(CEXTRA) $(DEFINCL) -o $@ $< .cpp.o: $(CXX) -c $(CXXFLAGS) $(CXXEXTRA) $(DEFINCL) -o $@ $< .cxx.o: $(CXX) -c $(CXXFLAGS) $(CXXEXTRA) $(DEFINCL) -o $@ $< .rc.res: $(RC) $(RCFLAGS) $(RCEXTRA) $(DEFINCL) -fo$@ $< # Rules for cleaning CLEAN_FILES = y.tab.c y.tab.h lex.yy.c core *.orig *.rej \ \\\#*\\\# *~ *% .\\\#* clean:: $(SUBDIRS:%=%/__clean__) $(EXTRASUBDIRS:%=%/__clean__) $(RM) $(CLEAN_FILES) $(RC_SRCS:.rc=.res) $(C_SRCS:.c=.o) $(CXX_SRCS:.cpp=.o) $(RM) $(DLLS:%=%.so) $(EXES:%=%.so) $(EXES:%.exe=%) $(SUBDIRS:%=%/__clean__): dummy cd `dirname $@` && $(MAKE) clean $(EXTRASUBDIRS:%=%/__clean__): dummy -cd `dirname $@` && $(RM) $(CLEAN_FILES) ### Target specific build rules DEFLIB = $(LIBRARY_PATH) $(LIBRARIES) $(DLL_PATH) $(dmsw_exe_MODULE).so: $(dmsw_exe_OBJS) $(CC) $(dmsw_exe_LDFLAGS) -o $@ $(dmsw_exe_OBJS) $(dmsw_exe_LIBRARY_PATH) $(DEFLIB) $(dmsw_exe_DLLS:%=-l%) $(dmsw_exe_LIBRARIES:%=-l%)

2 2

Re: [PATCH] generate stand alone AC_CONFIG_FILES() lines.
by Saulius Krasuckas March 1, 2007

March 1, 2007

* On Tue, 27 Feb 2007, Marcus Meissner wrote: > Another try to generate stand alone AC_CONFIG_FILES lines > to make git merges easier. Thank you Marcus (and others) very much for that :)

1 0

Re: [9/12] WineD3D: When multithreading, call glFinish after drawing
by H. Verbeet March 1, 2007

March 1, 2007

Would GL_NV_fence be usefull here?

2 1

Re: ntdll: implement NtAllocateLocallyUniqueId with server call (resend)
by Alexandre Julliard March 1, 2007

March 1, 2007

Juan Lang <juan_lang(a)yahoo.com> writes: > Any feedback on this one? > > ChangeLog: implement NtAllocateLocallyUniqueId with server call In general it's better to define server-specific types based on simple C types instead of using Windows data types in server requests. This gives us more control about the data layout, and avoids confusion with things like long/LONG etc. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [6/6] d3d9: Add a mova rounding test
by Alexandre Julliard March 1, 2007

March 1, 2007

"H. Verbeet" <hverbeet(a)gmail.com> writes: > It should be noted that native d3d rounds to nearest even while Wine > doesn't. Applications are not supposed to depend on that though. > > Changelog: > - Add a mova rounding test The test fails here: ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so visual.c && touch visual.ok visual.c:405: Test failed: Expected color 00ffff00, got 00000000 (for input -2.400000) visual.c:405: Test failed: Expected color 00ffff00, got 00000000 (for input -1.600000) visual.c:405: Test failed: Expected color 0000ffff, got 00000000 (for input -0.400000) visual.c:405: Test failed: Expected color 0000ffff, got 00000000 (for input 0.400000) visual.c:405: Test failed: Expected color 00ff00ff, got 00000000 (for input 1.600000) visual.c:405: Test failed: Expected color 00ff00ff, got 00000000 (for input 2.400000) make: *** [visual.ok] Error 6 -- Alexandre Julliard julliard(a)winehq.org

3 4

Wine's Wiki Defaced
by Francois Gouget March 1, 2007

March 1, 2007

Someone has defaced Wine's Wiki frontpage. Also I have either forgotten my password or the user accounts don't work anymore. Could someone look into this? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ War doesn't determine who's right. War determines who's left.

2 2

DIB Engine & GSoC
by Benoit Pradelle March 1, 2007

March 1, 2007

Hi, I would like participate to the Google Summer Of Code with Wine by implementing a DIB Engine. I've searched a lot of informations about the DIB Engine but i still got one question : for you, how important is a DIB Engine in Wine ? Ben.

1 0

Re: user32: add more tests for GetUpdateRect()
by Dmitry Timoshkov March 1, 2007

March 1, 2007

"Clinton Stimpson" <cjstimpson(a)utwire.net> wrote: > Here's another test to add to test_GetUpdateRect(). > This case doesn't uses CS_PARENTDC as suggested in bug #7360. > +static LRESULT WINAPI test_GetUpdateRect_window_procA(HWND hwnd, UINT msg, WPARAM wparam, LPARAM lparam) > +{ > + return DefWindowProc(hwnd, msg, wparam, lparam); > +} You can just specify 'cls.lpfnWndProc = DefWindowProcA;' to avoid useless test_GetUpdateRect_window_procA body. > + cls.style = 0; > + cls.lpfnWndProc = test_GetUpdateRect_window_procA; > + cls.cbClsExtra = 0; > + cls.cbWndExtra = 0; > + cls.hInstance = GetModuleHandleA(0); > + cls.hIcon = 0; > + cls.hCursor = LoadCursorA(0, (LPSTR)IDC_ARROW); > + cls.hbrBackground = GetStockObject(WHITE_BRUSH); > + cls.lpszMenuName = NULL; > + cls.lpszClassName = "CSParentDCWindowClass"; Strange class name since it doesn't use CS_PARENTDC style at all. -- Dmitry.

1 0

Re: [2/6] winex11.drv: Try to get an opengl visual with aux buffers
by Vitaliy Margolen March 1, 2007

March 1, 2007

> I don't know if that patch wasn't applied because other patches of my patchset > weren't applied, or because something is wrong with this patch. If something > is wrong with this patch please tell me > @@ -3083,33 +3083,44 @@ BOOL X11DRV_SwapBuffers(X11DRV_PDEVICE *physDev) > XVisualInfo *X11DRV_setup_opengl_visual( Display *display ) > { > XVisualInfo *visual = NULL; > - /* In order to support OpenGL or D3D, we require a double-buffered visual and stencil buffer support, */ > - int dblBuf[] = {GLX_RGBA,GLX_DEPTH_SIZE, 24, GLX_STENCIL_SIZE, 8, GLX_ALPHA_SIZE, 8, GLX_DOUBLEBUFFER, None}; > + /* In order to support OpenGL or D3D, we require a double-buffered visual and stencil buffer support, > + * WineD3D and Some applications can make use of aux buffers > + */ > + int dblBuf[] = {GLX_RGBA,GLX_DEPTH_SIZE, 24, GLX_STENCIL_SIZE, 8, GLX_ALPHA_SIZE, 8, GLX_AUX_BUFFERS, 1, GLX_DOUBLEBUFFER, None}; [skip] > + int dblBuf2[] = {GLX_RGBA,GLX_DEPTH_SIZE, 24, GLX_STENCIL_SIZE, 8, GLX_ALPHA_SIZE, 8, GLX_DOUBLEBUFFER, None}; [skip] > + int dblBuf3[] = {GLX_RGBA,GLX_DEPTH_SIZE, 16, GLX_STENCIL_SIZE, 8, GLX_DOUBLEBUFFER, None}; [skip] > + int dblBuf4[] = {GLX_RGBA,GLX_DEPTH_SIZE, 16, GLX_DOUBLEBUFFER, None}; 3 levels was bad enough. Can we put this in an array and iterate through it instead of adding more levels? Specific comments can go there as well. Vitaliy.

1 0

Re: ntdll: Some code cleanup
by Vitaliy Margolen Feb. 28, 2007

Feb. 28, 2007

Felix Nawothnig wrote: > - if (last) > - { > - LdrShutdownProcess(); > - exit( exit_code ); > - } > - else > - { > - LdrShutdownThread(); > - server_exit_thread( exit_code ); > - } > + NtTerminateThread( GetCurrentThread(), func( arg ) ); > + exit(0); /* To avoid a compiler warning, never reached. */ server_exit_thread() and NtTerminateThread() (which calls server_abort_thread()) are not the same things! Former gracefully exits the current thread freeing it's memory. Later rips it out from the process without freeing any resources. Needless to say you can't do that. Vitaliy.

1 0

Re: kernel32: Remove server-call from ExitThread()
by Dmitry Timoshkov Feb. 28, 2007

Feb. 28, 2007

"Felix Nawothnig" <flexo(a)holycrap.org> wrote: > - if (last) > - { > - LdrShutdownProcess(); > - exit( code ); > - } > - else RtlExitUserThread( code ); > + TerminateThread( GetCurrentThread(), code ); > + exit(code); /* To avoid a compiler warning, never reached. */ > } New code now calls exit() unconditionally killing the whole process. If you follow the TerminateThread way you will notice that exit() is being already called on its time. -- Dmitry.

1 0

Re: [2/6] winex11.drv: Try to get an opengl visual with aux buffers
by Ivan Gyurdiev Feb. 28, 2007

Feb. 28, 2007

Something's wrong with this patch: it has more 2 nested if statements. I suggest early returns on negated condition, gotos, and subroutines to fix the problem :) > I don't know if that patch wasn't applied because other patches of my patchset > weren't applied, or because something is wrong with this patch. If something > is wrong with this patch please tell me > > ------------------------------------------------------------------------ > > From 029e9756abed6c2647950f86e9227ba47d366ebe Mon Sep 17 00:00:00 2001 > From: Stefan Doesinger <stefan(a)codeweavers.com> > Date: Tue, 27 Feb 2007 15:53:43 +0100 > Subject: [PATCH] winex11.drv: Try to get an opengl visual with aux buffers > > Applications may profit from auxilliary buffers. Because we have to find > the visual at initialization time try to find a visual with aux buffers > first, if none is found fall back to the usual default visual without > aux buffers > --- > dlls/winex11.drv/opengl.c | 35 +++++++++++++++++++++++------------ > 1 files changed, 23 insertions(+), 12 deletions(-) > > diff --git a/dlls/winex11.drv/opengl.c b/dlls/winex11.drv/opengl.c > index fdb92ae..9c1060a 100644 > --- a/dlls/winex11.drv/opengl.c > +++ b/dlls/winex11.drv/opengl.c > @@ -3083,33 +3083,44 @@ BOOL X11DRV_SwapBuffers(X11DRV_PDEVICE *physDev) > XVisualInfo *X11DRV_setup_opengl_visual( Display *display ) > { > XVisualInfo *visual = NULL; > - /* In order to support OpenGL or D3D, we require a double-buffered visual and stencil buffer support, */ > - int dblBuf[] = {GLX_RGBA,GLX_DEPTH_SIZE, 24, GLX_STENCIL_SIZE, 8, GLX_ALPHA_SIZE, 8, GLX_DOUBLEBUFFER, None}; > + /* In order to support OpenGL or D3D, we require a double-buffered visual and stencil buffer support, > + * WineD3D and Some applications can make use of aux buffers > + */ > + int dblBuf[] = {GLX_RGBA,GLX_DEPTH_SIZE, 24, GLX_STENCIL_SIZE, 8, GLX_ALPHA_SIZE, 8, GLX_AUX_BUFFERS, 1, GLX_DOUBLEBUFFER, None}; > if (!has_opengl()) return NULL; > > wine_tsx11_lock(); > visual = pglXChooseVisual(display, DefaultScreen(display), dblBuf); > wine_tsx11_unlock(); > if (visual == NULL) { > - /* fallback to 16 bits depth, no alpha */ > - int dblBuf2[] = {GLX_RGBA,GLX_DEPTH_SIZE, 16, GLX_STENCIL_SIZE, 8, GLX_DOUBLEBUFFER, None}; > - WARN("Failed to get a visual with at least 24 bits depth\n"); > + /* Try without aux buffers */ > + int dblBuf2[] = {GLX_RGBA,GLX_DEPTH_SIZE, 24, GLX_STENCIL_SIZE, 8, GLX_ALPHA_SIZE, 8, GLX_DOUBLEBUFFER, None}; > + WARN("Failed to get a visual with at least one aux buffer\n"); > > wine_tsx11_lock(); > visual = pglXChooseVisual(display, DefaultScreen(display), dblBuf2); > wine_tsx11_unlock(); > if (visual == NULL) { > - /* fallback to no stencil */ > - int dblBuf2[] = {GLX_RGBA,GLX_DEPTH_SIZE, 16, GLX_DOUBLEBUFFER, None}; > - WARN("Failed to get a visual with at least 8 bits of stencil\n"); > + /* fallback to 16 bits depth, no alpha */ > + int dblBuf3[] = {GLX_RGBA,GLX_DEPTH_SIZE, 16, GLX_STENCIL_SIZE, 8, GLX_DOUBLEBUFFER, None}; > + WARN("Failed to get a visual with at least 24 bits depth\n"); > > wine_tsx11_lock(); > - visual = pglXChooseVisual(display, DefaultScreen(display), dblBuf2); > + visual = pglXChooseVisual(display, DefaultScreen(display), dblBuf3); > wine_tsx11_unlock(); > if (visual == NULL) { > - /* This should only happen if we cannot find a match with a depth size 16 */ > - FIXME("Failed to find a suitable visual\n"); > - return visual; > + /* fallback to no stencil */ > + int dblBuf4[] = {GLX_RGBA,GLX_DEPTH_SIZE, 16, GLX_DOUBLEBUFFER, None}; > + WARN("Failed to get a visual with at least 8 bits of stencil\n"); > + > + wine_tsx11_lock(); > + visual = pglXChooseVisual(display, DefaultScreen(display), dblBuf4); > + wine_tsx11_unlock(); > + if (visual == NULL) { > + /* This should only happen if we cannot find a match with a depth size 16 */ > + FIXME("Failed to find a suitable visual\n"); > + return visual; > + } > } > } > } > > ------------------------------------------------------------------------ > > >

1 0