May 2017 - Wine-Devel - list.winehq.org

Re: [PATCH] msvcp140: Implement _To_wide.

by Marvin

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://testbot.winehq.org/JobDetails.pl?Key=31204 Your paranoid android. === wvistau64 (32 bit msvcp140) === msvcp140.c:492: Test failed: Got unexpected output L"\05e6\05d4\f895\f893\20ac\009f" === wvistau64 (64 bit msvcp140) === msvcp140.c:492: Test failed: Got unexpected output L"\05e6\05d4\f895\f893\20ac\009f"

May 26, 2017

Re: [PATCH] macdrv: Don't update clipboard if its content didn't change

by Piotr Caban

> I'll have to run some tests again to see exactly which operations do and don't increment the change count. I'll let you know what I find. > > It may be that your patch is better for the vast majority of the cases such that we should commit it. We'll just accept incorrect behavior for the (hopefully) rare aberrant uses of the API that I'm concerned about. Or maybe we can take a belt-and-suspenders approach and check both the change count and the list of types. I’ve done some initial testing: [myPasteboard clearContents]; clearContent increments the changeCount. [myPasteboard setString:@"test" forType:NSStringPboardType]; NSLog(@"changeCount %ld", [myPasteboard changeCount]); [NSThread sleepForTimeInterval:2]; [myPasteboard setString:@"test2" forType:NSStringPboardType]; NSLog(@“changeCount %ld", [myPasteboard changeCount]); In this case changeCount doesn’t change no matter if other applications read the pasteboard data between setString calls. [myPasteboard addTypes:[NSArray arrayWithObject:NSRTFPboardType] owner:nil]; NSLog(@“addTypes changeCount %ld”, [myPasteboard changeCount]); [myPasteboard setString:rtf forType:NSRTFPboardType]; NSLog(@"new data type changeCount %ld", [myPasteboard changeCount]); Adding new clipboard format doesn’t change changeCount. Setting value for newly added format also doesn’t change it. [myPasteboard declareTypes:[NSArray arrayWithObjects:NSStringPboardType, NSURLPboardType, nil] owner:nil]; declareTypes changes changeCount value. Thank you, Piotr

May 26, 2017

Re: [PATCH] macdrv: Don't update clipboard if its content didn't change

by Ken Thomases

On May 25, 2017, at 5:26 PM, Piotr Caban <piotr(a)codeweavers.com> wrote: > > >> Unfortunately, -[NSPasteboard changeCount] isn't incremented for all changes to the pasteboard. For example, if the owner replaces the data for an existing type, it doesn't change. I'd have to check again, but I think it doesn't even change if the owner adds a new data type. I think it only changes when the pasteboard is cleared and rebuilt by -clearContents or -declareTypes:owner:. > > I wonder if applications that are doing it are using pasteboard API correctly. … > I’ve also checked the code of open source clipboard manager that works on Mac (Flycut) - as far as I can see it's looking for clipboard changes this way. Well, I suspect that the vast majority of the time, apps work with the pasteboard in a way which does allow another app to poll the change count to be informed of the changes. I'd even go so as to say that that's the "normal" way of working with the pasteboard. However, the API allows for the operations that in fact change the data on the pasteboard but which don't increment the change count. I don't think such uses of the API are incorrect, just uncommon. > The documentation says that “application can determine whether the current data in the pasteboard is the same as the data it last received” by checking changeCount value. The docs also say, "The change count … increments every time the contents of the pasteboard changes (a new owner is declared)"[1] and, "The change count … increments each time the pasteboard ownership changes."[2] Those suggest it's tied to the methods which specifically take ownership of (and clear) the pasteboard. [1] https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/… [2] https://developer.apple.com/reference/appkit/nspasteboard/1533544-changecou… I'll have to run some tests again to see exactly which operations do and don't increment the change count. I'll let you know what I find. It may be that your patch is better for the vast majority of the cases such that we should commit it. We'll just accept incorrect behavior for the (hopefully) rare aberrant uses of the API that I'm concerned about. Or maybe we can take a belt-and-suspenders approach and check both the change count and the list of types. -Ken

May 26, 2017

Re: [PATCH] oleaut32: Add VarBstrFromDisp tests

by Marvin

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://testbot.winehq.org/JobDetails.pl?Key=31191 Your paranoid android. === wxppro (32 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\c3c9\768d\c700\2444\7804\0014\c700\2404\9400S\8ce8\0091\c700\2404\fe44S\40e8\0094\c900\8dc3\26b4" === w2003std (32 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\c3c9\768d\c700\2444\7804\0014\c700\2404\9400S\8ce8\0091\c700\2404\fe44S\40e8\0094\c900\8dc3\26b4" === wvistau64 (32 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\c3c9\768d\c700\2444\7804\0014\c700\2404\9400S\8ce8\0091\c700\2404\fe44S\40e8\0094\c900\8dc3\26b4" === w2008s64 (32 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\c3c9\768d\c700\2444\7804\0014\c700\2404\9400S\8ce8\0091\c700\2404\fe44S\40e8\0094\c900\8dc3\26b4" === w7u (32 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\c3c9\768d\c700\2444\7804\0014\c700\2404\9400S\8ce8\0091\c700\2404\fe44S\40e8\0094\c900\8dc3\26b4" === w7pro64 (32 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\c3c9\768d\c700\2444\7804\0014\c700\2404\9400S\8ce8\0091\c700\2404\fe44S\40e8\0094\c900\8dc3\26b4" === w8 (32 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\c3c9\768d\c700\2444\7804\0014\c700\2404\9400S\8ce8\0091\c700\2404\fe44S\40e8\0094\c900\8dc3\26b4" === w864 (32 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\c3c9\768d\c700\2444\7804\0014\c700\2404\9400S\8ce8\0091\c700\2404\fe44S\40e8\0094\c900\8dc3\26b4" === w1064 (32 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\c3c9\768d\c700\2444\7804\0014\c700\2404\9400S\8ce8\0091\c700\2404\fe44S\40e8\0094\c900\8dc3\26b4" === wvistau64 (64 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\8b4c\53dc\5655\4157\4154\4155\4156\4857\ec81\00a8" oleaut32:vartype crashed (c0000374) === w2008s64 (64 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\8b4c\53dc\5655\4157\4154\4155\4156\4857\ec81\00a8" oleaut32:vartype crashed (c0000374) === w7pro64 (64 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\8b4c\53dc\5655\4157\4154\4155\4156\4857\ec81\00a8" oleaut32:vartype crashed (c0000374) === w1064 (64 bit vartype) === vartype.c:5306: Test failed: got 0x80020008 vartype.c:5307: Test failed: got L"\5540\5653\4157\4154\4155\4156\4857\6c8d\e124\8148\d8ec" oleaut32:vartype crashed (c0000374)

May 25, 2017

Re: [PATCH] macdrv: Don't update clipboard if its content didn't change

by Piotr Caban

> Unfortunately, -[NSPasteboard changeCount] isn't incremented for all changes to the pasteboard. For example, if the owner replaces the data for an existing type, it doesn't change. I'd have to check again, but I think it doesn't even change if the owner adds a new data type. I think it only changes when the pasteboard is cleared and rebuilt by -clearContents or -declareTypes:owner:. I wonder if applications that are doing it are using pasteboard API correctly. The documentation says that “application can determine whether the current data in the pasteboard is the same as the data it last received” by checking changeCount value. I’ve also checked the code of open source clipboard manager that works on Mac (Flycut) - as far as I can see it's looking for clipboard changes this way.

May 25, 2017

Re: [PATCH] macdrv: Don't update clipboard if its content didn't change

by Ken Thomases

On May 25, 2017, at 1:22 PM, Piotr Caban <piotr(a)codeweavers.com> wrote: > > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > dlls/winemac.drv/clipboard.c | 34 ++++++++++------------------------ > dlls/winemac.drv/cocoa_clipboard.m | 18 ++++++++++++++++++ > dlls/winemac.drv/macdrv_cocoa.h | 1 + > 3 files changed, 29 insertions(+), 24 deletions(-) > > +int macdrv_has_pasteboard_changed(void) > +{ > + __block int new_change_count; > + int ret; > + > + OnMainThread(^{ > + NSPasteboard* pb = [NSPasteboard generalPasteboard]; > + new_change_count = [pb changeCount]; > + }); > + > + ret = (change_count != new_change_count); > + change_count = new_change_count; > + return ret; > +} Unfortunately, -[NSPasteboard changeCount] isn't incremented for all changes to the pasteboard. For example, if the owner replaces the data for an existing type, it doesn't change. I'd have to check again, but I think it doesn't even change if the owner adds a new data type. I think it only changes when the pasteboard is cleared and rebuilt by -clearContents or -declareTypes:owner:. -Ken

May 25, 2017

Re: [v5 PATCH 1/3] wined3d: Send texture updates through the command stream.

by Masanori Kakura

On Wed, 24 May 2017 16:08:30 +0200 Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > Am 2017-05-24 um 15:49 schrieb Masanori Kakura: > > + for (j = 0; j < layer_count; ++j) > > + { > > + wined3d_cs_emit_blt_sub_resource(cs, > > + &dst_texture->resource, j * dst_level_count + i, &box, > > + &src_texture->resource, j * src_level_count + i + src_skip_levels, &box, > > + 0, NULL, WINED3D_TEXF_POINT); > > + } > I don't like emitting new operations in the CS handler instead of doing > the actual operation. Maybe this can be avoided with some refactoring of > wined3d_cs_exec_blt_sub_resource? I wrote 2 new patches but I'm not sure which is better. ----- Patch 1 (modify wined3d_cs_exec_blt_sub_resource) ----- static void wined3d_cs_exec_blt_sub_resource(struct wined3d_cs *cs, const void *data) { /* ... */ error: if (op->opcode == WINED3D_CS_OP_BLT_SUB_RESOURCE) { if (op->src_resource) wined3d_resource_release(op->src_resource); wined3d_resource_release(op->dst_resource); } } static void wined3d_cs_exec_update_texture(struct wined3d_cs *cs, const void *data) { /* ... */ for (i = 0; i < level_count; ++i) { width = wined3d_texture_get_level_width(dst_texture, i); height = wined3d_texture_get_level_height(dst_texture, i); depth = wined3d_texture_get_level_depth(dst_texture, i); wined3d_box_set(&box, 0, 0, width, height, 0, depth); for (j = 0; j < layer_count; ++j) { const struct wined3d_cs_blt_sub_resource op_blt = {WINED3D_CS_OP_UPDATE_TEXTURE, &dst_texture->resource, j * dst_level_count + i, box, &src_texture->resource, j * src_level_count + i + src_skip_levels, box, 0, NULL, WINED3D_TEXF_POINT}; wined3d_cs_exec_blt_sub_resource(cs, &op_blt); } } wined3d_resource_release(&src_texture->resource); wined3d_resource_release(&dst_texture->resource); } ----- Patch 2 (write codes directly) ----- static void wined3d_cs_exec_update_texture(struct wined3d_cs *cs, const void *data) { /* ... */ /* Update every surface level of the texture. */ for (i = 0; i < level_count; ++i) { width = wined3d_texture_get_level_width(dst_texture, i); height = wined3d_texture_get_level_height(dst_texture, i); depth = wined3d_texture_get_level_depth(dst_texture, i); wined3d_box_set(&box, 0, 0, width, height, 0, depth); for (j = 0; j < layer_count; ++j) { struct wined3d_resource *dst_resource = &dst_texture->resource; unsigned int dst_sub_resource_idx = j * dst_level_count + i; unsigned int src_sub_resource_idx = j * src_level_count + i + src_skip_levels; if (dst_resource->type == WINED3D_RTYPE_TEXTURE_2D) { struct wined3d_surface *dst_surface, *src_surface; dst_surface = dst_texture->sub_resources[dst_sub_resource_idx].u.surface; src_surface = src_texture->sub_resources[src_sub_resource_idx].u.surface; if (FAILED(wined3d_surface_blt(dst_surface, (const RECT *)&box, src_surface, (const RECT *)&box, 0, NULL, WINED3D_TEXF_POINT))) FIXME("Blit failed.\n"); } else if (dst_resource->type == WINED3D_RTYPE_TEXTURE_3D) { unsigned int update_w, update_h, update_d; unsigned int row_pitch, slice_pitch; struct wined3d_context *context; struct wined3d_bo_address addr; update_w = box.right - box.left; update_h = box.bottom - box.top; update_d = box.back - box.front; if (box.left || box.top || box.front) { FIXME("Source box %s not supported for %s resources.\n", debug_box(&box), debug_d3dresourcetype(dst_resource->type)); continue; } context = context_acquire(cs->device, NULL, 0); if (!wined3d_texture_load_location(src_texture, src_sub_resource_idx, context, src_texture->resource.map_binding)) { ERR("Failed to load source sub-resource into %s.\n", wined3d_debug_location(src_texture->resource.map_binding)); context_release(context); continue; } if (update_w == width && update_h == height && update_d == depth) { wined3d_texture_prepare_texture(dst_texture, context, FALSE); } else if (!wined3d_texture_load_location(dst_texture, dst_sub_resource_idx, context, WINED3D_LOCATION_TEXTURE_RGB)) { ERR("Failed to load destination sub-resource.\n"); context_release(context); continue; } wined3d_texture_get_memory(src_texture, src_sub_resource_idx, &addr, src_texture->resource.map_binding); wined3d_texture_get_pitch(src_texture, src_sub_resource_idx % src_texture->level_count, &row_pitch, &slice_pitch); wined3d_texture_bind_and_dirtify(dst_texture, context, FALSE); wined3d_texture_upload_data(dst_texture, dst_sub_resource_idx, context, &box, wined3d_const_bo_address(&addr), row_pitch, slice_pitch); wined3d_texture_validate_location(dst_texture, dst_sub_resource_idx, WINED3D_LOCATION_TEXTURE_RGB); wined3d_texture_invalidate_location(dst_texture, dst_sub_resource_idx, ~WINED3D_LOCATION_TEXTURE_RGB); context_release(context); } else { FIXME("Not implemented for %s resources.\n", debug_d3dresourcetype(dst_resource->type)); } } } wined3d_resource_release(&src_texture->resource); wined3d_resource_release(&dst_texture->resource); }

May 25, 2017

Re: [v5 PATCH 1/3] wined3d: Send texture updates through the command stream.

by Henri Verbeet

On 24 May 2017 at 16:08, Stefan Dösinger <stefandoesinger(a)gmail.com> wrote: > Am 2017-05-24 um 15:49 schrieb Masanori Kakura: >> + for (j = 0; j < layer_count; ++j) >> + { >> + wined3d_cs_emit_blt_sub_resource(cs, >> + &dst_texture->resource, j * dst_level_count + i, &box, >> + &src_texture->resource, j * src_level_count + i + src_skip_levels, &box, >> + 0, NULL, WINED3D_TEXF_POINT); >> + } > I don't like emitting new operations in the CS handler instead of doing > the actual operation. Maybe this can be avoided with some refactoring of > wined3d_cs_exec_blt_sub_resource? > Yeah, that's a consideration, although it probably shouldn't be the focus right now.

May 25, 2017

Re: [7/8] d3d11/tests: Add R9G9B9E5_SHAREDEXP to test_create_texture3d.

by Józef Kucia

On Thu, May 25, 2017 at 12:15 PM, Sven Hesse <drmccoy(a)drmccoy.de> wrote: > {DXGI_FORMAT_R8G8B8A8_UNORM, D3D11_BIND_DEPTH_STENCIL, FALSE, FALSE}, > {DXGI_FORMAT_D24_UNORM_S8_UINT, D3D11_BIND_RENDER_TARGET, FALSE, FALSE}, > {DXGI_FORMAT_D32_FLOAT, D3D11_BIND_RENDER_TARGET, FALSE, FALSE}, > + {DXGI_FORMAT_R9G9B9E5_SHAREDEXP, D3D10_BIND_SHADER_RESOURCE, TRUE, FALSE}, > + {DXGI_FORMAT_R9G9B9E5_SHAREDEXP, D3D10_BIND_RENDER_TARGET, FALSE, FALSE}, > + {DXGI_FORMAT_R9G9B9E5_SHAREDEXP, D3D10_BIND_DEPTH_STENCIL, FALSE, FALSE}, Please use D3D11 enum values.

May 25, 2017

Re: [6/8] d3d11/tests: Add R9G9B9E5_SHAREDEXP to test_create_texture2d.

by Józef Kucia

On Thu, May 25, 2017 at 12:15 PM, Sven Hesse <drmccoy(a)drmccoy.de> wrote: > {DXGI_FORMAT_D32_FLOAT, 1, D3D11_BIND_RENDER_TARGET, 0, FALSE, FALSE}, > {DXGI_FORMAT_D32_FLOAT, 1, D3D11_BIND_DEPTH_STENCIL, 0, TRUE, FALSE}, > + {DXGI_FORMAT_R9G9B9E5_SHAREDEXP, 1, D3D10_BIND_SHADER_RESOURCE, 0, TRUE, FALSE}, > + {DXGI_FORMAT_R9G9B9E5_SHAREDEXP, 1, D3D10_BIND_RENDER_TARGET, 0, FALSE, FALSE}, > + {DXGI_FORMAT_R9G9B9E5_SHAREDEXP, 1, D3D10_BIND_DEPTH_STENCIL, 0, FALSE, FALSE}, > }; Please use D3D11 enum values.

May 25, 2017