March 2011 - Wine-devel - list.winehq.org

Xbox 360 controller compatibility
by Alesh Slovak 22 Mar '11

22 Mar '11

Hi, I apologize if this question has come up before, I could not find a search feature in the mailing list archives and google didn't give me much on the subject. I am interested in getting the Xbox 360 controller working in wine. Currently, I can use the controller, but it is recognized only as a generic controller. This is acceptable (although annoying) for games that allow me to freely configure the controller, but others seem to specifically look for an Xbox 360 controller, and when they can't find it, drop to keyboard controls. Firstly, I am not even sure this is something that should or can be handled in wine. Maybe this needs to be handled in the xpad kernel module, or maybe both. But my guess is that wine would need to detect an Xbox 360 controller and then explicitly present it as such to any games. I guess the first step would be to find out how exactly games detect the Xbox 360 controller under Windows and try to emulate that. Any other previous attempts that anyone knows of? I would appreciate it if anybody out there who has any knowledge in this area, can point me in the right direction. Thanks.

5 11

Re: mshtml: avoid shadowing a parameter (2/2)
by Jacek Caban 22 Mar '11

22 Mar '11

Hi Austin, On 3/9/11 10:07 AM, Austin English wrote: > diff --git a/dlls/mshtml/htmlwindow.c b/dlls/mshtml/htmlwindow.c > index d0d378f..9948a02 100644 > --- a/dlls/mshtml/htmlwindow.c > +++ b/dlls/mshtml/htmlwindow.c > @@ -2141,22 +2141,22 @@ static HRESULT HTMLWindow_invoke(DispatchEx *dispex, DISPID id, LCID lcid, WORD > > switch(prop->type) { > case GLOBAL_SCRIPTVAR: { > - IDispatchEx *dispex; > + IDispatchEx *dpex; How about renaming argument name to 'iface'? It's not really an interface, but its purpose in this context is like iface arguments in regular COM objects. Jacek

2 1

Re: wined3d: Prevent crash when blit_priv is NULL.
by Roderick Colenbrander 21 Mar '11

21 Mar '11

Hi Konrad, You should try to figure out why blit_priv is NULL. That's the real issue. What drivers are you using? Do they support arb fragment program? Right now we may still call arbfp_blit_surface when the extension isn't around (was working on this a year ago, haven't had time since then :( ), this could explain why there is no priv_data since in ffp_blit_alloc we don't do any allocation. Roderick On Sun, Mar 20, 2011 at 3:58 AM, Konrad Rzepecki <hannibal(a)astral.lodz.pl> wrote: > Might&Magic VII from gog.com crash in bink movie plaing: > > Backtrace: > =>0 0x7e70c4b9 arbfp_blit_set+0x28b(blit_priv=0x0(nil), gl_info=0x135b08, surface=0x1dc788) [/mnt/skopia/devel/winegit/wine/dlls/wined3d/arb_program_shader.c:7058] in wined3d (0x0033f98c) > 1 0x7e70d3db arbfp_blit_surface+0xa2(device=0x16cdc0, src_surface=0x1dc788, src_rect=0x33fa74, dst_surface=0x168140, dst_rect_in=0x33fa84, blit_op=BLIT_OP_BLIT, Filter=0x2) [/mnt/skopia/devel/winegit/wine/dlls/wined3d/arb_program_shader.c:7192] in wined3d (0x0033f9dc) > 2 0x7e7d28f7 IWineD3DSurfaceImpl_BltOverride+0xf1b(dst_surface=0x168140, DestRect=0x33fcf8, src_surface=0x1dc788, SrcRect=0x33fce8, flags=0x1000000, DDBltFx=(nil), Filter=WINED3DTEXF_LINEAR) [/mnt/skopia/devel/winegit/wine/dlls/wined3d/surface.c:3787] in wined3d (0x0033fbac) > 3 0x7e7d3013 IWineD3DSurfaceImpl_Blt+0x29e(iface=0x168140, DestRect=0x33fcf8, src_surface=0x1dc788, SrcRect=0x33fce8, flags=0x1000000, DDBltFx=(nil), Filter=WINED3DTEXF_LINEAR) [/mnt/skopia/devel/winegit/wine/dlls/wined3d/surface.c:3930] in wined3d (0x0033fc2c) > 4 0x7e8687f2 ddraw_surface7_Blt+0x380(iface=0x135308, DestRect=0x33fcf8, SrcSurface=0x1dc560, SrcRect=0x33fce8, Flags=0x1000000, DDBltFx=(nil)) [/mnt/skopia/devel/winegit/wine/dlls/ddraw/surface.c:908] in ddraw (0x0033fc9c) > 5 0x004a18cd in mm7-rel (+0xa18cc) (0x0033fcc8) > 6 0x004beda4 in mm7-rel (+0xbeda3) (0x0033fd08) > 7 0x004be721 in mm7-rel (+0xbe720) (0x00000000) > --- > dlls/wined3d/surface.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c > index 745bd77..baa032b 100644 > --- a/dlls/wined3d/surface.c > +++ b/dlls/wined3d/surface.c > @@ -3924,8 +3924,8 @@ static HRESULT WINAPI IWineD3DSurfaceImpl_Blt(IWineD3DSurface *iface, const RECT > } > > /* Special cases for RenderTargets */ > - if ((This->resource.usage & WINED3DUSAGE_RENDERTARGET) > - || (src && (src->resource.usage & WINED3DUSAGE_RENDERTARGET))) > + if (This->resource.device->blit_priv && ((This->resource.usage & WINED3DUSAGE_RENDERTARGET) > + || (src && (src->resource.usage & WINED3DUSAGE_RENDERTARGET)))) > { > if (SUCCEEDED(IWineD3DSurfaceImpl_BltOverride(This, DestRect, src, SrcRect, flags, DDBltFx, Filter))) > return WINED3D_OK; > -- > 1.7.4.1 > > >

3 5

Failing kernel32:change and ntdll:change tests on Mac OS
by Charles Davis 21 Mar '11

21 Mar '11

Hi, I just got done looking over the latest batch of test results I sent, and one thing really sticks out and bothers me. The Change Notification tests all fail miserably on my machine (a 2009 Mac Pro with Mac OS X 10.6), because that feature hasn't been implemented on Mac yet. I could implement it for 10.5 up, but the problem is that the "public" API for Change Notifications on Mac (the "FSEvents" API, in CoreServices.framework) expects clients to either use a CFRunLoop or (on 10.6 and up) a GCD dispatch queue. I'm sure this won't sit well with AJ. I did some digging, and it turns out that FSEvents just uses a Mach port (whose name is published in root's Mach bootstrap context as "com.apple.FSEvents") to talk to a daemon, fseventsd, which in turn opens a device file, /dev/fsevents, which is the actual gateway to the kernel. Though it's largely undocumented, we could use this device file to implement Change Notification. The FDs that get returned by this file even support kqueues. But, there are two tiny problems with that: 1) You have to be root to open /dev/fsevents. If we do it this way, we will have to wait until the server is converted to run as root. 2) Because this API isn't officially documented, it's unstable and subject to change. (In fact, judging from the kernel source, it's already changed once. There are several 'old' and 'new' variants of the FSEvents ioctls that the kernel handler supports.) I guess the real question is, which way should we do this? If we do it the first way (using the public and documented but kqueue-unfriendly Carbon API), wineserver has to use a CFRunLoop (or, if we're no longer concerned about Leopard, a GCD dispatch queue) in its main loop, and if we do it the second way (using the undocumented and unstable but kqueue-friendly Unix API), wineserver needs to run as root, and may need to cope with API changes. Based on what I've heard, I'm leaning toward the second way, but I want your guys' input before I go ahead. Thanks. Chip

2 4

Re: msi: Add an offset to sequence numbers belonging to files added by a patch. (try 2)
by Hans Leidekker 21 Mar '11

21 Mar '11

On Mon, 2011-03-21 at 14:14 +0100, David Hedberg wrote: > +static void msi_patch_offset_list_init(struct msi_patch_offset_list **pos) > +{ > + *pos = msi_alloc(sizeof(struct msi_patch_offset_list)); > + list_init( &(*pos)->files ); > + (*pos)->count = (*pos)->max = 0; > + (*pos)->min = 999999; > +} It would be nicer to have a _create function that returns an initialized structure.

1 0

Re: user32: Fix return value when passing a non-sibling preceding window to SetWindowPos.
by Dmitry Timoshkov 21 Mar '11

21 Mar '11

David Hedberg <dhedberg(a)codeweavers.com> wrote: > +#define ERROR_ABORT_WITH_TRUE 30000 ... > /* Fix redundant flags */ > - if (!fixup_flags( winpos )) return FALSE; > + ret = fixup_flags( winpos ); > + if(ret == ERROR_FUNCTION_FAILED) > + return FALSE; > + else if(ret == ERROR_ABORT_WITH_TRUE) > + return TRUE; Please try to avoid made up names and internal conditions. I'd suggest to add a test case which shows the problem first with todo_wine around the failing test, and only then send a fix, so it's clear what actually your patch is doing. Tiny nitpick, in the code below: if (condition1) return something1; else if (contition2) return something2; 'else' statement is redundant. -- Dmitry.

1 0

Re: [1/4] wined3d: don't create VBOs in buffer::preload
by Henri Verbeet 21 Mar '11

21 Mar '11

On 20 March 2011 20:07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > I'm not so sure about this patch. I think preload() should conceptually be "wined3d_resource_load_location(resource, WINED3D_RESOURCE_LOCATION_GPU, NULL);", and this patch seems to move away from that rather than towards it. I'm also not sure about how the bug you're describing would actually happen. Although device_stream_info_from_declaration() seems to assume preload() can only drop buffer objects, it does correctly call buffer_get_sysmem(), so the resulting stream info should be consistent, even though perhaps somewhat sub-optimal. Shouldn't this just be a matter of fixing device_stream_info_from_declaration() to not assume preload() can only drop buffer objects?

1 0

Re: [PATCH] winegcc - do not create .exe.so
by Vitaliy Margolen 21 Mar '11

21 Mar '11

On 03/20/2011 05:14 AM, Pali Rohár wrote: > Can anybody review my patch? Not sure what you trying to do exactly. Wine already has wrapper that makes all wine binaries executable after they are being installed into system. As for the patch: - Do not use tab characters - Please no unneeded white space changes - Use git to create your patch. At the very minimum it have to have full path to the source file in the header - patch should be generated from the top of the source tree. Vitaliy.

4 8

Re: [PATCH] winegcc - do not create .exe.so
by James McKenzie 21 Mar '11

21 Mar '11

On 3/20/11 4:14 AM, Pali Rohár wrote: > 2011/2/19 Pali Rohár<pali.rohar(a)gmail.com>: >> 2011/2/4 Pali Rohár<pali.rohar(a)gmail.com>: >>> Hello, >>> >>> I created patch which implement correct _start section in ELF shared >>> libraries/binaries which generate winegcc. >>> Into _start section this patch add calling execve syscall which start >>> wine with all arguments. So it is not needed to generate shell wrapper >>> and .exe.so binary. >>> >>> This replace code on: >>> http://wiki.winehq.org/Winelib_binaries_as_ELF_executables_not_.exe.so >>> >>> $ winegcc app.c --> generate only a.exe (shared object ELF binary), no >>> aditional a.exe.so >>> $ ./a.exe --> start binary correctly without shell wrapper >>> >>> -- >>> Pali Rohár >>> pali.rohar(a)gmail.com >>> >> I rewrited my patch. Now set up correctly enviromental variables too. >> Assembler code is only for x86. >> >> -- >> Pali Rohár >> pali.rohar(a)gmail.com >> > Can anybody review my patch? > Reviews are sent to wine-development list. If you want to submit a patch for comment only, please submit it to wine-development. Thank you. James McKenzie

1 0

Idea
by Sanket Patel 20 Mar '11

20 Mar '11

I Have One Idea ......... Why Should not we make wine portable ? -- " Live 2 Love and Love 2 Live "

2 1