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

Re: [PATCH 5/6] d3d10core/tests: Add test for aoffimmi modifier.
by Henri Verbeet 09 Mar '16

09 Mar '16

On 8 March 2016 at 17:46, Józef Kucia <jkucia(a)codeweavers.com> wrote: > Signed-off-by: Józef Kucia <jkucia(a)codeweavers.com> > --- > dlls/d3d10core/tests/device.c | 34 ++++++++++++++++++++++++++++++++++ > 1 file changed, 34 insertions(+) > This (and the equivalent d3d11 test) fails for me on Windows: device.c:4022: Test failed: Test 18: Got unexpected color 0x00000000 at (0, 0). device.c:4022: Test failed: Test 18: Got unexpected color 0x00000000 at (0, 1). device.c:4022: Test failed: Test 18: Got unexpected color 0x00000000 at (1, 0). device.c:4022: Test failed: Test 18: Got unexpected color 0x00000000 at (1, 1). device.c:4022: Test failed: Test 18: Got unexpected color 0x00000000 at (2, 0). device.c:4022: Test failed: Test 18: Got unexpected color 0x00000000 at (2, 1). device.c:4022: Test failed: Test 18: Got unexpected color 0x00000000 at (3, 0). device.c:4022: Test failed: Test 18: Got unexpected color 0x00000000 at (3, 1).

1 0

Re: [PATCH 2/6] wined3d: Extend shader_glsl_gen_sample_code() to support offsets.
by Henri Verbeet 09 Mar '16

09 Mar '16

On 8 March 2016 at 17:46, Józef Kucia <jkucia(a)codeweavers.com> wrote: > +static void shader_glsl_append_imm_ivec(struct wined3d_string_buffer *buffer, > + const int *values, unsigned int size) > +{ > + const char *fmt = "%#x"; > + char str[4][17] = {{0}}; I guess this is inspired by shader_glsl_append_imm_vec4(), but I think you can just append to the buffer here. > + if (1 > size || size > 4) I don't think "1 > size" is all that more readable than "!size". > + for (i = size - 1; i >= 0; --i) > + { > + sprintf(str[i], fmt, values[i]); > + fmt = "%#x, "; > + } If you use ", %#x" for the format you don't need the awkward reverse loop. > - if (flags != WINED3D_GLSL_SAMPLE_LOAD) > - ERR("Unexpected flags for texelFetch %#x.\n", flags & ~WINED3D_GLSL_SAMPLE_LOAD); > + static const DWORD texel_fetch_flags = WINED3D_GLSL_SAMPLE_LOAD | WINED3D_GLSL_SAMPLE_OFFSET; > + if (flags & ~texel_fetch_flags) > + ERR("Unexpected flags for texelFetch %#x.\n", flags & ~texel_fetch_flags); The original had this as well, of course, but "Unexpected flags %#x for texelFetch.\n" may be better.

1 0

Re: [PATCH v2 2/5] dxgi: Add feature level support.
by Henri Verbeet 09 Mar '16

09 Mar '16

On 8 March 2016 at 23:19, Matteo Bruni <mbruni(a)codeweavers.com> wrote: > @@ -214,7 +215,7 @@ static HRESULT STDMETHODCALLTYPE dxgi_adapter_CheckInterfaceSupport(IDXGIAdapter > return DXGI_ERROR_UNSUPPORTED; > } > > - if (FAILED(hr = dxgi_check_d3d10_support(adapter->parent, adapter))) > + if (FAILED(hr = dxgi_check_feature_level_support(adapter->parent, adapter, &feature_level, 1))) > return DXGI_ERROR_UNSUPPORTED; I don't think this does what you want it to do, > -HRESULT dxgi_check_d3d10_support(struct dxgi_factory *factory, struct dxgi_adapter *adapter) > +HRESULT dxgi_check_feature_level_support(struct dxgi_factory *factory, struct dxgi_adapter *adapter, > + const D3D_FEATURE_LEVEL *feature_levels, unsigned int level_count) ... > + D3D_FEATURE_LEVEL selected_feature_level = 0; ... > + return selected_feature_level; because this doesn't match the return type.

1 0

Re: [PATCH 1/5] wmasf: add stub dll
by Austin English 09 Mar '16

09 Mar '16

On Wed, Mar 9, 2016 at 12:31 AM, Austin English <austinenglish(a)gmail.com> wrote: > This patch series is for https://bugs.winehq.org/show_bug.cgi?id=39797 > > The bug subject is wmasf, but the uploaded log shows that there are a > few more dlls requested (api-ms-wine-core-*), so I went ahead and > added stubs for those while I was at it. > > -- > -Austin Sorry for the noise, gitconfig wasn't set up on the machine the patches were generated on, I'll resend tomorrow. -- -Austin

1 0

Re: [PATCH] d3dx9: IsParameterUsed stub should return TRUE.
by Henri Verbeet 08 Mar '16

08 Mar '16

On 7 March 2016 at 22:49, Matteo Bruni <matteo.mystral(a)gmail.com> wrote: > Yes, I guess returning TRUE is usually more likely to work. Of course Is that necessarily what you want though? It might be harder to debug something being slow because it's updating unused parameters than to debug something rendering incorrectly because it's not updating them. > a proper implementation would be even better (although it may be non > obvious to find out if a parameter is used, depending on what "used" > really means - it needs tests)... You always need tests, but a reasonable guess would be whether the parameter is referenced by the technique.

3 7

Metatrader 5 uses all CPU time
by Vyacheslav Napadovsky 08 Mar '16

08 Mar '16

Hello. I'm trying to launch Metatrader 5 in ubuntu with winehq-devel=1.9.5~ubuntu14.04.1 When I log in to my demo account the wineserver and terminal.exe (Metetrader 5 itself) start consume all available CPU. And if I'm trying to "Show all symbols" in "Market overview" then Metatrader UI just hangs. Here's last 10000 lines of 1.9GB log I dumped with WINEDEBUG=fixme-all,warn+all,+relay wine terminal.exe > terminal.log 2>&1 http://sendfile.su/1211848 (can't post it with pastebin.com, because it's over 500kB). Note, I killed process at the end with `killall terminal.exe` Moreover, when terminal.exe is running (without showing all symbols), `vmstat 1` shows that user space / system space consumes 50 / 50 % of CPU. And one more notice, if I run terminal.exe in a Virtual Box and assign this VM only one CPU core, than terminal.exe works fine consuming about 7% cpu, but with 2 cores it consumes 50%/50% with wineserver. On native Windows OS terminal.exe consumes less than 4% CPU with showing all symbols (I have 4 CPU cores on my notebook). Any clues where to dig next? -- Vyacheslav Napadovsky

1 0

wine dll loader
by Vyacheslav Napadovsky 08 Mar '16

08 Mar '16

Hello. I'm developing .dll plugin for thirdparty software. In Windows 8.0 all works fine (my plugin loads and unloads correctly), but in wine, I got DLL_PROCESS_ATTACH, then 7 DLL_THREAD_ATTACH at plugin loading stage and only 1 DLL_THREAD_DETACH at plugin unloading, i.e my plugin remains active (because no DLL_PROCESS_DETACH came in). Maybe that's because I spawn new thread (CreateThread) at DLL_PROCESS_ATTACH. Please, suggest ways to debug this issue. Regards, Vyacheslav Napadovsky

3 6

Re: [PATCH] opencl/tests: Add initial tests
by Henri Verbeet 08 Mar '16

08 Mar '16

On 8 March 2016 at 13:14, Detlef Riekenberg <wine.dev(a)web.de> wrote: > + * Copyright 2013 Detlef Riekenberg Is the year correct? > +INT WINAPI clGetPlatformIDs(UINT, PVOID*, UINT*); That doesn't look right. I also don't think anything in this test is particularly Windows specific.

1 0

Re: [PATCH] opencl/tests: Add initial tests
by Marvin 08 Mar '16

08 Mar '16

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=21276 Your paranoid android. === build (build) === Recreation of tests/Makefile failed

1 0

Re: user32: Do not block sending/posting WM_NOTIFY messages.
by Alexandre Julliard 08 Mar '16

08 Mar '16

Sebastian Lackner <sebastian(a)fds-team.de> writes: > @@ -11188,6 +11188,35 @@ static void test_quit_message(void) > ok_sequence(WmStopQuitSeq, "WmStopQuitSeq", FALSE); > } > > +static void test_notify_message(void) > +{ > + HWND hwnd; > + BOOL ret; > + > + hwnd = CreateWindowExA(0, "TestWindowClass", NULL, WS_OVERLAPPEDWINDOW, > + CW_USEDEFAULT, CW_USEDEFAULT, 300, 300, 0, NULL, NULL, 0); > + ok(hwnd != 0, "Failed to create window\n"); > + > + ret = SendNotifyMessageA(hwnd, WM_NOTIFY, 0x1234, 0xdeadbeef); > + ok(ret == TRUE, "SendNotifyMessageA failed with error %u\n", GetLastError()); > + ret = SendNotifyMessageW(hwnd, WM_NOTIFY, 0x1234, 0xdeadbeef); > + ok(ret == TRUE, "SendNotifyMessageW failed with error %u\n", GetLastError()); > + ret = SendMessageCallbackA(hwnd, WM_NOTIFY, 0x1234, 0xdeadbeef, NULL, 0); > + ok(ret == TRUE, "SendMessageCallbackA failed with error %u\n", GetLastError()); > + ret = SendMessageCallbackW(hwnd, WM_NOTIFY, 0x1234, 0xdeadbeef, NULL, 0); > + ok(ret == TRUE, "SendMessageCallbackW failed with error %u\n", GetLastError()); > + ret = PostMessageA(hwnd, WM_NOTIFY, 0x1234, 0xdeadbeef); > + ok(ret == TRUE, "PostMessageA failed with error %u\n", GetLastError()); > + ret = PostMessageW(hwnd, WM_NOTIFY, 0x1234, 0xdeadbeef); > + ok(ret == TRUE, "PostMessageW failed with error %u\n", GetLastError()); > + ret = PostThreadMessageA(GetCurrentThreadId(), WM_NOTIFY, 0x1234, 0xdeadbeef); > + ok(ret == TRUE, "PostThreadMessageA failed with error %u\n", GetLastError()); > + ret = PostThreadMessageW(GetCurrentThreadId(), WM_NOTIFY, 0x1234, 0xdeadbeef); > + ok(ret == TRUE, "PostThreadMessageW failed with error %u\n", GetLastError()); It would be interesting to test the received message contents too, also for the case of valid data. -- Alexandre Julliard julliard(a)winehq.org

1 0