Re: X11Drv: move WGL extension code
On Fri, Sep 01, 2006 at 01:57:24PM +0200, Roderick Colenbrander wrote: The way WGL extensions are loaded is different. The old code correctly advertised the names of available WGL extensions but the wglGetProcAddress code didn't work correctly. Even if an extension wasn't advertised you could get a function pointer to the functions. On Windows wglGetProcAddress would return NULL. Note that (as far as I know), 'wglGetProcAddress' returns NULL on non-existant extensions for all extensions, whether they are GL or WGL ones. This means that our implementation of it is broken (at least on DRI / Mesa) as 'glXGetProcAddress' may return a non-NULL value when querying a non-supported extension. So if we really want to be windows-like, we would need to add a 'function name / extension name' database and check if the extension corresponding to the function is present before actually calling 'glXGetProcAddress'. But as I ever only once got a bug report linked to that, I never took the pain to fix it :-) Lionel (catching up his old mails) PS: I guess that this 'database' may be automatically build by the 'make_opengl' script though so it should not be that hard to do :-) -- Lionel Ulmer - http://www.bbrox.org/
Re: Re: Wine 1.0 Tasks
On Tue, May 30, 2006 at 05:32:26PM -0700, Dan Kegel wrote: On 5/30/06, Scott Ritchie [EMAIL PROTECTED] wrote: It might be, but the heavy hitters I know of who have taken a look at it in detail have concluded that an X change really is needed.] Is this really a problem? Another version of X is due out in about 4 months (probably the earliest we could possibly see Wine 1.0), so why can't we just help write an X extension to tackle the bug? Not really a problem. It'll just take some time to trickle out to the world. We may also have to get Nvidia and ATI on board so they can implement the extension in their drivers. And for it to be taken, I guess we would need to not only write the extension, but a 'reference implementation' (I would guess in DRI / Mesa) and get it approved by the FD.o people. But ohsix's idea to use 'real' X windows 'overlaid' over the single Wine X window would be the easiest idea to investigate (because it would not only fixes this issue but also the mutiple windows with multiple pixel formats problem that the former 'extension' solution does not). Lionel (in 'not even time to read wine-devel' mode :-) ) -- Lionel Ulmer - http://www.bbrox.org/
Re: Google Sketch-Up Not Starting
On Mon, May 01, 2006 at 12:19:47PM +0100, Huw Davies wrote: Yeah, I think the problem is the flags we return. Adding PFD_GENERIC_FORMAT if we don't set PFD_GENERIC_ACCELERATED helps. But then we run into the opengl in a child window bug... Yes, this 'patch' helps it to start: Index: dlls/x11drv/opengl.c === RCS file: /home/wine/wine/dlls/x11drv/opengl.c,v retrieving revision 1.26 diff -u -r1.26 opengl.c --- dlls/x11drv/opengl.c27 Mar 2006 11:30:29 - 1.26 +++ dlls/x11drv/opengl.c1 May 2006 12:11:14 - @@ -384,7 +384,7 @@ ppfd-nVersion = 1; /* These flags are always the same... */ - ppfd-dwFlags = PFD_DRAW_TO_WINDOW | PFD_SUPPORT_OPENGL; + ppfd-dwFlags = PFD_DRAW_TO_WINDOW | PFD_SUPPORT_OPENGL | PFD_GENERIC_FORMAT; /* Now the flags extracted from the Visual */ wine_tsx11_lock(); I looked at the 'code' (ahem :-) ) and it seems that it checks either for 'PFD_GENERIC_FORMAT' / 'PFD_GENERIC_ACCELERATED' flags depending on some internal arguments. It loops multiple times on the pixel formats but the only one it seems to like are the one that are supposedly reported by the un-accelerated reference driver (so if you installed an ICD you are out of luck). I did not find out though why it does not like our accelerated ones though. Note that it does not start either on my WinXP Pro laptop so well, I guess this is an application which is VERY picky on the pixel formats it likes and I hope it will be fixed in a forthcoming patch to the application :-) A 'work-around' for Wine would be report twice the number of visuals, one set 'generic' and the other 'accelerated' (but well, as some applications like SeriousSam check for these bits too, no idea if they would like it). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: What do we need from other projects?
You, you already left too many time speaking about that, you would time to code it :) Not sure. I once debugged something in XFree and already spent hours understanding the code and this was only in a peripheric library (DGA). I can't even imagine the time it would take to go into the 'real' X core to understand how input works :-) PS: it'll be cool to have a GLX extension to change the fbconfig of an existing window and another to share contexts (ala wglShareLists) Well, better petition AJ to have the possibility to 're-create' on the fly the X window, it would be easier :-) And you cannot share lists using glXCreateContext (the last parameter) ? Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: What do we need from other projects?
On Thu, Apr 27, 2006 at 02:35:14PM -0400, Vincent Povirk wrote: Windows probably pulls this off by reading relative mouse movement directly from the device, but I don't think wine developers want to go that route. An X extension would be needed that can detect relative mouse movement that does not generate absolute movement. Well, all (except tablets of course) mouse drivers report relative movements (even in X11 at the lowest level). We just need to export this to user-space via the X11 API. I once started a thread about this on the FD.O lists and people seemed to agree it would be doable and (if not too ugly) accepted into the X.org tree. Now we just need to find someone to code it :) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: SOC project
On Wed, Apr 19, 2006 at 08:35:41AM +, Louis Lenders wrote: what they want :) I'm sure some of the developers that currently work on wined3d can think of proposals that students could work on. At least , wouldn't be fixing bug 2398 be an idea for SOC? Well, I do not really see the link between game and this bug... Bug 2398 does not affect any game at all (the only thing game-related it affects is the NVM toolset AFAIK). Moreover, fixing this may introduce some performance hit in the 'normal' GL code (a bit like Huw's patch for GL on DIB rendering) so it may actually be seen as a regression for gamers :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: SOC project
On Wed, Apr 19, 2006 at 10:59:14AM +0200, Willie Sippel wrote: I'd guess the DIB engine proposal would help there as well. One of the most important improvements, IMHO. Windowed OpenGL support would be nice as well, for game level editors (and many other things)... :-) The DIB engine would only help some games (from my experience, I would guess 5 % of the old DirectX = 7 games which uses GetDC). For all other games, it has absolutely no impact at all. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: SOC project
On Wed, Apr 19, 2006 at 11:07:43PM +0200, Raphael wrote: new Dx9 APIs: IDirect3DSurface9::GetDC IDirect3DSurface9::ReleaseDC Yeah I suppose that they exist... But as it's a stub for now, I suppose that not many application require it :-) Anyway fixing the DIB engine will improve a lot professional applications as photoshop, ... Sure it does. I just wanted to point out the fact the the DIB engine is not the silver bullet that will make all games work faster (as many people seem to believe). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: abort if WINEDEBUG requests functionality that was disabled at configure time
On Sun, Apr 16, 2006 at 01:55:11PM +0100, Mike Hearn wrote: So, I'll say it again - can somebody prove that Wine is faster without the tracing? I doubt it. And if there is a region where the debug channel test slows things down we can always add manual branch prediction hints or just take the trace out of that codepath. So if I take your reasonning further, why even keep the '--disable-debug' / '--disable-trace' options in the configure script ? For me, as long as the user can disable these traces and that he may get 'trace-disabled' builds from stupid sources, the patch can be useful to prevent loosing too much time helping users... Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: NtProtectVirtualMemory
On Thu, Apr 06, 2006 at 10:23:11AM +0200, Stefan Dösinger wrote: That would be usefull too for multithreaded direct3d. Somehow we have to bring another thread to releasing the glxContext, so we can re-use it in a new thread. After discussing this at length on IRC with another coder, we think that the easiest solution would be to have one GL context per thread (and multiple contexts can share the same rendering target and also texture handles). If we add 'intelligent' (i.e. 'lazy' or 'just in time' :-) ) state change evaluation it could even be pretty efficient code-wise (maybe not so efficient in the GL driver though as it may lead to more 'pipeline flushes' than the 'hacky' solution). After we just have to rely that this is properly implemented at the GL driver level... I once wanted to toy with this in the DDraw code base but well, seeing that it will phased out pretty soon I did not do any work on it. On the other hand I could try for some specific games (like DungeonSiege) as an experiment to then port it over to WineD3D. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Starcraft vs. fullscreen
On Thu, Apr 06, 2006 at 10:18:16AM +0200, Stefan Dösinger wrote: Because windows' ddraw.dll restores everything when the app exists. I've added some code to do that do my ddraw lib. I restore the screen mode when the ddraw object is released, and on the last DllMain() unload call, I loop through all ddraw objects, print their refcount, destroy all the surfaces and the ddraw object. This restores the screen res successfully. Well it's the same for memory: who in his right mind in modern operating system still 'free's at exit all 'malloc'ed memory :-) ? Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: NtProtectVirtualMemory
On Fri, Apr 07, 2006 at 11:47:08AM +0200, Stefan Dösinger wrote: I think we need to set the context before the first gl call in a thread. It should be enought to do a ckeck in ENTER_GL() if a context is set for the current thread, and if not create one and set it. Yeah, check as soon as you want to do a GL call if this thread has already his GL context set. And if no, create it (sharing the texture ids with the 'primary' one) and set it as current. I think we need a mutex or something simmilar for all the object structures too. Yes we need to protect all internal states by mutexes (different than the 'GL' mutex as the plan would be to only ever call any GL function when rendering on screen :-) ). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: XVidMode is required for Gamma Control
On Tue, Apr 04, 2006 at 10:42:18AM -0700, Jesse Allen wrote: 1) Allow XVidMode to init for gamma control regardless the setting of UseXVidMode. I already sent a patch for this. 2) Make UseXVidMode default to Y. 3) Tell people to set UseXVidMode manually. 4) do not return an error message if gamma is not supported :-) For me Gamma is a 'nice to have' but like some stubs, the game would work almost as well if we just ignore the call... So instead to forward the error to the application, why should we not put a nice ERR message on the console and just ignore the gamma change and return OK ? Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: XVidMode is required for Gamma Control
On Tue, Apr 04, 2006 at 09:17:24PM +0200, Stefan Dösinger wrote: Of course we might want to fix the mouse code sometimes to make the mouse stay insinde the virtual desktop or the window with XVidMode at all times if that's possible at all. I tried once to do a 'DXGrab' for the virtual desktop but was constrained by the fact that only the connection doing the mouse grab would get any subsequent events. And as in Wine you can have multiple processes sharing the same window, only the one doing the grab would get events and all other processes won't get any mouse / keyboard inputs. Now with the new explorer and all that, maybe one could imagine it forwarding the events to other applications via the server, but well, this is a part of Wine I do not master at all :-) Lionel PS: 'non-exclusive grab' was one of my 'X11' extension I planned to work one day :-) -- Lionel Ulmer - http://www.bbrox.org/
Re: Direct3D, the kernel and ReactOS
On Wed, Mar 29, 2006 at 11:12:06PM +0200, Stefan Dösinger wrote: My long term suggestion is to move the Direct3D-OpenGL translation code from WineD3D to gdi and a win32k sys, and write ddraw.dll, d3d8.dll and d3d9.dll to use that interface. The user mode dlls can be shared with Reactos, and from a technical point of view, even Microsoft's DirectX dlls can be used on Wine(including the hardware emulation layer). If you look back at the wine-devel archives, this point was discussed at the moment 'wined3d' was started (i.e. do we go the MS way with HAL / HEL / ... or our own way with 'wined3d'). And the conclusion was that the DDK interfaces being poorly documented (no idea if they are even *publicly* documented - thus leading to all sort of legal mess if you implement Windows' internal APIs) and that they should not be used by external applications (thus enabling MS to change them for each new DirectX revision) made us choose the other way. Not to mention also that if the 'native' DDraw / D3D / ... DLLs were to work over this API, nobody would spend time working on them :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Direct3D, the kernel and ReactOS
On Sat, Apr 01, 2006 at 11:45:18AM +0200, Stefan Dösinger wrote: Ms has to document all this, because the device drivers sit on the other side of this interface if I'm not mistaken. Of course it is documented for people in companies like NVIDIA or other IHVs, but well, it's not publicly documented (AFAIK - I would gladly be proven otherwise). I would not be surprised to see the full DDK documentation coming with license agreements or NDAs. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: [opengl] Catch BadMatch errors before they can occur.
Oh, and this patch creates a new debug-channel 'swapbuffers' and puts both opengl swapbuffers functions into it. What is the reason for this change ? Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: [opengl] Catch BadMatch errors before they can occur.
On Fri, Mar 24, 2006 at 08:20:08PM +0100, Tomas Carnecky wrote: When debugging opengl applications, I'm usually not interested in the *Swap*Buffers() functions, but in context creation, pbuffers stuff etc. It just writes unnecessary messages into the console. When debugging an application that crashes after 10 minutes it makes the log very big. If someone is interested in the *Swap*Buffers() functions, he still can enable them, but for the majority of the cases its useless. Strange as there are 'opengl' TRACEs for ALL OpenGL functions and extensions so I would guess that those would vastly dwarf the SwapBuffer traces (except if you have an application that does not draw anything on screen and just does swapping its buffers :-) ). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: [opengl] Catch BadMatch errors before they can occur.
On Fri, Mar 24, 2006 at 08:48:16PM +0100, Tomas Carnecky wrote: so.. what about splitting 'opengl' up into 'opengl' (all the opengl functions) and 'oglsetup' with the setup/wgl/pbuffer etc. functions ? Why not 'wgl' ? So we would have 'opengl' for 'core' functions and 'wgl' for the rest. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: opengl32: make the old code before the sync the dibsection to its pixmap patch be selectable at runtime
What says that a gl context can be used by one thread only? In the glxDestroyContext man page it sounds like a context has a sort of reference count, and it can be used by multiple threads. man glXMakeCurrent BadAccess is generated if ctx was current to another thread at the time glXMakeCurrent was called. Seems pretty clear to me, but well, my man pages may be outdated :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: opengl32: make the old code before the sync the dibsection to its pixmap patch be selectable at runtime
On Mon, Mar 20, 2006 at 05:37:50PM +0100, Leon Freitag wrote: Why thread-local variables? AFAIK OpenGL is single-threaded in its nature. I don't know if there are applications that draw opengl in multiple threads in different contents, and if current code would make any problems with these. Well, in OpenGL each thread can have its own context (and you can also bind a context to only one thread which explains why multi-threaded D3D applications are such a pain to support). So you can have multi-threaded GL applications with each thread having its own GL context. So instead of retrieving the context on each ENTER_GL / LEAVE_GL macro using the GLX call, one can simply store the currently bound context for the current thread in a thread-local variable. This is what Mike's patch does. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: opengl32: make the old code before the sync the dibsection to its pixmap patch be selectable at runtime
On Mon, Mar 20, 2006 at 05:09:53PM +0100, Leon Freitag wrote: I don't think it would be that hard to realize. Right now we have the ENTER_GL() macro that gets called before each opengl call (see opengl_ext.c and norm.c) where the check and sync occurs. One solution would be to make two enter_gl functions -- one with the check and one without, and hardcode some database with the function list in the script that generates the files. I agree, not hard at all to do, but the database needs to be maintained and it would mean that upgrading to new extensions would not be 'automatic' as it is now as one would need to review manually all new extensions to check the one that can modify / access the FB. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: opengl32: make the old code before the sync the dibsection to its pixmap patch be selectable at runtime
On Fri, Mar 17, 2006 at 11:47:14AM +, Mike Hearn wrote: There's a new patch to try here: http://plan99.net/~mike/files/glteb.patch Does that work any better? Well, to make this work better, one would need a two-tiered approach: = use thread-local variables to check if it's a 'special' buffer or not (like this patch does) = only do this check on GL APIs that actually modify or read from the frame buffer (basically stuff like glClear, glEnd, gl(Read|Write)Buffer, ...). The last is easy to do for 'core' stuff, a bit harder for extensions though. But anyway, this is mandatory if one day we want to fix the 'windowed' OpenGL code properly (whatever the method we choose as long as we do not have the GLX extension exporting the clip list feature to the application). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: New wined3d configuration window
On Thu, Feb 02, 2006 at 11:01:55AM +0100, Stefan Dösinger wrote: What options do want to add? IMO, the best guideline is to avoid options and try to find it automatically. Most D3D options in the registry exist, because the D3D code is incorrect and needs tweaks for some games - The best thing is to fix the code so it works without tweaks for all games :) Well, while it's a worthy goal to try to auto-detect everything automatically, I think that to have best performance in all cases, configuration options are needed. What people could work on is a centralized, WineHQ-managed database of options (some sort of Application Database but automated). Basically, people would connect to this database and get their Wine configuration automatically updated to get best performance on 'officially supported' games / applications. The only real problem I would see with that scheme would be if multiple applications have the same name (like for example 'game.exe') as this would render the whole 'override' stuff useless. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: opengl: Sync a dibsection to its pixmap before drawing to it via opengl
On Fri, Jan 27, 2006 at 03:48:00PM +, Huw D M Davies wrote: Huw Davies [EMAIL PROTECTED] opengl: Sync a dibsection to its pixmap before drawing to it via opengl Was some benchmarks done to see if this change negatively impacted the performance of applications doing only 'in-window' drawings (e.g. games) and not 'in-dib' drawings ? Lionel (in catch-up mode after coming back from vacation so sorry if this point was already raised later in the week :-) ) -- Lionel Ulmer - http://www.bbrox.org/
Re: [wined3d] Status update: Converting Wined3d to use WGL instead of GLX
On Thu, Jan 12, 2006 at 02:17:11AM +, Aric Cyr wrote: Most of the problems I've come across were GLXContext related... namely due to a problem in wine's wgl which causes an app to think there is a current context, when infact there isn't. (See wglGetCurrentContext in wgl.c, and see what happens when there is no glX context, especially between calls to wglCreateContext and wglMakeCurrent). Could you explain in more details what the problem is ? Another change I made which I'm not sure about and would like feedback for, is to change wgl's process_attach to use wgl functions instead of glX functions. The reason for this is so that the GLXContext that is created will be properly added to the context list so it can be used for other purposes. This should reduce the number of GL contexts by one for all d3d and (behaved) opengl apps. This default context was only added to prevent one game from breaking (do not remember the name of it though) which did some 'glGet' stuff before creating its context. I checked that this worked just fine in Windows but did not work properly in GLX (where calling any GL function without a context set generates an error) so the only way I found out to work around the problem was to add this default context. And if you put in the context_list, in that case 'wglGetCurrentContext' will return this dummy context (instead of NULL as in the current code as it won't find this dummy one in the linked list). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Please read: Wine(HQ) needs a reorganization (AppDB, Bugzilla, etc.)
On Mon, Jan 09, 2006 at 08:42:06PM -0800, Scott Ritchie wrote: Forums are absolutely a good idea. (...) The reason is the same reason I post to these forums - they're far more usable, well-sorted, and accessable than a mailing list. The problem is that (AFAIK) most if not all Wine developpers do not share at all this view (at last for me nothing beats either a mailing list or a newsgroups :-) ). So you will have a nice forum full of Wine questions and no developpers who read them to answer the posts because no-one will care actually reading the forum. I may be wrong though thinking that all other Wine developpers are 'dinosaurs' like me :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Need help in debugging a stack corruption
On Tue, Jan 03, 2006 at 09:17:14PM +0100, Stefan Dösinger wrote: To create interfaces for IDirectDraw1 to 7, I created 4 lpVtbl structures for each version, and I cast most DD7 funtions info the older versions. Only where the type or the number of parameters is different, I use a wrapper function. At DD creation, I use whatever version was requested by the app for the new object. The old dd version used a number of macros to cast the various interfaces(defined in ddcomimpl.h). I don't use them. Might this cause the problem? Best would to see the actual code for that as I do not really understand what you did by reading your description of it. But I still find what you wrote suspicious: if you have 4 VTables you should NEVER cast functions even if they have the same signature - casts are only useful if multiple object versions share the same VTable. Basically (from what I remember :-) ), the pointer to the VTable is stored at the address returned to the application as the COM object. Wine then use a fixed offset to find it's private data from the COM object (basically, the offset between the start of Wine's data to the VTable it returned to the application). Of course, if you have 4 VTables, these offsets are different = you cannot find the address of Wine's internal data without knowing exactly which object was given as an argument to the function. So by just casting, you will apply the wrong offset and so have completely bogus internal datas (for example, if you do another DDraw call inside the called DDraw function), you may use completely bogus values to do the jump (and so maybe jump to a function which does not have the correct signature = stack corruption). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Need help in debugging a stack corruption
On Sat, Jan 07, 2006 at 12:02:27PM +0100, Stefan Dösinger wrote: When creating the Interface, I allocate a IInterfaceImpl structure, and I assign the VTable of the requested version: if(DD7) object-lpVtbl = IDirectDraw7_Vtbl; else if(DD4) (IDirectDraw4Vtbl *) object-lpVtbl = IDirectDraw4_Vtbl; else if(DD2) (IDirectDraw2Vtbl *) object-lpVtbl = IDirectDraw2_Vtbl; else if(DD1) (IDirectDrawVtbl *) object-lpVtbl = IDirectDraw1_Vtbl; Well, an object can have multiple interfaces and still be the same object. So basically if at each new 'QueryInterface' call you allocation a new IInterfaceImpl structure it's wrong regarding COM too... For example, you could create a surface1, query interface it to be a surface2. Then if you changed stuff using the 'surface1' methods (like, for example, attaching a palette to it), you should be able to query the same palette back using the 'surface2' methods ... Which would not be the case using your solution as both interfaces have separate contexts. So your object need to have all vtables set at the beginning and the only difference between the interfaces is the pointer returned to the application. What are the advantages of this? * No need for the Thunk_IInterface_Method functions, except for IDirectDraw::SetDisplayMode. The app calls directly into the methods. * No need for the ICOM_THIS_FROM, COM_INTERFACE_CAST, ... Makros. * No difference between the Implementation address and the address passed to the app. This makes traces easier to read IMO. Yeah but all this is wrong and does not respect what COM is... I did not spend hours writing the Python script that auto-generated most of the initial code for nothing :-) Lionel PS: actually at the beginning of the rewrite we toyed with removing the thunks and adding a pointer to the object data after each VTable. This would have removed all the ICOM_THIS_FROM stuff as getting the address of the object itself would just have been to read the 4 bytes after the VTable. As this idea was frowned upon by AJ, we went the thunks way :-) -- Lionel Ulmer - http://www.bbrox.org/
Re: [Bug 4146] first run usability
On Sun, Dec 25, 2005 at 09:47:39PM +0100, [EMAIL PROTECTED] wrote: Does someone want to reign in this fuck-wit before she pisses of the whole community? Well, tell this to Alexandre as he removed the '-h' stuff some time ago (we got more cases of people having problem with the 'wine foo.exe -- -a -b' syntax than with the '-h' problem). As for the 'Start Menu', it's a packaging issue, not really a Wine issue per se. And finally, why should we prevent people from running Wine as root ? I played the complete MI3 game as root (to have DGA support) and it worked just fine :-) I still have problem with this whole discussion(s): people who do not know Linux should never use a command line window and should do everything from the start / run / foot / ... menu from their favourite distribution. If someone starts Wine from the command line, I certainly expects him/her to be at least knowledgeable enough in how Linux works. So effort should be spent on Desktop integration instead of futile stuff like adding '-h' help message or a 'running as root' protection. Make of it what you like, I'm tired of pissing into the wind. See you all in 10 years time for 1.0 Yup, maybe by then we will see some patches too instead of just rants ? Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: [wined3d] Converting Wined3d to use WGL instead of GLX
On Wed, Dec 14, 2005 at 03:53:12AM +, Aric Cyr wrote: So now I am stuck... if I use wglGetProcAddress for OpenGL extensions I get crashes in most D3D9 applications. If I use glXGetProcAddress in wined3d everything works fine, but then wined3d is still dependent on glx. The answer is easy (did not read the complete thread in details to know if you found out the solution or not): basically, 'wglGetProcAddress' returns functions as expected by Win32 applications, so using the 'stdcall' calling convention whereas 'glXGetProcAddress' returns them in the standard Unix calling convention 'cdecl'. So you basically have the same problem with GL extensions that you had with direct linking to OpenGL32.DLL instead of to libGL.so = all the calls going through function pointers that you retrieved via 'wglGetProcAddress' will go through thunks to change the calling convention (at the price of a slight performance hit). Moreover, you will have a nice 'header' head-ache as you won't be able to rely on the Linux distribution's version of 'glext.h' but on a version compatible with Windows that adds the proper 'STDCALL' types to the function pointer prototypes. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: DirectDraw over Direct3D
On Mon, Dec 05, 2005 at 08:17:38AM +0100, Stefan Dösinger wrote: I hope I can come up with a patch for testing this week, then we can have a look ;) I think that to merge Roderick's and your patch, the best would be to directly hook WineD3D even at the 2D level and not have DDraw hook DDraw's D3D which then goes into WineD3D. This way we would have an unified DDraw. Of course, then the problem remains of what to do with older cards :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: DirectDraw over Direct3D
On Sun, Dec 04, 2005 at 07:27:29PM -0700, Jesse Allen wrote: Is Starcraft really that slow? How does this compare with using DGA? Nothing can beat DGA (actually DGA2 as you would need depth change to go to 8 bit colours to run StarCraft) in raw speed as it is the method which does copy the less memory over. This patch seems similar to glSDL where it wraps SDL's 2d API to OpenGL. The good thing about this it can provide acceleration and not require root like DGA. The bad thing with this idea is that it can't be used on older video cards or even some newer ones that lack proper direct rendering. The problem is not direct rendering, it's more 'basic' OpenGL acceleration. Am I correct that even when just doing depth conversions, without direct rendering it will still be slow? If you have accelerated OpenGL rendering but without direct access, I think that it should still be faster than the current method (as you would 1) move less data over the GPU bus and 2) do less CPU computation on a big amount of data). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: DirectDraw over Direct3D
On Mon, Dec 05, 2005 at 10:22:23PM +0100, Peter Beutner wrote: Isn't indirect rendering always unaccelerated, i.e. done in software? Nope. Indirect means only that all your OpenGL commands are encapsuled into GLX commands and then serialized over the X network link (which could be a local Unix socket) and deserialized at the other side before being sent to the graphic card. It may well be that no current Linux GL drivers support accelerated indirect rendring (although I think that the NVIDIA drivers support it - would verify it if I had GL installed on my head-less server box) and you may be right in the current situation if not in the terms to use to describe it :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: ddraw: make some driver info not const
On Fri, Dec 02, 2005 at 12:11:34PM -0700, Vitaliy Margolen wrote: Friday, December 2, 2005, 11:46:39 AM, Rein Klazes wrote: Hi, [skip] Making this information not const makes the application proceed further. Changelog: dlls/ddraw : ddraw_hal.c, ddraw_user.c Make some driver info not const, some applications want to modify it. This is wrong. No user program should modify our internal data. I think you need to copy this data into heap before passing it to the app. You should make simple test to check if the data returned on windows is within heap or not. Yeah, I agree with Vitaliy here... We were alread hit multiple times by this bug in other cases: Wine should never send to the application actual private data as many games expect to use these values to do actual processing. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Missing WGL function declarations in wingdi.h
Anyone have problems with me submitting a patch which would move the relevant (i.e. not all) parts of dlls/opengl32/wgl.h into include/wingdi.h? Not from me. It simply that when I did the OpenGL work, 'winelib' was not really a priority and so I did not think about putting the 'wgl.h' headers somewhere usable for something else than the GL library itself. Anyway, about your D3D over WGL project, I am still wondering how you are going to link 'wined3d' against OpenGL32.DLL. Direct linking or 'GetProcAddress' linking ? If it's the former, will you PE-link against OpenGL32.DLL or ELF-link against libGL.so ? Just wondering because if it's the former, you also need a complete set of 'GL' headers in Wine to have the stdcall version of all GL calls (and pay the price of thunking on each GL call). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Diablo II and Direct3D?
Apparently the video test won't detect d3d right with a wine desktop. Just sent a patch which should fix this. At least now I can choose 'Direct3D' from the list :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Fwd: MBR was destroyed
If you run WINE only as user (not as root) this just cannot happen. Well, except if (as in my old Slackware install), the access rights for the disk are like this: brw-rw 1 root disk 3, 0 Apr 28 1995 /dev/hda And that the user is in the 'disk' group. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Fwd: Re: Fwd: MBR was destroyed
On Sun, Nov 20, 2005 at 07:06:29PM +0100, seorge wrote: Yes, it's kill MBR when run it as a regular user. Can you paste the result of 'ls -l /dev/hda*' and also the result of 'groups' in a mail ? Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Drop the PFD_GENERIC_ACCELERATED flag?
Thanks for the hint. :) So something like the attached patch would be ok? Well, it looks OK for me so you can submit it. I would have been more 'brutal' than you: if on Windows one does not see an example of a pixel format with this flag set, just never set it on Wine either :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Drop the PFD_GENERIC_ACCELERATED flag?
On Wed, Nov 16, 2005 at 03:21:29PM +0100, Peter Beutner wrote: At the moment wine always set the PFD_GENERIC_ACCELERATED flag in X11DRV_DescribePixelFormat. SeriousSam uses this flag to determine if the pixelformat is hardware accelerated. If the flag is set it is interpreted as _no_ hardware acceleration available. Well, the best way to check this would be to run a test case on a Windows box with OpenGL installed and accelerated. Then create the most standard pixel format (ie double buffer + depth buffer) and see what the pixel format is. If it does not fill GENERIC_ACCELERATED, we should do the same in Wine. Note that the equivalent does not really exist in GLX (except maybe between the direct / indirect rendering pathes but this is not the same distinction than in Windows). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: request small changes to winecfg
1/ emulate desktop is still at a historic size of 640,480 which at least on my screen is too small to display winecfg's natural height next time I run it. Would 600x800 be a better default? I need to resend my patch which keeps the previous Desktop version set when disabling it. This way once you set it to a correct value, it will remember what you asked for when you re-enable it. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: RFC: Presentation for Desktop Architecture meeting
OK, here is my wish list from the X.org guys: - relative mouse movement reporting. This is a must-have to have proper DInput support without the hacks we currently have in the code. Extension already discussed with X people on the mailing lists and they seem OK with it. Now we just need to find someone who codes it :-) As said, need to check if the XInput stuff could be re-used (last time I checked no as you cannot take control with XInput of the 'core' device - i.e. the mouse). - full support for resolution / depth switching. A nice idea was discussed the other day on the fd.o lists: what about being able to easily start a new display using an X API which would start a new X screen. This screen could then be used for full-screen games and would support any requested depth / resolution change (the problem with the former - depth change - is that clients need to support it and so the 'new screen' idea would solve this problem as one could still have legacy X applications running on the 'main screen' while still have complete control of depth / resolution on this secondary screen). Then some 'nice to have' which would help in the GL / D3D front but may be out of FD.O scope (and for which work-arounds are known): - GL (GLX ?) extension which would remove the 'thread-affinity' from GL. I.e. a GL context would be at the process level and not at an application level. An even better solution would to be able to create 'shareable' contexts which another thread could attach to (i.e. remove the one thread = one context rule). - GLX extension that would export the 'clip-list' functionnalities of cards (or at lest the one which is in the X code itself). Would help on applications (like Wine) that do their own in-window clipping. - same point as before but for Xv the day we will re-add this code for accelerated YUV display. Some 'misc' stuff that is really in the 'we could use it' category: - have 'connection-level' configuration. Basically, if a client X change an X setting (resolution, mouse acceleration, ...), as soon as this client exits, restore the previous configuration. Would be useful to prevent having people restarting X because Wine crashed after having changed the resolution using XRand. - have a non-connection limited mouse-grab. To explain better, this would enable one to grab the pointer into a window (i.e. the mouse would never leave this window) while still sending events to all connections and not only to the connection which started the grab. This could be nice to simulate 'full-screen desktop mode' or for DXGrab. No idea if with Wine's current event model this is still usefull though. Another 'let's dream' possibilities: - direct frame buffer access :-) And finally, not in my domain, but investigate re-using something from FD.O for the fabled DIB engine (extensions to Cairo, ...) ? Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: [DDraw] Fix AoE2 font rendering (in most cases)
Does this fix bug http://bugs.winehq.org/show_bug.cgi?id=2666 including the problems with warblade? No idea actually for Warblade but at least for AoE2 it fixes the fonts in the game itself. The fonts in the menu are still black (and from my tests in QEMU they should be white instead). Will attach the patch to the bug report and wait for answers Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: The Holy Grail - Wine 0.9 - thanks to all
On Tue, Nov 01, 2005 at 12:07:58PM +, Christian Costa wrote: Btw, when do you plan to finish and submit your patch that fixes the mouse cursor issue in Dungeon Keeper ? :-) Found the patch again. Now I just need to write a proper test case in the Wine framework and submit both to be sure Alexandre commits it this time :-) It should be done today I hope. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: KERNEL: force copying of DOS-style path into argv[0] of PE process (was: Re: Queries about some 'usability' points) - partially fixes #3542
On Mon, Oct 31, 2005 at 12:08:36PM -0500, Alex Villacís Lasso wrote: BTW, could you please post the mouse-cursor issue patch? I also have a Japanese RPG for which the mouse cursor gets stuck at the center of the window, and I think that problem and the one in DungeonKeeper might be one and the same. I will post it when I find the patch (must be somewhere on this hard drive but no idea where I put it :-) ) and merge it with the current CVS tree. Now if you game uses DInput (easy to see: just do a +dinput trace) I doubt that my patch would fix anything as it is another of the 'common' bugs linked to mouse warping. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: The Holy Grail - Wine 0.9 - thanks to all
On Sun, Oct 30, 2005 at 10:55:36AM +, Christian Costa wrote: IIRC, a patch fixing this problem was commited about 2 or 3 months ago. Yes but because this patch conflicted with your 'rename everything' patch, AJ did merge it himself ... and forgot a part of the patch (the one about light creation). It was in my plans to resubmit the parts which were left off during the merge but it seems that you beat me to it :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: The Holy Grail - Wine 0.9 - thanks to all
On Sun, Oct 30, 2005 at 12:46:13PM +, Christian Costa wrote: I've just taken a look at it again and it seems the patch only fixed the D3D7 API. Do not check the commit mail, but the patch itself: http://www.winehq.org/hypermail/wine-patches/2005/06/0103.html And you will see that the real patch fixes this issue. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Anarchy Online, Specular Lighting, Pixel Shaders....
There didn't appear to be any existing entries in the bug database for AO, so I added this info there. I'll re-test as I see patches coming into CVS. As this and Oliver's code do not share (yet) the same codebase, no need to re-test each time Oliver sends a patch :-) Better for example retest when Christian has his 'max lights' patch merged in as it was written originally for AO. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: KERNEL: force copying of DOS-style path into argv[0] of PE process (was: Re: Queries about some 'usability' points) - partially fixes #3542
I think the conclusion last time we looked at this was that this is actually a characteristic of Explorer, not Windows, and so it's really caused by the fact that most Wine users run the apps from the command line not via the shortcuts. If you run Dungeon Keeper in the wrong way from the command line in Windows it'll crash too IIRC. Yes this is what I wanted to test as I brought my Windows laptop home: i.e. start the application from the Explorer, from a shortcut, from a DOS windows, from a a get in all cases what 'argv[0]' is and the current work dir. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: D3D7 - WineD3D, 2nd attempt
On Sun, Oct 30, 2005 at 02:15:56PM +0100, Stefan Dösinger wrote: However, I'd suggest a software implementation for DX7 as a fallback for cards which don't have shaders and cards which don't have the necessary extensions. Well, if you go this way, that means writing an almost complete (except for texturing) OpenGL implementation of the geometry pipeline. This is why I did it (for the only application actually using it) via the current 'hack'. After, one can always imaging lifting code from Mesa or TinyGL to do that, but I would really investigate if the current hack is not enough for all games out there. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: KERNEL: force copying of DOS-style path into argv[0] of PE process (was: Re: Queries about some 'usability' points) - partially fixes #3542
On Mon, Oct 31, 2005 at 07:18:24PM +0100, Molle Bestefich wrote: Uhm. Explain to me how the above ratifies _not_ converting the Unix-style path to a Windows-style path before handing it to the app? We ARE trying to emulate Windows, are we not? There is a difference between converting an Unix-style path to a Windows-style patch and converting between an Unix-style relative path to a fully-qualified Windows path. Basically, the question here is whether argv[0] contains always a full-qualified path or can it contain a relative path. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: The Holy Grail - Wine 0.9 - thanks to all
Well, no. Antoine's patch fixed only the d3d7 light APIs. Old light APIs (light object + CreateLight method of direct3d object) were wrong. Ah must have been drunk when I got the CreateLight but report in the channel and compared Antoine's patch to my tree :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: The Holy Grail - Wine 0.9 - thanks to all
The only other issue is upon exiting the game I get an 'error writing to address' that pops up in a separate window and I have to kill X and then log back in to get the proper resolution back. No need to kill X to get back your resolution, just use 'xrandr' to set it back to what you want. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: The Holy Grail - Wine 0.9 - thanks to all
However, as far as I'm concerned neither of those are major issues, just the kind of stuff that makes the difference between decent and great support for an application. Could you raise a bug on bugzilla attaching a +ddraw trace so that I can take a look at it when I find the time ? I tried to d/l the BZ2 demo but no site seems to host it anymore so I will be restricted to look at traces to find out what goes wrong :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Queries about some 'usability' points
On Thu, Oct 27, 2005 at 04:17:17PM -0500, Alex Villacís Lasso wrote: The page says that you have a patch that fixes something. Is that the issue about the executable path name, or the one about the game refusing to go past the splash screen, or the one about the mouse cursor? It's only fixing the mouse cursor issue. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: wine overstepping the mark?
If I wanted moron-user-friendly I would still be running M$ not Linux. Ah then we could petition AJ to remove the configure script and go back to Makefile templates that you modify to be aligned with your configuration :-) And frankly, if you want to control exactly what the installer does, just do not type 'make install' and copy the files over yourself. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Queries about some 'usability' points
Hi all, There are just two (unrelated) points that I would like to discuss: = the possibility to add a 'wine' launcher. Basically what happens is that some (maybe only one :-) ) application takes as an assumption that it is started via 'double clicking' on the .EXE file or via the installed link. From what I know, both these actions will start the game from its .EXE directory and with the full qualified path as the exe name. So the application crashes if you start it with 'wine foo.exe', you need to type 'wine D:\\Foo\\foo.exe' to get it running. One could then imagine having either 'wine' be a launcher that qualifies the name, changes to the good directory and just start the 'real' wine or do the reverse: publicize to new users that they should use 'winelaunch' to start applications and keep 'wine' how it is now. = in the current Wine tree, if Wine crashes, some persistant X settings are changed (for example desktop resolution for people using XRandR)... And as most people do not know the 'xrandr' command line tool, they tend to kill X to restore their resolution (which tends to annoy them :-) ). In the same vein, I would like to disable mouse acceleration when DInput mode is entered but actually fear to do so for the above-mentionned reasons (I fear gettint these kind of lines in the IRC channels: 'Wine is crap, when it exits, I need to restart X to get my mouse acceleration back'). Well, there is 'xset' but most 'normal' users have no idea that it even exists... For that one, the most robust way would be at the X level (basically having 'connection-linked' configurations - i.e. the settings has changed up until the point in time that the client quits) but if we do not want to change X, the most robust way would be to do it at the wineserver level (I often get Wine crashing, it's more rare to get the server to crash). Of course, injecting X code in the server is maybe not to AJ's liking :-) So the other solution would be to be able to hook somehow some 'clean-up' functions from DLLs to the Wine process that could be called when Wine exits (whether normally or when crashing). Of course, people 'kill-9'ing their Wine would get nothing but I do not think it's really a problem. Lionel (in rant mode :-) ) -- Lionel Ulmer - http://www.bbrox.org/
Re: Queries about some 'usability' points
Could you please indicate which application has this behavior? Can you provide a download URL? All info here: http://bugs.winehq.org/show_bug.cgi?id=3542 Lionel (will answer to your other points after some more tests in Windows :-) ) -- Lionel Ulmer - http://www.bbrox.org/
Re: Wine regression testing: PIT_
On Wed, Oct 26, 2005 at 10:04:46AM +, Molle Bestefich wrote: I want to find which patch ruins an application. The application, according to one note, worked in 2003. I decide to try and see how it really runs with the 2003 version of Wine mentioned in the note. The question now is: why was this application not tested more often to get the exact date of regression ? Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: DirectDrawEnumerateExW calls DirectDrawEnumerateExA
On Wed, Oct 26, 2005 at 10:03:36PM +0300, Saulius Krasuckas wrote: As this struct keeps base information about a driver and it uses char strings, I guess %Subject% cross call should be marked invalid in the wiki. Right? Well, we could move the DDraw code to Unicode and do the opposite (have the A function call the W one). But as the only strings we report to the application are in English anyway and are not planned to be localized anytime soon, it's a bit overkill to do this work for no gain at all. If one day someone wants to have the DirectX driver name reported in Chinese, let him to the work of unicodification of DDraw :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: preload libGL
On Sat, Oct 22, 2005 at 11:33:45PM +0200, Tomas Carnecky wrote: those people don't need to know what opengl is.. the distribution packager needs to make wine depend on opengl.. and they didn't.. so it was their fault.. Yes, but tell that to the users who complain to us 'Wine is broken, it does not work on my box, it's crap'. Wine is already somewhat hard to package, so why should we make the life of packagers harder ? And frankly, I find it nice to only have the libraries that really need it (opengl and wined3d in the current tree) hard-link to OpenGL. That means that people can ship a 'work anywhere' Wine without even having to check the GL dependency (as Wine will handle it gracefully for them): if GL is installed, Wine supports it, if not, Wine will work except for OpenGL32.DLL and D3D8/9.DLL (which is to be expected). I don't see why you (eg. wine developers) should need to fix something (it's not really a fix, just a workaround) that is caused by someone else (eg. the distribution packagers). See before. It's Wine's image that is hurt by this, not the packagers. like with other packages that require some strange libraries, why can't opengl be a 'hard' dependency for wine? I would reverse the question: why should it be when only 2 DLLs over the 200 Wine provides needs it ? Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: preload libGL
Do you need it to fix the mouse pointer lagging problem with fglrx? This patch might be what you need. It works for me with Half-Life and Jedi Academy. I kinda see how this could help, but it would need to be better understood first before being applied (it would need, of course, to not link directly to GL and use function pointers :-) ). Heck, it should make performance almost worse as we add a round-trip to the X server to do this and need to flush the GL rendering pipeline at each buffer swap instead of continuing sending commands to display the new frame while the swap occurs... Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: preload libGL
On Sat, Oct 22, 2005 at 08:39:28PM +0200, Tomas Carnecky wrote: I don't really see any dfference between dlopen(libGL) at run-time and linking x11drv with libGL at compile-time.. Well, suppose you want to do a 'full-blown' Wine distribution. You would then link to libGL at compile time. And then suppose someone uses your package on a machine without GL installed = the guy will not be able to do anything as he won't be able to load the graphics driver (this case actually happened some time back). This is why we try to have less and less 'hard' dependencies in the Wine code and more and more 'soft' ones (which means that you can build Wine on a machine with all dependecies met while having this package still work on a much less feature-full box). Of course, in cases where the dependency is really mandatory (like the GL dependency in the OpenGL32.DLL) we do the hard linking :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: preload libGL
On Sat, Oct 22, 2005 at 11:06:14PM +0200, Tomas Carnecky wrote: I personally would vore for the first option, make opengl a wine requirement, we'll soon have opengl integrated into the xserver (Xgl etc.) so sooner or later everyone will need to have an opengl implementation installed. Well, trust me on that one, but some times ago, Wine did link directly to OpenGL. But seeing the number of broken packages (i.e. did not advertise the GL dependency) and the time spent on bug reports / support requests, it was decided to move to a run-time link scheme. And I think there are more people without GL installed (and without even a clue to what GL is) than one wanting to play pre-link tricks to override GL. opengl should be installed per default on all desktop boxes (at least through mesa in pure-GPL duistributions that don't want to have any proprietary binaries).. Maybe when it will be really mandatory we can switch back to 'hard' linking. But for now, I think GL is not yet pre-installed on all distributions and we will still have to wait a while to get to the Xgl and all other eye-candy infested stuff they are writing :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: bug 2398: OpenGL, child windows, and wine
Yeah, this is for a customer of ours who has the OpenGL in child windows problem. The easiest way around this was to get them to modify their code to draw onto dibsections and blit to the window. Then all we needed to do was to implement the OpenGL on dibsection bit. Ah I understand now. Do you know when the 'in DIB section' patch will be sent to wine-patches (maybe after the 0.9 freeze) ? I think once this is in, I will try (for fun) to see if I can get a hacked version of wgl.c together which uses DIB for the 'in window' rendering part. It would only handle 'back buffer' rendering (i.e. the DIB flushing would be done on the swap buffer call) but it could be a temporary solution waiting for a real OpenGL guru (i.e. not me) to fix using funky extensions :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: bug 2398: OpenGL, child windows, and wine
Huw has done some work on this using pbuffers but I'm not sure how far he's got. I thought it was GLXPixmaps seeing the patch he submitted to wine-cvs :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: bug 2398: OpenGL, child windows, and wine
Which patch is that? I couldn't find it... * dlls/x11drv/bitmap.c, dlls/x11drv/init.c, dlls/x11drv/opengl.c, dlls/x11drv/x11drv.h: Huw Davies [EMAIL PROTECTED] Add an x11drv escape that returns a glx drawable. At the time the patch was submitted I was (and I am still :-) ) intrigued about the use case for this patch. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: bug 2398: OpenGL, child windows, and wine
On Tue, Oct 18, 2005 at 12:08:04AM -0700, Dan Kegel wrote: I'm tempted to say skip the workaround, at least for the first pass, and just implement the real fix using the opengl extension. As Sippel said, people who use apps like Lightwave (and maybe Quake3 Radiant :-) tend to have the latest 3d hardware and drivers anyway. I would tend to do the reverse. First code what works on all cards / drivers (that would be pbuffers which are pretty much supported on all cards that I know of) and then only code the 'fast path' if any. What do other people think? Has anybody started looking at fixing this yet? I am aware of the issue since WineConf 2004 but never had the time / motivation / knowledge to fix it. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: D3D7 - WineD3D, 2nd attempt
On Sat, Oct 15, 2005 at 04:58:00PM +0200, Stefan Dösinger wrote: Hello, Just one question about thread safety: The openGL crash I am struggling with seems related to threading: A, you fell again in the (in)famous multi-threaded D3D applications :-) Alas, for now, this is an unsolved issue for which no clear plan is put in place. So I guess it would be best to choose another game to do your DDraw = WineD3D port as neither DDraw not WineD3D support (yet) these kind of applications. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: D3D7 - WineD3D, 2nd attempt
On Sat, Oct 15, 2005 at 08:25:18PM +0200, Stefan Dösinger wrote: I'll try my wined3d glXMakeCurrent hack on old ddraw, just out of curiosity. I checked your code you sent in the other part of the thread and it seems strange... According to the man page: BadAccess is generated if ctx was current to another thread at the time glXMakeCurrent was called. So if you are in thread B and thread A has the control of your context, doing a 'glXMakeCurrent' on the shared context should fail as the context is currently active in thread A. To have this method work properly, one would have to somehow make 'glXMakeCurrent(NULL)' run in the context of thread A before doing what you did. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: D3D7 - WineD3D, 2nd attempt
On Sat, Oct 15, 2005 at 07:30:34PM +0100, Oliver Stieber wrote: Add the OpenGL context to the device structure. Make a per-device critical section. Whenever a call is made enter the critical section Then check that the current active context is the same as the context on the device. If not then make the device context active. How did you plan to solve the 'one needs to release a context before it is free to be used in another thread' problem ? The only 'easy' way out I can see would be to always release the context at the end of each processing so that any subsequent thread could, if needed, get the context. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: D3D7 - WineD3D, 2nd attempt
On Sat, Oct 15, 2005 at 08:13:24PM +0100, Oliver Stieber wrote: We could do that, or we could signal the other thread an tell it to release the context which should cut down on the context switching, I'm not sure how easy that would be to setup (it doesn't seem possible using even objects because the thread has to be waiting) Well, the 'signal' option is (AFAIK) what Transgaming does in Cedega to fix the issue. Another option would be to create a new context that shares resources with the other contexts and copy over the state from the old context to the new one. And this is what I planned to implement when the I have the motivation and the time (discussed about it on IRC with a guy some time ago trying to find the best way to do that). I may try it one of these days for some specific cases (like for Dungeon Siege) and if it works, generalize to all cases. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: D3D7 - WineD3D, 2nd attempt
On Sat, Oct 15, 2005 at 08:59:55PM +0200, Stefan Dösinger wrote: Another update before sending: I've used my glXMakeCurrent hack with old ddraw, and guess what: Empire Earth brings the main menu up successfully[1]. It's slow as hell(yes, 2D DIB with those horrible ATI drivers), and it has some little drawing problems. It crashes in msacm when trying to start a game. Well, seems that your GL drivers do not do all the checks the specification requires them to do... Lucky for you :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: D3D7 - WineD3D, 2nd attempt
How about creating a new thread to to all rendering, and make the calls call this thread and block until the function's finished? Is this possible? Yeah, this was another option we discussed (the 'marshalling' option as we called it :-) ). Was deemed too slow as it would reduce performance of games using a single-threaded rendering system (the vast majority of games). The problem with that is either you know beforehand that it will be multi-threaded or it's too late (as once you detect it, you cannot go back as your context is already taken by the other thread). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: D3D7 - WineD3D, 2nd attempt
On Sat, Oct 15, 2005 at 08:44:05PM +0100, Oliver Stieber wrote: It may be easier to do in DirectX 7 because of the way it manages states. Well, I wanted first to handle 'special cases' like applications using the second thread just to do lock / unlock on the buffer or loading textures (which is a good part of the cases). For those, no need to handle states as they are not needed anyway. Applications that are really doing multithreaded 3D rendering are quite rare (and the only case I know is just starting with one thread and then moving to another while not using the previous one again). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Reality check
On Fri, Oct 14, 2005 at 09:50:48AM -0700, Hiji wrote: However, there is a more fundamental problem here. I don't see bugs in a black vs. white type of view; in fact, I can classify bugs in two ways: 1) A bug is something that has always been broken 2) A bug is something that is broken, but it once worked This is still too 'white and black'. What about a patch that fixes 1) and in the process introduces 2) (case in point the WM rewrite and windowed GL applications) ? Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: D3D7 - WineD3D, 2nd attempt
On Fri, Oct 14, 2005 at 04:52:37PM +0100, Christian Costa wrote: Since vertex buffer support is a hack, I think you can use standard wined3d drawing primitives for the moment. Well, vertex buffer support is only a hack in the case of 'pre-transformed' buffers (i.e. if the application transforms the buffer without rendering it and later on renders the transformed buffers). The only application I know of which uses this feature is MI4 (EMI). A part from that, where is the hack located :-) ? Lionel PS: in theory, vertex buffers should be stored 'on card' using OpenGL extensions (for which I forgot the names) -- Lionel Ulmer - http://www.bbrox.org/
Re: D3D7 - WineD3D, 2nd attempt
On Thu, Oct 13, 2005 at 07:31:09PM +0200, Stefan Dösinger wrote: I always thought this patch was commited to CVS. Must have been mistaken. Well, will see if doing a patch like that could help in the DirectX code waiting for merging the DDraw and WineD3D code. No idea if any application would actually be really accelerated though. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: D3D7 - WineD3D, 2nd attempt
On Wed, Oct 12, 2005 at 02:23:09PM +0100, Oliver Stieber wrote: Some of the code currently falls back to the desktop windows, and it looks like the X root windows is the desktop window when wine isn't running in desktop mode. We should only be using the desktop window if that's what Windows does, otherwise it could cause problems with other areas of code that are expecting the desktop window to behave like the same as it does on Windows. From what I know, it does. Case in point is QuickTime which (AFAICR) locks / unlocks a 'NULL' window which in Wine does a lot of ugly stuff. Will need to check this though. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: D3D7 - WineD3D, 2nd attempt
On Tue, Oct 11, 2005 at 10:24:58PM +0200, Stefan Dösinger wrote: WineD3D can't create a device without a Window. For DirectDraw and D3D7 running without a Window is valid, at least to a certain extent. The D3D light test does so, and some games use this for some purposes. So I need to do something for the case HWND == 0 or the d3d surface is not a primary surface. Why not use the 'desktop' window to do it ? No idea what window will be used to display when not in Desktop mode (maybe the X root window ?). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: D3D7 - WineD3D, 2nd attempt
On Mon, Oct 10, 2005 at 12:17:47AM +0200, Stefan Dösinger wrote: * WineD3D Surfaces can be attached to DDraw Surfaces, and they receive the properties of their parents, including the memory reserved for the surface How do you handle the 'special' case Blits (between surface and texture, between surfaces, ...) ? The whole thing is far from beeing useable, if anyone is interested in the code, I can send it, but be warned, it's quite a mess at the moment. My plan is to get some games running, and then I'll send small and clean patches for CVS commit and upload a big patch somewhere for prior testing. Well, for one, I would like to see first the big patch (or at least enough code to be able to see where this is going) before you start sending small self-contained patch to be able to have a big picture of where we are going and if it will work at the end (with all special cases a 2D / 3D mix entails). Anyway, keep up the work :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: [ddraw] Fix bug 3487 take 2
On Mon, Oct 10, 2005 at 01:43:04AM +0200, Peter Berg Larsen wrote:
Could you try it and tell if it fixes the problem ?
It, the patch on the bug page, does (e.i. without the locking). Could I
suggest a comment in the code.
Well, you can suggest a comment or even send a patch adding comments if you
wish :-)
And as my patch is in CVS now, you can even do a regression test with the
'full blown' patch.
Nor did I say that; just that it had nothing to with bug 3487 as the
subject said it had.
Yeah, got confused too (it really took me a while to understand that we went
out of the Lock function before crashing).
Now back to your patch. The code looks like this:
/* __tosize can be set too large by some programs */
#define DD_STRUCT_COPY_BYSIZE(to,from)
do {
DWORD __tosize = (to)-dwSize;
DWORD __fromsize = (from)-dwSize;
if ((to) == (from))
break;
if (__tosize sizeof(*(to)))
ERR(To struct's size too large);
if (__fromsize sizeof(*(from)))
ERR(From struct's size too large);
if (__fromsize __tosize)
ERR(Copying too large struct);
memcpy(to,from,__fromsize);
memset(to+__fromsize,0,sizeof(*(to))-__fromsize);
(to)-dwSize = __tosize;/*restore size*/
} while (0)
I would first merge both our patches replacing the following lines with an
'assert(to != from)':
if ((to) == (from))
break;
This macro is only used to copy application data to Wine data or the
reverse. So if both pointers are the same, it is a Wine bug as we should
NEVER send any pointer to our private data to the application (they are not
const pointers = the application can modify them = all hell break loose).
After you also give a lot of warnings but you do not do as the previous
macro. Ie if 'fromsize' is bigger than 'tosize', you just print an error,
you do not 'correct' the size which would lead to a memory overflow.
Finally, 'to+__fromsize' is wrong, it should be '((char *) to)+__fromsize'
and why use 'sizeof(*(to))' as the basis for the 'memset' size and not
'tosize' ?
Lionel
--
Lionel Ulmer - http://www.bbrox.org/
Re: [ddraw] Fix bug 3487 take 2
On Mon, Oct 10, 2005 at 10:18:21PM +0200, Peter Berg Larsen wrote:
I would first merge both our patches replacing the following lines with an
'assert(to != from)':
if ((to) == (from))
break;
I think thats execellent idea; I hadnt though of asserts, did not new
wine used them..
Well, as Alexandre committed my 'assert' patch, it's already in the code and
there is just a merge to be done :-)
As for asserts, they work because Wine catches the 'assert' signal and
transforms it into a Win32 exception thus starting the Wine debugger.
I still havent got the grasp of what dwSize is for if it does not reflect
the size allocated?, nor the size of the struct current in the mem.
An example of the usage of the 'dwSize' parameter:
static HRESULT WINAPI
IDirectDrawSurface3Impl_Lock(LPDIRECTDRAWSURFACE3 This, LPRECT pRect,
LPDDSURFACEDESC pDDSD, DWORD dwFlags, HANDLE h)
{
return IDirectDrawSurface7_Lock(CONVERT(This), pRect,
(LPDDSURFACEDESC2)pDDSD, dwFlags, h);
}
As the DDSURFACEDESC2 structure starts exactly like the DDSURFACEDESC2 one,
the hack here is to use 'dwSize' to magically cast one structure to the
other to be able to share code.
This is what MS had in mind when they introduced this field: have
'extendable' structure wheer each new revisions only added fields = they
can all be filled by one common function, using the 'dwSize' field to
disctriminate between versions.
Note that next time I bring my Win32 laptop home, I will try to do some
tests in real Windows to see how Windows fills the given structure pointer.
Lionel
--
Lionel Ulmer - http://www.bbrox.org/
Re: [WINECFG] Remember disabled Desktop settings
On Sun, Oct 09, 2005 at 03:02:30PM +0100, Richard Cohen wrote: It annoys me as well. Instead of creating another key, why not set the Desktop key to #800x600. We will need to fix x11drv_main, of course... Ah yes, another possibility to fix this problem :-) Will wait for more comments to see the path we go into. I kinda like the 'full blown' winecfg keys to do other stuff like that (like remembering the last panel the user was on when leaving winecfg or other 'stateful' stuff we could do if we had this registry 'key'). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: [ddraw] Fix bug 3487 take 2
So here is better patch that does not open 2070 again. Changelog: Bug in copying structs if to == from as to was memset first. Well, while your patch was lying in the moderation queue, I sent what I feel is a better solution to this problem (which fixes also a severe reference counting issue). Could you try it and tell if it fixes the problem ? Lionel PS: and Raphael's patch while not fixing your bug is not technically wrong as Windows checks for the surface description pointer being non-NULL :-) -- Lionel Ulmer - http://www.bbrox.org/
Re: DirectDraw driver question
On Wed, Oct 05, 2005 at 12:24:46AM +0200, Stefan Dösinger wrote: Wine has 2 DDraw drivers: An accellerated HAL driver and a software-based user driver. I've noticed that the HAL driver uses many basic functionality from the user + gdi driver, and that the hal driver is the prefered one. But is there any situation where the user driver is used directly? From what I know, both are almost exactly the same code-wise. The only difference being that the HAL one could support DGA / DGA2 whereas the User one not. After, I think that this is here to be compatible with Windows that always exports these two 'basic' drivers whatever your installation (would have to check this point on my Windows laptop though). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Stop-ship 0.9 problem
On Sat, Oct 01, 2005 at 10:42:34PM -0600, Vitaliy Margolen wrote: Bottom line we have to fix. Users started to complain immediately after 20050930 was out. Even if it's not 100% correct we still cant cripple the Wine with such an ugly fonts. The only problem I see is with people having a self-compiled FreeType library with hinting enabled. Why cripple their configuration too by default ? Is there no way to detect at compile / run-time what kind of FreeType library we link with ? Or, at the very least, let this be configurable in winecfg (or in the registry) as it does not seem to be the case with Mike's patch. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Auto-register d3drm too?
On Mon, Sep 26, 2005 at 12:48:04AM +0200, Francois Gouget wrote:
d3drm.dll has exactly the same issue as d3dxof.dll. It depends on the
CLSID\{4516EC41-8F20-11D0-9B6D-C0781BC3} registry key but it is
unclear how this key is supposed to be created.
It seems to be the same issue that we have with the DDplay service providers
whose keys are not registered by any DLL (I put them in wine.inf).
Alexandre proposed in those days the creation of a 'directx.inf' which would
regroup all keys created by a standard DirectX installation.
Lionel
--
Lionel Ulmer - http://www.bbrox.org/
Re: DDraw: Better flag handling in SetCooperativeLevel
On Thu, Sep 08, 2005 at 12:03:52PM +0200, Stefan Dösinger wrote: Changelog: *Add handling for DDSCL_SETFOCUSWINDOW in SetCooperativeLevel *Print a fixme for DDSCL_CREATEDEVICEWINDOW and DDSCL_SETDEVICEWINDOW. Alexandre, any reason why this patch (plus the other about the reference counting) were not applied ? If you were waiting for some DDraw 'guru' to give his blessing, they both look OK to me :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: listview: infoPtr might be invalid after WM_NOTIFY
On Tue, Sep 20, 2005 at 11:32:38PM -0400, Dimi Paun wrote: This is true only if we rely on the access violation exception (which is a possibility, I admit). But the test patch that I sent checked the hwnd after each notify message with IsWindow(), and if invalid it was throwing a custom exception. OK, so next time I will read the patch before saying stupid things :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: WooHoo get a load of this :-)
On Wed, Sep 21, 2005 at 10:54:28PM +0300, Shachar Shemesh wrote: As a side track, Win4Lin contacted me a while back, and wanted Lingnu to represent them in Israel. I sent back a few technical questions, and NEVER HEARD FROM THEM AGAIN! Does the company still exist? Last I know they still exist and plan to sell a packaged version of QEMU as their Windows emulator. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Documentation volunteer(s) needed
On Tue, Sep 20, 2005 at 10:56:41PM +0200, Stefan Dösinger wrote: That's exactly the problem I have! I expect it to occur too when Empire Earth finally runs. Can you send me your hack? I'd like to try it with D3D7. If the game is well behaved, this optimisation should already be present in the D3D7 code (i.e. if the surface is locked 'write only', do not bother to read the buffer from the card). Alas most games are not well behaved and always lock in R/W mode :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: listview: infoPtr might be invalid after WM_NOTIFY
On Tue, Sep 20, 2005 at 11:51:00AM -0400, Dimi Paun wrote: I personally think an exception-based solution would be better. This is what exceptions where invented. (...) Correct me if I am wrong (I know absolutely nothing about how the listview code works) but a flaw of the 'exception based' solution would be if the application allocated memory that would re-use the just freed memory pointed by 'infoPtr'. This would mean that no exception would be triggered while the code would still be wrong as it would write / read something that is clearly not what it expects. Now one could say that knowing the heap allocation algorithms this case should never happen, but well, better safe than sorry. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Empire Earth continued
*Windows increases the refcount of the DirectDraw7 object by 1 when a surface is created. When the surface is released, the refcount of the DirectDraw7 object is decreased, obviously. Wine doesn't do so(yet), and to my current knowledge, this is what makes Empire Earth crash. Yeah, this is what I suspected: that Wine had some reference counting differences with Windows that provoked this error. Best would be to write a 'DDraw' test (integrated in the test suite) to be able to check reference counting in some 'standard' cases (surface creation, D3D object creation, ...). I am looking for a good place to place the AddRef and Release calls to solve the first issue, and I'll send a patch as soon as I have one. Well, as we call a DDraw 'method' to create the surface, you should add the AddRef call there. For the release, it should be in the 'final_release' call for the surface (AFAIK, each surface already stores a pointer to its parent DDraw object). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Empire Earth continued
On Thu, Sep 08, 2005 at 10:37:56PM +0200, Stefan Dösinger wrote: I think you're right. After Releasing the DDraw object two times, as EE does, it's far from beeing freed: It has a refcount of 8!! In particular, creating the surface and performing QueryInterface on it increase the refcount by 1, creating a D3D device increases the refcount by 7. What you could test is artifically increase the refcount of 'normal' surfaces and check if these are deleted or not. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Empire Earth continued
Wine releases the surface in 5), Windows doesn't. It appears to me, that Windows doesn't release Surfaces which have a D3D object attached when the DDraw instance they belong to is freed. Yeah, I suspected that the problem was in the 'force destroy' code. Could you change your test script to get the reference count of the 'complex' object before release of the DDraw object and after ? Could you do the same for the 'normal' objects (mostly before as after it will crash :-) ) ? After that, it's always a bit tricky to test stuff like this as non-crashing is not a definite proof that the object was not actually destroyed... Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Empire Earth continued
On Thu, Sep 08, 2005 at 09:20:39PM +0200, Stefan Dösinger wrote: Do you mean on Windows or on Wine? How can I get these members from an external application? I thought that apps can't look inside a COM object, as the structures used by the libs and the structures exported to the app are different. Well, just do an 'AddRef' which returns the (now incremented) reference count and then a Release. If you print the returned value minus one, you will get the current reference count at the moment of the call. Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Suggestions for improvement of the emulator
On Tue, Sep 06, 2005 at 09:26:44AM +1000, Troy Rollo wrote: To scale better you would need to divide the project into different areas of responsibility and have multiple committers. Well, one can say that this model already exists implicitely as most patches to 'non-core' DLLs (DirectX in my case) are applied without much problem by Alexandre (as long as no other DirectX 'core' hackers do not complain when the patch is sent to wine-patches). Now one could say that it would be better to have direct commit access for one guy, but well, it never really hurt anyone (and frankly, I prefer to have the Alexandre quality control as it oftens helps us finding bugs or better solutions if not the basic stuff to force people to send 'small' patches :-) ). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: Crash on glBegin() (Was: Help with debugging needed)
As far as I can tell from a quick look, no. All ddraw calls are done from the same thread, there are only a few imm32 calls from another thread. OK, a shame :-) I have noticed that it creates multiple DirectDraw and Direct3D devices, some of them are freed, re-created and freed again. At the time of the crash due to reference counting, there are at least 2 DirectDraw and 2 Direct3D objects. Is this going to work? Well, there should be no issue with that except if there is some issue in the GL drivers about an application having multiple contexts created at the same time? Do you still want to see a +ddraw,+tid trace? I can upload one to my homepage. Well, if it's not multithreaded in DDraw, no need. I still have to look at your other trace with the refcounting issue to try to see where the problem lies. Lionel -- Lionel Ulmer - http://www.bbrox.org/
