On 13 October 2013 11:13, Marcus Meissner wrote:
> 1104553 Resource leak
>
Fixing the memory leak is fine of course, but I think it would be
better to handle the array initialization in
d3drm_visual_array_create() etc. instead, so that those functions
actually return an object that's properly init
Hum...
WIR= When it's ready ???
Ok ok, i still wait
> From: frederic.dela...@gmail.com
> Date: Sun, 13 Oct 2013 01:49:04 +0200
> Subject: Re: d3d11 patch
> To: asnl...@hotmail.com
> CC: wine-devel@winehq.org
>
> On Fri, Oct 11, 2013 at 7:20 PM, Max . wrote:
> >
On Fri, Oct 11, 2013 at 7:20 PM, Max . wrote:
> Hi,
>
> I would like to know when the first patchs for d3d11 will be introduce into
> wine ?
> Beginning of 2014 ? middle 2014 ? End 2014 ?
>
> Thanks,
WIR
Hi,
I would like to know when the first patchs for d3d11 will be introduce into
wine ?
Beginning of 2014 ? middle 2014 ? End 2014 ?
Thanks,
Hmm... It still fails today. I have a better idea to fix it, will send
a patch tomorrow. Sorry for introducing the failures :(
On Thu, Oct 10, 2013 at 8:42 PM, Qian Hong wrote:
> Sorry for introduced the failures, I'd like to investigate, however I
> can't reproduce the failures on my own Win7. I try to run
> winetest-latest.exe on the testbot, but it ran timeout (as expect), is
> there any way I can increase the timeout
Hello,
On Thu, Oct 10, 2013 at 6:48 PM, Alexandre Julliard wrote:
> Can you please fix the test failures introduced by your previous changes
> first? cf. https://test.winehq.org/data/tests/user32:winstation.html
Sorry for introduced the failures, I'd like to investigate, however I
can't reprodu
Qian Hong writes:
> ---
> dlls/user32/tests/winstation.c | 57
>
> 1 file changed, 57 insertions(+)
Can you please fix the test failures introduced by your previous changes
first? cf. https://test.winehq.org/data/tests/user32:winstation.html
--
Alex
Hi Vincent,
Thanks a lot for the advice, I'll try that.
On Thu, Oct 10, 2013 at 12:41 AM, Vincent Povirk wrote:
> I don't think it's possible to properly implement SwitchDesktop in
> either the X11 or Mac driver. There's just nothing sensible for it to
> do.
>
That's one reason that I didn't try
I don't think it's possible to properly implement SwitchDesktop in
either the X11 or Mac driver. There's just nothing sensible for it to
do.
One possible strategy would be to implement SwitchDesktop in user32
and wineserver. Wineserver could logically track the input desktop,
and OpenInputDesktop
>>
>>> 2. If a variable has something in data, it is fxlc, shader (preshader) or
>>> a
>>> string. This was state ST_CONSTANT and ST_FXLC.
>>>
>>> 3. If it has both (destination and data), it points to an array of shader
>>> variables. The
IsEqualGUID(riid, &IID_IDirect3DRMVisualArray)
>> +|| IsEqualGUID(riid, &IID_IUnknown))
>> {
>> -*ret_iface = iface;
>> IDirect3DRMVisualArray_AddRef(iface);
>> +*out = iface;
>> return S_OK;
>> }
&
ualGUID(riid, &IID_IUnknown))
> {
> -*ret_iface = iface;
> IDirect3DRMVisualArray_AddRef(iface);
> +*out = iface;
> return S_OK;
> }
Although this is existing code the assignment '*out = iface' is wrong,
especially since next patch introduces impl_from_IDirect3DRMVisualArray()
helper. Looks like that file needs a bit of COM clean up.
--
Dmitry.
. The name is in the destination, the index could be calculated
with the data. This will be added in a later patch.
There's still the issue of distinguishing between ST_CONSTANT and
ST_FXLC, checking object_id and type might cover that though.
I think we could distinguish between them. I forg
shader
> variables. The name is in the destination, the index could be calculated
> with the data. This will be added in a later patch.
>
There's still the issue of distinguishing between ST_CONSTANT and
ST_FXLC, checking object_id and type might cover that though.
> Also saving
Hello, this patch is in pending status, is there any way I can improve it?
IMO there is no way to 'correctly' implement OpenInputDesktop before
implementing SwitchDesktop, as far as SwitchDesktop is a stub, it is
safe to assume that OpenInputDesktop will always return either NULL
On 8 October 2013 13:44, Stefan Dösinger wrote:
> Are you sure? E.g. if a texture is used with srgb=true and sRGB_decode
> is supported, wined3d_texture_bind sets WINED3D_TEXTURE_IS_SRGB. If
> the application later calls PreLoad manually, texture2d_preload is
> called with SRGB_ANY. Because of the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-10-08 12:06, schrieb Henri Verbeet:
> On 8 October 2013 00:27, Stefan Dösinger
> wrote:
>> diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c
>> index 52eac16..eb8ca7e 100644 --- a/dlls/wined3d/surface.c +++
>> b/dlls/wined3d/surfac
On 8 October 2013 00:27, Stefan Dösinger wrote:
> diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c
> index 52eac16..eb8ca7e 100644
> --- a/dlls/wined3d/surface.c
> +++ b/dlls/wined3d/surface.c
> @@ -5608,8 +5608,6 @@ HRESULT surface_load_location(struct wined3d_surface
> *surface, DWO
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://newtestbot.winehq.org/JobDetails.pl?Key=2651
Your paranoid andr
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://newtestbot.winehq.org/JobDetails.pl?Key=2649
Your paranoid andr
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://newtestbot.winehq.org/JobDetails.pl?Key=2650
Your paranoid andr
Am 04.10.2013 um 17:15 schrieb Henri Verbeet :
> I guess that makes it ok in practice, but I'd still feel happier about
> this kind of patch if we actually enforced resource access flags
> first. (At which point you could also just check the access flags
> instead of the poo
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://newtestbot.winehq.org/JobDetails.pl?Key=2625
Your paranoid andr
; will go to a cpu side clear because of the INSYSMEM optimization. (This
> optimization is needed for a few other things to work correctly, but that's a
> different patch.)
>
I guess that makes it ok in practice, but I'd still feel happier about
this kind of patch if we actually
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://newtestbot.winehq.org/JobDetails.pl?Key=2624
Your paranoid andr
; will go to a cpu side clear because of the INSYSMEM optimization. (This
> optimization is needed for a few other things to work correctly, but that's a
> different patch.)
Fwiw, the other patches are independent of this patch.
w other things to work correctly, but that's a different patch.)
On 4 October 2013 15:02, Stefan Dösinger wrote:
> Client storage only applies to GL textures, which won't be created for sysmem
> surfaces.
>
I don't think that's necessarily true at the moment. In particular,
ddraw blits can in principle cause a texture to be created for sysmem
surfaces. There m
On 4 October 2013 00:03, Stefan Dösinger wrote:
> @@ -2883,10 +2886,6 @@ HRESULT CDECL wined3d_surface_set_mem(struct
> wined3d_surface *surface, void *mem
> /* Now the surface memory is most up do date. Invalidate drawable
> and texture. */
> surface_validate_location(surface,
On Oct 4, 2013, at 12:17 AM, Ken Thomases wrote:
> ---
> dlls/winemac.drv/cocoa_app.m| 8 ++--
> dlls/winemac.drv/cocoa_window.h | 1 +
> dlls/winemac.drv/cocoa_window.m | 16 +---
> dlls/winemac.drv/event.c| 5 +
> dlls/winemac.drv/macdrv.h | 1 +
> dlls/winem
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-10-03 16:05, schrieb Henri Verbeet:
> I don't think this patch makes sense before you actually unify the
> location management. In particular, after this patch you'd have
> location management in resources that really
On 3 October 2013 15:03, Stefan Dösinger wrote:
> Am 2013-10-03 13:45, schrieb Henri Verbeet:
>> It sounds like you have some ordering issues in that patch set.
> Correct. Patches before patch 24 shouldn't be affected by that though.
> I didn't get around to splitting and
ace part and more explanations.
> It sounds like you have some ordering issues in that patch set.
Correct. Patches before patch 24 shouldn't be affected by that though.
I didn't get around to splitting and recombining patch 24 and some
later bugfixes yet due to other priorities.
Unle
ed3d/wined3d_private.h | 6 -- 2 files changed, 27
>>> insertions(+), 25 deletions(-)
>>>
>> What about surfaces and buffers?
> Will be updated as well. See
> http://www.winehq.org/pipermail/wine-devel/2013-October/101575.html
> for the surface part and more explanations.
It sounds like you have some ordering issues in that patch set.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-10-03 13:14, schrieb Henri Verbeet:
> On 3 October 2013 13:08, Stefan Dösinger
> wrote:
>> --- dlls/wined3d/volume.c | 46
>> +-
>> dlls/wined3d/wined3d_private.h | 6 -- 2 files changed,
On 3 October 2013 13:08, Stefan Dösinger wrote:
> ---
> dlls/wined3d/volume.c | 46
> +-
> dlls/wined3d/wined3d_private.h | 6 --
> 2 files changed, 27 insertions(+), 25 deletions(-)
>
What about surfaces and buffers?
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://newtestbot.winehq.org/JobDetails.pl?Key=2455
Your paranoid andr
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
https://newtestbot.winehq.org/JobDetails.pl?Key=2457
Your paranoid andr
Seems reasonable, but could you put together some tests to show this?
Andrew
On Sat, Sep 28, 2013 at 10:41:15AM +0200, Maarten Lankhorst wrote:
> diff --git a/dlls/dsound/capture.c b/dlls/dsound/capture.c
> index 40f1702..0fe300c 100644
> --- a/dlls/dsound/capture.c
> +++ b/dlls/dsound/capture.c
Please split this.
Huw Davies writes:
> ---
> dlls/setupapi/fakedll.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
I don't think that's correct. The datadir is for platform-independent
files, but the fakedlls are platform specific.
--
Alexandre Julliard
julli...@winehq.org
anoid android.
=== build (build) ===
Patch failed to apply
Isn't this going to make the caption "Wine Gecko Installer" in both cases?
On 27 September 2013 15:23, Stefan Dösinger wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Am 2013-09-27 14:19, schrieb Henri Verbeet:
>> Perhaps, I'm not sure. For that kind of comment to be useful it
>> should have a clear set of implications, and I'm not sure it has
>> that until
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-09-27 14:19, schrieb Henri Verbeet:
> Perhaps, I'm not sure. For that kind of comment to be useful it
> should have a clear set of implications, and I'm not sure it has
> that until we work out the details of the multi-threaded
> implementation
On 27 September 2013 13:05, Stefan Dösinger wrote:
> I think we should place comments like "This function is called through
> the command stream" for all functions that are called through the CS,
> similar to what we do for context activation.
>
Perhaps, I'm not sure. For that kind of comment to b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-09-27 00:15, schrieb Henri Verbeet:
> -swapchain->swapchain_ops->swapchain_present(swapchain,
> src_rect, dst_rect, dirty_region, flags); +
> wined3d_cs_emit_present(swapchain->device->cs, swapchain,
> src_rect, +dst_rect, dst_w
George Stephanos writes:
> @@ -224,13 +248,138 @@ static NTSTATUS open_key( HKEY *retkey, ACCESS_MASK
> access, OBJECT_ATTRIBUTES *a
>
> }
>
> +static LSTATUS create_hkcr_struct( HKEY *hkey, opened_hkcr_t **hkcr )
> +{
> +UINT_PTR handle = nb_hkcr_handles, i;
> +LSTATUS ret = ERROR_
Hi all,
I see this patch is in 'pending' now, are there anything needs to be
improved?
Please give me some advice.
Thank you.
--
Regards,
Jactry Zeng
anoid android.
=== build (build) ===
Patch failed to apply
Daniel Wendt writes:
> @@ -308,6 +308,11 @@ static int get_arc_points( PHYSDEV dev, const RECT
> *rect, POINT start, POINT end
> }
>
> memmove( points, points + count, (pos - count) * sizeof(POINT) );
> +
> +if (GetGraphicsMode( dev->hdc ) == GM_ADVANCED)
> +{
> +LPto
Jactry writes:
> +chBuffer = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, size+2);
> +if(!chBuffer)
> +{
> +CloseHandle(hFile);
> +return HRESULT_FROM_WIN32(GetLastError());
> +}
It's not useful to zero the buffer since you are reading into it. Also
GetLastError
anoid android.
=== build (build) ===
Patch failed to apply
On 25 September 2013 15:32, Rico Schüller wrote:
> Yes. Depending on the use case we may create it on the Begin/BeginPass when
> the shader is needed the first time (this may also be something like
> isParameterUsed or GetVertexShader). We don't need the shaders for cases
> like GetPassDesc, where
On 25.09.2013 14:02, Matteo Bruni wrote:
2013/9/24 Rico Schüller :
---
dlls/d3dx9_36/effect.c | 248
+++--
1 Datei geändert, 95 Zeilen hinzugefügt(+), 153 Zeilen entfernt(-)
I definitely like the direction this patch takes.
@@ -5068,6 +5009,9
2013/9/24 Rico Schüller :
> ---
> dlls/d3dx9_36/effect.c | 248
> +++--
> 1 Datei geändert, 95 Zeilen hinzugefügt(+), 153 Zeilen entfernt(-)
>
I definitely like the direction this patch takes.
@@ -5068,6 +5009,9 @@ static HRESULT d3dx9
anoid android.
=== build (build) ===
Patch failed to apply
anoid android.
=== build (build) ===
Patch failed to apply
anoid android.
=== build (build) ===
Patch failed to apply
r...
> Unhandled exception: page fault on read access to 0x002c in 32-bit code
> (0x686aa077).
Right, the dxgi tests got skipped here, mainly because of missing
geometry shader support. I know what's wrong, just ignore this patch
for the moment.
Henri Verbeet writes:
> ---
> dlls/wined3d/device.c | 51
> +
> dlls/wined3d/stateblock.c |5 +
> 2 files changed, 20 insertions(+), 36 deletions(-)
It doesn't work here:
../../../tools/runtest -q -P wine -M dxgi.dll -T ../../.. -p dxg
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-09-23 17:31, schrieb Stefan Dösinger:
> Am 2013-09-23 17:29, schrieb Henri Verbeet:
>> On 23 September 2013 13:29, Stefan Dösinger
>> wrote:
>>> Note that Windows drivers disagree on which format they
>>> support. Nvidia has V16U16, AMD suppo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-09-23 17:29, schrieb Henri Verbeet:
> On 23 September 2013 13:29, Stefan Dösinger
> wrote:
>> Note that Windows drivers disagree on which format they support.
>> Nvidia has V16U16, AMD supports Q8W8V8U8, at least on r200. I am
>> working on a
On 23 September 2013 13:29, Stefan Dösinger wrote:
> Note that Windows drivers disagree on which format they support. Nvidia
> has V16U16, AMD supports Q8W8V8U8, at least on r200. I am working on a
> more comprehensive converted format test that tests all supported signed
> formats with surfaces.
anoid android.
=== build (build) ===
Patch failed to apply
anoid android.
=== build (build) ===
Patch failed to apply
anoid android.
=== build (build) ===
Patch failed to apply
anoid android.
=== build (build) ===
Patch failed to apply
anoid android.
=== build (build) ===
Patch failed to apply
anoid android.
=== build (build) ===
Patch failed to apply
anoid android.
=== build (build) ===
Patch failed to apply
anoid android.
=== build (build) ===
Patch failed to apply
anoid android.
=== build (build) ===
Patch failed to apply
anoid android.
=== build (build) ===
Patch failed to apply
anoid android.
=== build (build) ===
Patch failed to apply
anoid android.
=== build (build) ===
Patch failed to apply
On 20 September 2013 13:04, Stefan Dösinger wrote:
> +static BOOL wined3d_volume_can_evict(const struct wined3d_volume *volume)
> +{
> +if (volume->resource.pool != WINED3D_POOL_MANAGED)
> +return FALSE;
> +if (volume->download_count < 10)
> +return FALSE;
That doesn't look
On 20 September 2013 13:04, Stefan Dösinger wrote:
> -volume->flags &= ~(WINED3D_VFLAG_ALLOCATED |
> WINED3D_VFLAG_SRGB_ALLOCATED);
> +volume->flags &= ~(WINED3D_VFLAG_ALLOCATED | WINED3D_VFLAG_SRGB_ALLOCATED
> +| WINED3D_VFLAG_CLIENT_STORAGE);
>
Indentation looks a bit off here.
I don't think this is going to work correctly when replacing hotkeys
(by passing an already-registered hwnd and id to RegisterHotKey with a
different key combination). Since the user driver's RegisterHotKey
function will be called with the new id/vkey/flags before
UnregisterHotKey is called for the
On 19 Sep 2013, at 15:07, Bruno Jesus wrote:
> Hi, Huw. I'm not sure this is an issue but in the android
> implementation of get_interface_indexes you are not setting
>
> +if (table) *table = NULL;
Hi Bruno,
Good catch! Resent.
Thanks,
Huw.
On Thu, Sep 19, 2013 at 10:06 AM, Huw Davies wrote:
> ---
> configure.ac | 3 +-
> dlls/iphlpapi/ifenum.c | 199
> -
> 2 files changed, 200 insertions(+), 2 deletions(-)
Hi, Huw. I'm not sure this is an issue but in the android
impleme
Jacek Caban writes:
> ---
> dlls/mshtml/navigate.c | 3 ---
> 1 file changed, 3 deletions(-)
It doesn't work here:
../../../tools/runtest -q -P wine -M urlmon.dll -T ../../.. -p
urlmon_test.exe.so url.c && touch url.ok
url.c:3397: Test failed: mon should be destroyed here
url.c:3397: Test fai
On Sep 16, 2013, at 1:21 PM, Ken Thomases wrote:
> On Sep 16, 2013, at 12:55 PM, Alexandre Julliard wrote:
>
>> It's better to avoid adding entry points that don't correspond to
>> Windows APIs. Instead you should request the info when you need it.
>
> Cocoa makes use of the size limits "spontan
anoid android.
=== build (build) ===
Patch failed to apply
anoid android.
=== build (build) ===
Patch failed to apply
anoid android.
=== build (build) ===
Patch failed to apply
anoid android.
=== build (build) ===
Patch failed to apply
On 17 September 2013 21:07, Stefan Dösinger wrote:
> I might have misunderstood what you meant with "separate flags for
> each GL resource type". Did you mean something like this
>
> B8G8R8A8_UNORM.flags[texture2d] = RENDERTARGET | TEXTURE | ...;
> B8G8R8A8_UNORM.flags[renderbuffer] = RENDERTARGET
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-09-17 17:12, schrieb Henri Verbeet:
> The point is that the distinction you're making here between
> volumes and everything else is a bit arbitrary, and I think this
> patch as it is will make it more work rather than less to
On Tue, Sep 17, 2013 at 3:01 PM, Andrew Eikum wrote:
> This fixes a crash in PowerPoint when a shape is made
> semi-transparent.
May also fix bug http://bugs.winehq.org/show_bug.cgi?id=34463 and
http://bugs.winehq.org/show_bug.cgi?id=30485
or ARB_internalformat_query2
>> as well, and I'd prefer "TEXTURE3D" over "VOLUME".
> I don't see what your intentions are exactly.
The point is that the distinction you're making here between volumes
and everything else is a bit arbitrary, and I think this patc
#x27;t
get us anywhere with bug 21708.
Changing the format flags to have one flag for each resource type
wasn't exactly on my priority list. The goal of this patch and patch 3
is to make the dxtn creation tests in patch 7 work. Adding a TEXTURE3D
flag is a step in the correct direction. My
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-09-17 15:05, schrieb Henri Verbeet:
> I was mostly thinking of merging e.g. wined3d_surface_get_pitch()
> and wined3d_volume_get_pitch() into wined3d_resource_get_pitch(). I
> don't feel strongly about doing that first though, so if you're
> sa
On 17 September 2013 14:58, Stefan Dösinger wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Am 2013-09-17 13:55, schrieb Henri Verbeet:
>> On 17 September 2013 11:39, Stefan Dösinger
>> wrote:
>>> --- dlls/wined3d/volume.c | 95
>>> +++
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-09-17 13:55, schrieb Henri Verbeet:
> On 17 September 2013 11:39, Stefan Dösinger
> wrote:
>> --- dlls/wined3d/volume.c | 95
>> +++ 1 file
>> changed, 88 insertions(+), 7 deletions(-)
>>
> Can't
On 17 September 2013 11:39, Stefan Dösinger wrote:
> diff --git a/dlls/wined3d/wined3d_private.h b/dlls/wined3d/wined3d_private.h
> index 4928f92..eabf890 100644
> --- a/dlls/wined3d/wined3d_private.h
> +++ b/dlls/wined3d/wined3d_private.h
> @@ -2927,6 +2927,7 @@ extern enum wined3d_format_id
> p
On 17 September 2013 11:39, Stefan Dösinger wrote:
> ---
> dlls/wined3d/volume.c | 95
> +++
> 1 file changed, 88 insertions(+), 7 deletions(-)
>
Can't most of this be done on the resource level instead?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-09-17 11:55, schrieb Henri Verbeet:
> CreateDevice() returns D3DERR_SURFACENOTINVIDMEM, provided the
> surface would otherwise be suitable for rendering.
> SetRenderTarget() has inconsistent behaviour between versions, but
> returns DDERR_INVAL
On 17 September 2013 11:48, Stefan Dösinger wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Am 2013-09-17 09:22, schrieb Henri Verbeet:
>> Setting render target usage on a P8 surface for example would fail
>> surface creation, while such surfaces can't be used for actual
>> rendering
1 - 100 of 9232 matches
Mail list logo
