April 2016 - Wine-Devel - list.winehq.org

Re: [PATCH] d3dx9: Don't complain when overwriting effect object id 0.

by Matteo Bruni

>> No, you're right, I forgot the free altogether. Let's drop this patch, >> unless it's too late. I'll send a fix either way. Uh, somehow I missed the earlier push. Sending the additional patch...

April 18, 2016

Re: [PATCH] d3dx9: Don't complain when overwriting effect object id 0.

by Matteo Bruni

2016-04-18 17:42 GMT+02:00 Matteo Bruni <matteo.mystral(a)gmail.com>: > 2016-04-18 15:26 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: >> Matteo, >> >> I must be missing something, but don't you forget to free the >> object->data when it is reallocated at least for object id 0 when it is >> not FIXME anymore? I suppose you don't but I looked through several >> times and do not see how it can be freed when it was allocated previously. >> >> Regards, >> Paul. > > No, you're right, I forgot the free altogether. Let's drop this patch, > unless it's too late. I'll send a fix either way. For the records, the leak is already there in git. It makes sense to fix it in this patch though.

April 18, 2016

Re: [PATCH 1/2] d3drm: Implement IDirect3DRM*::CreateObject.

by Aaryaman Vasishta

I thought it'd be a good idea to keep it void * for once future objects would be implemented (i.e. the one's that have todo marked as true in the tests). But you do have a point. Since I'm just returning texture objects right now, maybe using d3drm_texture structure would do. What should I go with? Cheers, Aaryaman On Mon, Apr 18, 2016 at 6:58 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 18 April 2016 at 15:15, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> > wrote: > > On Mon, Apr 18, 2016 at 4:17 PM, Henri Verbeet <hverbeet(a)gmail.com> > wrote: > >> Why do you need "object_struct"? > > > > I need it to store the object's address, from which the IUnknown > interface > > is obtained which in turn is used to QI the required object using iid. > > > > Am I missing something? Is there a better way? I suppose I could re-use > > object and keep it as a void * instead of IUnknown.. > > > What's wrong with using a d3drm_texture structure? >

April 18, 2016

Re: [PATCH] d3dx9: Don't complain when overwriting effect object id 0.

by Matteo Bruni

2016-04-18 15:26 GMT+02:00 Paul Gofman <gofmanp(a)gmail.com>: > Matteo, > > I must be missing something, but don't you forget to free the > object->data when it is reallocated at least for object id 0 when it is > not FIXME anymore? I suppose you don't but I looked through several > times and do not see how it can be freed when it was allocated previously. > > Regards, > Paul. No, you're right, I forgot the free altogether. Let's drop this patch, unless it's too late. I'll send a fix either way.

April 18, 2016

Re: ntdll: Ignore invalid exit_frame when exiting thread.

by Sebastian Lackner

On 18.04.2016 12:53, Alexandre Julliard wrote: >> Yes, MSYS2/Cygwin will switch to its own stack and deallocate the old one. >> This patch alone is not sufficient because there are still a couple of other >> references to the old stack (like the debug_info struct in start_thread). >> >> If preferred, this issue can also be solved differently by calculting exit_frame >> dynamically based on StackBase (after a couple of other bugs are fixed). >> Disadvantage is that if applications mess around with StackBase, I'm not sure if >> we should trust that the new stack is set up properly. > > The reason for exit_frame is to prevent pthread_exit from trying to > unwind the stack. I'm wondering how that will work if it was > deallocated. Did you look into this? Does pthread detect that we are on > a different stack? And doesn't pthread also put its own structures on > the stack? > Some versions of pthread indeed put internal structures at the top of the stack. To solve that, the current Staging patchset allocates threads with a dummy pthread, and then switches to the real stack, see: https://github.com/wine-compholio/wine-staging/blob/master/patches/ntdll-Th… Unless there is something weird going on, thanks to the CFI annotations in wine_switch_to_stack() pthread should be able to unwind the stack correctly despite the stack switch inbetween. At least I have not found any problems so far ;) You are right that ignoring exit_frame might (under specific circumstances) run language handlers, but I'm not yet aware of a better way to deal with this. The only alternative would be to calculate it based on StackBase, but its also far from perfect.

April 18, 2016

RE: wined3d: Add Nvidia GT 9700M

by Caron Wills

Actually, you sent it to the right place. There are some things you should have a look at that my eyes are drawn to. First, when reviewed here, the patch has odd line breaks and spacing: https://source.winehq.org/patches/data/121371 It's also missing your signed-off-by line. You can read about how to add that here: https://wiki.winehq.org/Submitting_Patches Your patch should come through clean and match the surrounding style. I had a patch accepted adding the same number of lines in the same general places, pay close attention to how the two differ in appearance: https://source.winehq.org/patches/data/121336 I'm looking at those patches simply by going to this page to make sure everything "looks" okay: https://source.winehq.org/patches/ Note the red "X" indicating the missing sign-off next to your patch. You would do yourself many favors by using git send-email to send patches or in the very least, take a moment to create a patch and check it over once, twice, three times, before sending. I commit to my local tree and then I do: git format-patch origin and compare what's going on and then I make sure Wine still builds after my changes. I catch a lot of mistakes that way (like missing a comma...). Thank you for sending a patch and following up on it. Others might have more feedback for you. -Caron -----Original Message----- From: wine-devel [mailto:wine-devel-bounces(a)winehq.org] On Behalf Of Kim Malmo Sent: Monday, April 18, 2016 9:57 AM To: wine-devel(a)winehq.org Subject: wined3d: Add Nvidia GT 9700M I posted this one to wine-patches, I realize I may have sent it to the wrong mailing list. I would probably want some feedback on this one, as it's basically a dirty hack I put together. Critisism welcome. Posted here: https://www.winehq.org/pipermail/wine-patches/2016-April/149298.html wined3d: Add Nvidia GT 9700M Bug: https://bugs.winehq.org/show_bug.cgi?id=36031 --- dlls/wined3d/directx.c | 2 ++ dlls/wined3d/wined3d_private.h | 1 + 2 files changed, 3 insertions(+) diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c index 8358930..6b115d3 100644 --- a/dlls/wined3d/directx.c +++ b/dlls/wined3d/directx.c @@ -1230,6 +1230,7 @@ static const struct gpu_description gpu_description_table[] = {HW_VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9400GT, "NVIDIA GeForce 9400 GT", DRIVER_NVIDIA_GEFORCE8, 256 }, {HW_VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9500GT, "NVIDIA GeForce 9500 GT", DRIVER_NVIDIA_GEFORCE8, 256 }, {HW_VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9600GT, "NVIDIA GeForce 9600 GT", DRIVER_NVIDIA_GEFORCE8, 384 }, + {HW_VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9700M, "NVIDIA GeForce 9700M", DRIVER_NVIDIA_GEFORCE8, 512 }, {HW_VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9800GT, "NVIDIA GeForce 9800 GT", DRIVER_NVIDIA_GEFORCE8, 512 }, {HW_VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_210, "NVIDIA GeForce 210", DRIVER_NVIDIA_GEFORCE8, 512 }, {HW_VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_GT220, "NVIDIA GeForce GT 220", DRIVER_NVIDIA_GEFORCE8, 512 }, @@ -1819,6 +1820,7 @@ cards_nvidia_binary[] = {"GTS 150", CARD_NVIDIA_GEFORCE_9800GT}, /* Geforce 9 - highend / Geforce 200 - midend */ {"9800", CARD_NVIDIA_GEFORCE_9800GT}, /* Geforce 9 - highend / Geforce 200 - midend */ {"GT 140", CARD_NVIDIA_GEFORCE_9600GT}, /* Geforce 9 - midend */ + {"9700M", CARD_NVIDIA_GEFORCE_9700M}, /* Geforce 9 - midend */ {"9600", CARD_NVIDIA_GEFORCE_9600GT}, /* Geforce 9 - midend */ {"GT 130", CARD_NVIDIA_GEFORCE_9500GT}, /* Geforce 9 - midend low / Geforce 200 - low */ {"GT 120", CARD_NVIDIA_GEFORCE_9500GT}, /* Geforce 9 - midend low / Geforce 200 - low */ diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h index 24515da..95dd88b 100644 --- a/dlls/wined3d/wined3d_private.h +++ b/dlls/wined3d/wined3d_private.h @@ -1739,6 +1739,7 @@ enum wined3d_pci_device CARD_NVIDIA_GEFORCE_9400GT = 0x042c, CARD_NVIDIA_GEFORCE_9500GT = 0x0640, CARD_NVIDIA_GEFORCE_9600GT = 0x0622, + CARD_NVIDIA_GEFORCE_9700M = 0x064a, CARD_NVIDIA_GEFORCE_9800GT = 0x0614, CARD_NVIDIA_GEFORCE_210 = 0x0a23, CARD_NVIDIA_GEFORCE_GT220 = 0x0a20, -- 1.9.1

April 18, 2016

wined3d: Add Nvidia GT 9700M

by Kim Malmo

I posted this one to wine-patches, I realize I may have sent it to the wrong mailing list. I would probably want some feedback on this one, as it's basically a dirty hack I put together. Critisism welcome. Posted here: https://www.winehq.org/pipermail/wine-patches/2016-April/149298.html wined3d: Add Nvidia GT 9700M Bug: https://bugs.winehq.org/show_bug.cgi?id=36031 --- dlls/wined3d/directx.c | 2 ++ dlls/wined3d/wined3d_private.h | 1 + 2 files changed, 3 insertions(+) diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c index 8358930..6b115d3 100644 --- a/dlls/wined3d/directx.c +++ b/dlls/wined3d/directx.c @@ -1230,6 +1230,7 @@ static const struct gpu_description gpu_description_table[] = {HW_VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9400GT, "NVIDIA GeForce 9400 GT", DRIVER_NVIDIA_GEFORCE8, 256 }, {HW_VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9500GT, "NVIDIA GeForce 9500 GT", DRIVER_NVIDIA_GEFORCE8, 256 }, {HW_VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9600GT, "NVIDIA GeForce 9600 GT", DRIVER_NVIDIA_GEFORCE8, 384 }, + {HW_VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9700M, "NVIDIA GeForce 9700M", DRIVER_NVIDIA_GEFORCE8, 512 }, {HW_VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_9800GT, "NVIDIA GeForce 9800 GT", DRIVER_NVIDIA_GEFORCE8, 512 }, {HW_VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_210, "NVIDIA GeForce 210", DRIVER_NVIDIA_GEFORCE8, 512 }, {HW_VENDOR_NVIDIA, CARD_NVIDIA_GEFORCE_GT220, "NVIDIA GeForce GT 220", DRIVER_NVIDIA_GEFORCE8, 512 }, @@ -1819,6 +1820,7 @@ cards_nvidia_binary[] = {"GTS 150", CARD_NVIDIA_GEFORCE_9800GT}, /* Geforce 9 - highend / Geforce 200 - midend */ {"9800", CARD_NVIDIA_GEFORCE_9800GT}, /* Geforce 9 - highend / Geforce 200 - midend */ {"GT 140", CARD_NVIDIA_GEFORCE_9600GT}, /* Geforce 9 - midend */ + {"9700M", CARD_NVIDIA_GEFORCE_9700M}, /* Geforce 9 - midend */ {"9600", CARD_NVIDIA_GEFORCE_9600GT}, /* Geforce 9 - midend */ {"GT 130", CARD_NVIDIA_GEFORCE_9500GT}, /* Geforce 9 - midend low / Geforce 200 - low */ {"GT 120", CARD_NVIDIA_GEFORCE_9500GT}, /* Geforce 9 - midend low / Geforce 200 - low */ diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h index 24515da..95dd88b 100644 --- a/dlls/wined3d/wined3d_private.h +++ b/dlls/wined3d/wined3d_private.h @@ -1739,6 +1739,7 @@ enum wined3d_pci_device CARD_NVIDIA_GEFORCE_9400GT = 0x042c, CARD_NVIDIA_GEFORCE_9500GT = 0x0640, CARD_NVIDIA_GEFORCE_9600GT = 0x0622, + CARD_NVIDIA_GEFORCE_9700M = 0x064a, CARD_NVIDIA_GEFORCE_9800GT = 0x0614, CARD_NVIDIA_GEFORCE_210 = 0x0a23, CARD_NVIDIA_GEFORCE_GT220 = 0x0a20, -- 1.9.1

April 18, 2016

Re: [PATCH 1/2] d3drm: Implement IDirect3DRM*::CreateObject.

by Henri Verbeet

On 18 April 2016 at 15:15, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> wrote: > On Mon, Apr 18, 2016 at 4:17 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: >> Why do you need "object_struct"? > > I need it to store the object's address, from which the IUnknown interface > is obtained which in turn is used to QI the required object using iid. > > Am I missing something? Is there a better way? I suppose I could re-use > object and keep it as a void * instead of IUnknown.. > What's wrong with using a d3drm_texture structure?

April 18, 2016

Re: [PATCH 1/2] d3drm: Implement IDirect3DRM*::CreateObject.

by Aaryaman Vasishta

On Mon, Apr 18, 2016 at 4:17 PM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > On 17 April 2016 at 22:57, Aaryaman Vasishta <jem456.vasishta(a)gmail.com> > wrote: > > @@ -1054,10 +1058,50 @@ static ULONG WINAPI d3drm3_Release(IDirect3DRM3 > *iface) > > static HRESULT WINAPI d3drm3_CreateObject(IDirect3DRM3 *iface, > > REFCLSID clsid, IUnknown *outer, REFIID iid, void **out) > > { > > - FIXME("iface %p, clsid %s, outer %p, iid %s, out %p stub!\n", > > + void *object_struct; > ... > > + if (IsEqualGUID(clsid, &CLSID_CDirect3DRMTexture)) > > + { > > + if (FAILED(hr = d3drm_texture_create((struct d3drm_texture > **)&object_struct))) > > + { > > + *out = NULL; > > + return hr; > > + } > > + object = (IUnknown *)&((struct d3drm_texture > *)object_struct)->IDirect3DRMTexture3_iface; > > + } > Why do you need "object_struct"? > I need it to store the object's address, from which the IUnknown interface is obtained which in turn is used to QI the required object using iid. Am I missing something? Is there a better way? I suppose I could re-use object and keep it as a void * instead of IUnknown.. Cheers, Aaryaman

April 18, 2016

Re: riched20: Use SetRect instead of open coding it.

by Huw Davies

On 18 Apr 2016, at 13:37, Michael Stefaniuc <mstefani(a)redhat.com> wrote: > > I have amended my coccinelle script to generate compile failures in > those cases. There were two more of those in my patch. > > How do you prefer to handle this cases? Still use SetRect() or leave > them open coded? I'd prefer those open coded, so it’s obvious what the width or height is. Huw.

April 18, 2016