December 2009 - Wine-Devel - list.winehq.org

Re: [PATCH 1/2] msvcrt: Add test to check if signal(SIGBREAK, ...) works (todo_wine).

by Peter Rosin

Den 2009-12-02 16:35 skrev Charles Davis: > You don't get added to AUTHORS until you've hacked on Wine enough. I > learned that the hard way when I tried to put my name at the top of an > already-existing file. I did a - eeerh couple of (sorry for the noise) - resend w/o touching AUTHORS. I don't really see the point of letting someone else update AUTHORS for me though, but now Alexandre can pick whichever version he likes best... Cheers, Peter -- They are in the crowd with the answer before the question. > Why do you dislike Jeopardy?

Dec. 3, 2009

Re: [PATCH] kernel32: Respect the LANG environment variable on Mac OS.

by Gert van den Berg

On Wed, Dec 2, 2009 at 22:52, Ken Thomases <ken(a)codeweavers.com> wrote: > On Dec 2, 2009, at 1:22 PM, Gert van den Berg wrote: >> As far as I can figure out, no LC_* variable, except LC_ALL specific >> the actual locale? They only determine individual settings, which >> overwrites the default for the locale, as set by LANG? (Not sure if it >> effectively means set everything to LANG's locale, overwrite >> individual settings from LC_* if they are defined) > > I'm not sure what you mean here. Are you referring to the general Unix > meaning of these variables or Wine's use of them? General *nix meaning. What I meant is that LC_* (not LC_ALL) don't have a setting that says "the locale is say en_ZA" it only has we have number (LC_NUMERIC) from en_ZA, times (LC_TIME) from en_UK, sort things (LC_COLLATE) according to en_AU, determine whether something is a letter / number and how to change their case (LC_CTYPE) according to UTF-8, ect. LANG is only setting that really maps to Wine / Windows' sCountry and Locale settings. (if all LC_* variables are set, LANG only determine things not in any of the LC_* variables) LC_* does not have anything to determine the actual UI language either. What I meant above, is that you should be able to get the equivalent effect (to the POSIX default) by setting everything to LANG's setting and then changing them from the LC_* variables. E.g. if LANG is fr_FR (not sure if that is an actual name) and LC_TIME is en_US, set environment up for French, change settings affected by LC_TIME to US English. Setting LANG to French and all individual settings to en_US, shoulld reslut in a system where the country is France, Locale code is 0x040c, UI is French, but date / time / number / currency settings, etc. is that of en_US. Considering how OS X seem to set variables, that might work as well... My interpretation of your proposed logic for OS X: Set up everything to OS X setting, overwrite everything if LANG is set, overwrite further settings from LC_*, overwrite everything from LC_ALL if that is set. (the slow unoptimized way that might result in some settings being overwritten 4 times before settling on a value...) Resulting order: LC_ALL LC_* LANG OS X settings. > As near as I can tell, Wine only probes the locale information by invoking > setlocale(<category>, NULL). It doesn't directly examine the environment > variables. Furthermore, it only queries using the individual categories, > not LC_ALL. It uses setlocale(LC_ALL, "") once to tell the C library to > initialize itself from the environment. > > So, I'm not sure how setting all of the LC_* variables to a given value can > be different from setting LC_ALL to that value. > Interpreting it as above, settings LC_ALL is equivalent to setting all LC_ variables and setting LANG to LC_ALL's value. >>> If one of the LC_* variables are set, that expresses user intent (because >>> those variables are not set by Terminal.app automatically). Also, it is >>> useful to allow the user to override the System Preferences on a >>> category-by-category basis. >> >> Mine gets set to C / UTF-8(for LC_CTYPE) of some reason... > > Maybe Terminal.app is setting LC_CTYPE when it can't set LANG. Check what's > actually set in your environment: > > env | egrep "^(LANG|LC_)" Sorry, only LC_CTYPE is actually set, to UTF-8. (form the locale command's output one would think that it does the same, which it obviously doesn't) Looking at the current values, your order for OS X makes sense. If the actual effect is similar to the result of the overwriting above, you can overwrite settings as in *nix, but OS X's ones are used by default. (Not sure what it will do if OS X actually knows your locale?) Gert

Dec. 3, 2009

Re: Slackware packager?

by Jesse Allen

On Tue, Dec 1, 2009 at 11:54 AM, Jeremy White <jwhite(a)codeweavers.com> wrote: > So Adam Schreiber reports that he's no longer > doing the Slackware packages. > > Is there an active Packager currently? If so, can > you submit a patch to remove Adam's name and insert yours? > > If not, I guess I'll submit a patch to remove that column > for Slackware... > > Cheers, > > Jeremy > > > There are current options in the slackware community to obtain a precompiled package or build wine: http://connie.slackware.com/~alien/slackbuilds/wine/ (by Eric Hameleers) http://slackbuilds.org/repository/13.0/system/wine/ Thanks, Jesse

Dec. 3, 2009

Re: RFC: dsound: Add support for enumerating capture devices through openal, try 4

by Ken Thomases

On Dec 2, 2009, at 12:11 PM, Maarten Lankhorst wrote: > This patch doesn't apply, just a rfc email to see if this approach > is correct :) > +static void *openal_handle = RTLD_DEFAULT; > +#ifdef SONAME_LIBOPENAL > + char error[128]; > + openal_handle = wine_dlopen(SONAME_LIBOPENAL, RTLD_NOW, error, > sizeof(error)); > + if (!openal_handle) > + ERR("Couldn't load " SONAME_LIBOPENAL ": %s\n", error); > +#endif > +#define LOAD_FUNCPTR(f) \ > + if((p##f = wine_dlsym(openal_handle, #f, NULL, 0)) == NULL) { \ > + ERR("Couldn't lookup %s in libopenal\n", #f); \ > + failed = 1; \ > + } > + > + LOAD_FUNCPTR(alcCreateContext); By defaulting to RTLD_DEFAULT on the Mac (where SONAME_LIBOPENAL won't be defined), is there any risk that wine_dlsym will find the symbols from Wine's openal32.dll.so rather than the linked OpenAL framework? If it does, is that a problem? I had proposed using RTLD_NEXT for the default to avoid that possibility, although it seems that RTLD_NEXT isn't universally available. We might use RTLD_NEXT if it's defined and RTLD_DEFAULT otherwise. -Ken

Dec. 3, 2009

Re: [4/6] WineD3D: Infrastructure to render swapchains to a FBO

by Stefan Dösinger

Am 02.12.2009 um 22:10 schrieb Henri Verbeet: >> switch(wined3d_settings.offscreen_rendering_mode) { >> case ORM_FBO: >> + This->offscreenBuffer = GL_COLOR_ATTACHMENT0; > This change is probably correct, but note that if it matters you're > probably doing something wrong. It matters when reading back an offscreen render target if FBOs are enabled, but FBO_blit is not supported. The readback function calls glReadBuffer(device->offscreenBuffer) in this case, and is correct to do so because its needed with other ORM methods. Without this change copying the backbuffer from an FBO into a texture without FBO_blit support fails. >> +static inline void swapchain_blit(IWineD3DSwapChainImpl *This, struct wined3d_context *context) > We have a number of functions now that do something very similar to > what this function does. Perhaps it's time to spend some time on our > blitter in order to unify those? The part that's shared between those is the glBegin(); 4*texcoord, 4*vertex; glEnd() block, but I'm not convinced that putting this pretty simple piece of code into a shared function is worth the trouble. Most of the code in the blit functions is to find the proper coordinates for the specific problem. Of course BltOverride is a pretty bad mess, but for a different reason. I have tried to restructure it in the past but didn't find any nice solution so far. I don't think this would affect this patch in any way though.

Dec. 3, 2009

Re: [3/6] WineD3D: A function for checking if a surface is offscreen

by Stefan Dösinger

Am 02.12.2009 um 22:10 schrieb Henri Verbeet: > Btw, note that the surface being offscreen is the common case, and > onscreen surfaces are the exception. Maybe surface_is_onscreen() makes > more sense, but I'll leave that up to you. I think its better to keep offscreen rendering the special case since we also have render_upside_down as the special case.

Dec. 3, 2009

Re: [2/6] WineD3D: Add a function for initializing surface sysmem

by Stefan Dösinger

Am 02.12.2009 um 22:10 schrieb Henri Verbeet: > IWineD3DDeviceImpl_Reset() suffers from similar issues in general, so > maybe we just don't care, but if one of the updateSurfaceDesc() calls > fails you're left with inconsistent surface sizes. We don't care because by Microsoft's design Reset() leaves the device in a broken state if it fails, and all you can do with it is call Reset() again or destroy it. >> + This->Flags |= SFLAG_INSYSMEM; > Why is this in surface_init_sysmem(), instead of a ModifyLocation() > call after the call to surface_init_sysmem()? My sense is that surface_init_sysmem should set it since it allocates and writes to the system memory copy. Probably surface_init_sysmem should call ModifyLocation itself to remove the other location flags.

Dec. 2, 2009

Re: [4/6] WineD3D: Infrastructure to render swapchains to a FBO

by Henri Verbeet

2009/12/2 Stefan Dösinger <stefan(a)codeweavers.com>: > @@ -1082,6 +1082,7 @@ static HRESULT WINAPI IWineD3DDeviceImpl_CreateSwapChain(IWineD3DDevice *iface, > object->wineD3DDevice = This; > object->parent = parent; > object->ref = 1; > + object->render_to_fbo = FALSE; This is redundant, the field is already initialized to 0. > @@ -1880,6 +1881,9 @@ static HRESULT WINAPI IWineD3DDeviceImpl_Init3D(IWineD3DDevice *iface, > > switch(wined3d_settings.offscreen_rendering_mode) { > case ORM_FBO: > + This->offscreenBuffer = GL_COLOR_ATTACHMENT0; This change is probably correct, but note that if it matters you're probably doing something wrong. > @@ -959,22 +963,25 @@ static void read_from_framebuffer(IWineD3DSurfaceImpl *This, CONST RECT *rect, v ... > @@ -3102,7 +3109,7 @@ static inline void fb_copy_to_texture_direct(IWineD3DSurfaceImpl *This, IWineD3D ... > @@ -3241,12 +3248,12 @@ static inline void fb_copy_to_texture_hwstretch(IWineD3DSurfaceImpl *This, IWine Most of this should be part of patch 3. Note that since we have SFLAG_SWAPCHAIN we don't really need to pass the swapchain to surface_get_gl_buffer() anymore, we can just cast This->container directly to IWineD3DSwapChainImpl *. > +static inline void swapchain_blit(IWineD3DSwapChainImpl *This, struct wined3d_context *context) We have a number of functions now that do something very similar to what this function does. Perhaps it's time to spend some time on our blitter in order to unify those?

Dec. 2, 2009

Re: [3/6] WineD3D: A function for checking if a surface is offscreen

by Henri Verbeet

2009/12/2 Stefan Dösinger <stefan(a)codeweavers.com>: > @@ -5674,7 +5674,7 @@ static void color_fill_fbo(IWineD3DDevice *iface, IWineD3DSurface *surface, > IWineD3DSwapChain *swapchain; > > swapchain = get_swapchain(surface); > - if (swapchain) { > + if (!surface_is_offscreen(surface)) { That's ok, but the code that sets up the scissor rect further down also uses "swapchain" like this. Also, some of the changes to e.g. read_from_framebuffer() in patch 4 are really the same as what you're doing in this patch. Btw, note that the surface being offscreen is the common case, and onscreen surfaces are the exception. Maybe surface_is_onscreen() makes more sense, but I'll leave that up to you.

Dec. 2, 2009

Re: [2/6] WineD3D: Add a function for initializing surface sysmem

by Henri Verbeet

2009/12/2 Stefan Dösinger <stefan(a)codeweavers.com>: > - updateSurfaceDesc((IWineD3DSurfaceImpl *)swapchain->frontBuffer, pPresentationParameters); > + hr = updateSurfaceDesc((IWineD3DSurfaceImpl *)swapchain->frontBuffer, pPresentationParameters); > + if(FAILED(hr)) > + { > + IWineD3DSwapChain_Release((IWineD3DSwapChain *) swapchain); > + return hr; > + } > + > for(i = 0; i < swapchain->presentParms.BackBufferCount; i++) { > - updateSurfaceDesc((IWineD3DSurfaceImpl *)swapchain->backBuffer[i], pPresentationParameters); > + hr = updateSurfaceDesc((IWineD3DSurfaceImpl *)swapchain->backBuffer[i], pPresentationParameters); > + if(FAILED(hr)) > + { > + IWineD3DSwapChain_Release((IWineD3DSwapChain *) swapchain); > + return hr; > + } > } IWineD3DDeviceImpl_Reset() suffers from similar issues in general, so maybe we just don't care, but if one of the updateSurfaceDesc() calls fails you're left with inconsistent surface sizes. > + This->Flags |= SFLAG_INSYSMEM; Why is this in surface_init_sysmem(), instead of a ModifyLocation() call after the call to surface_init_sysmem()?

Dec. 2, 2009