April 2022 - Wine-devel - list.winehq.org

[PATCH 1/2] qedit/tests: Check the Sample Grabber's buffer during and after flushing.
by Gabriel Ivăncescu 04 Oct '22

04 Oct '22

Signed-off-by: Gabriel Ivăncescu <gabrielopcode(a)gmail.com> --- dlls/qedit/tests/samplegrabber.c | 234 +++++++++++++++++++++++++++++++ 1 file changed, 234 insertions(+) diff --git a/dlls/qedit/tests/samplegrabber.c b/dlls/qedit/tests/samplegrabber.c index 8e68e3e..e66180f 100644 --- a/dlls/qedit/tests/samplegrabber.c +++ b/dlls/qedit/tests/samplegrabber.c @@ -1036,6 +1036,239 @@ static void test_connect_pin(void) ok(!ref, "Got outstanding refcount %d.\n", ref); } +struct frame_thread_params +{ + IMemInputPin *sink; + IMediaSample *sample; + DWORD delay; +}; + +static DWORD WINAPI frame_thread(void *arg) +{ + struct frame_thread_params *params = arg; + HRESULT hr; + + if (params->delay) + { + if (winetest_debug > 1) trace("%04x: Sleeping %u ms.\n", GetCurrentThreadId(), params->delay); + Sleep(params->delay); + } + if (winetest_debug > 1) trace("%04x: Sending frame.\n", GetCurrentThreadId()); + hr = IMemInputPin_Receive(params->sink, params->sample); + if (winetest_debug > 1) trace("%04x: Returned %#x.\n", GetCurrentThreadId(), hr); + IMediaSample_Release(params->sample); + free(params); + return hr; +} + +static HANDLE send_frame_time(IMemInputPin *sink, REFERENCE_TIME start_time, unsigned char color, DWORD delay) +{ + struct frame_thread_params *params = malloc(sizeof(*params)); + IMemAllocator *allocator; + REFERENCE_TIME end_time; + IMediaSample *sample; + HANDLE thread; + HRESULT hr; + BYTE *data; + + hr = IMemInputPin_GetAllocator(sink, &allocator); + ok(hr == S_OK, "Got hr %#x.\n", hr); + + hr = IMemAllocator_GetBuffer(allocator, &sample, NULL, NULL, 0); + if (hr == VFW_E_NOT_COMMITTED) + { + IMemAllocator_Commit(allocator); + hr = IMemAllocator_GetBuffer(allocator, &sample, NULL, NULL, 0); + } + ok(hr == S_OK, "Got hr %#x.\n", hr); + + hr = IMediaSample_GetPointer(sample, &data); + ok(hr == S_OK, "Got hr %#x.\n", hr); + memset(data, 0x55, 32 * 16 * 2); + + hr = IMediaSample_SetActualDataLength(sample, 32 * 16 * 2); + ok(hr == S_OK, "Got hr %#x.\n", hr); + + start_time *= 10000000; + end_time = start_time + 10000000; + hr = IMediaSample_SetTime(sample, &start_time, &end_time); + ok(hr == S_OK, "Got hr %#x.\n", hr); + + params->sink = sink; + params->sample = sample; + params->delay = delay; + thread = CreateThread(NULL, 0, frame_thread, params, 0, NULL); + + IMemAllocator_Release(allocator); + return thread; +} + +static HANDLE send_frame(IMemInputPin *sink, DWORD delay) +{ + return send_frame_time(sink, 0, 0x55, delay); /* purple */ +} + +static HRESULT join_thread_(int line, HANDLE thread) +{ + DWORD ret; + ok_(__FILE__, line)(!WaitForSingleObject(thread, 1000), "Wait failed.\n"); + GetExitCodeThread(thread, &ret); + CloseHandle(thread); + return ret; +} +#define join_thread(a) join_thread_(__LINE__, a) + +static void test_buffer_flush(void) +{ + AM_MEDIA_TYPE req_mt = + { + .majortype = MEDIATYPE_Video, + .subtype = MEDIASUBTYPE_RGB565, + .formattype = FORMAT_VideoInfo, + .bTemporalCompression = TRUE, + }; + LONG buf[(32 * 16 * 2) / sizeof(LONG)], size = sizeof(buf); + IPin *sink, *source, *renderer_pin; + struct testfilter testsource; + ISampleGrabber *grabber; + IMediaControl *control; + IFilterGraph2 *graph; + IMemInputPin *input; + IBaseFilter *filter; + OAFilterState state; + IMediaFilter *mf; + HANDLE thread; + DWORD ticks; + unsigned i; + HRESULT hr; + ULONG ref; + + testfilter_init(&testsource); + CoCreateInstance(&CLSID_FilterGraph, NULL, CLSCTX_INPROC_SERVER, + &IID_IFilterGraph2, (void **)&graph); + CoCreateInstance(&CLSID_NullRenderer, NULL, CLSCTX_INPROC_SERVER, + &IID_IBaseFilter, (void **)&filter); + IFilterGraph2_AddFilter(graph, filter, L"sink"); + IBaseFilter_FindPin(filter, L"In", &renderer_pin); + IBaseFilter_Release(filter); + + filter = create_sample_grabber(); + IFilterGraph2_AddFilter(graph, &testsource.filter.IBaseFilter_iface, L"source"); + IFilterGraph2_AddFilter(graph, filter, L"sample grabber"); + IBaseFilter_FindPin(filter, L"In", &sink); + IBaseFilter_FindPin(filter, L"Out", &source); + IBaseFilter_QueryInterface(filter, &IID_ISampleGrabber, (void **)&grabber); + IFilterGraph2_QueryInterface(graph, &IID_IMediaControl, (void **)&control); + IPin_QueryInterface(sink, &IID_IMemInputPin, (void **)&input); + + ISampleGrabber_SetMediaType(grabber, &req_mt); + ISampleGrabber_SetBufferSamples(grabber, TRUE); + + testsource.sink_mt = &req_mt; + hr = IFilterGraph2_ConnectDirect(graph, &testsource.source.pin.IPin_iface, sink, &req_mt); + ok(hr == S_OK, "Got hr %#x.\n", hr); + hr = IFilterGraph2_ConnectDirect(graph, source, renderer_pin, &req_mt); + ok(hr == S_OK, "Got hr %#x.\n", hr); + IPin_Release(renderer_pin); + + IFilterGraph2_QueryInterface(graph, &IID_IMediaFilter, (void **)&mf); + IMediaFilter_SetSyncSource(mf, NULL); + IMediaFilter_Release(mf); + + hr = IMemInputPin_ReceiveCanBlock(input); + ok(hr == S_OK, "Got hr %#x.\n", hr); + + hr = ISampleGrabber_GetCurrentBuffer(grabber, &size, buf); + ok(hr == VFW_E_WRONG_STATE, "Got hr %#x.\n", hr); + + hr = IMediaControl_Pause(control); + ok(hr == S_FALSE, "Got hr %#x.\n", hr); + hr = IMediaControl_GetState(control, 0, &state); + ok(hr == VFW_S_STATE_INTERMEDIATE, "Got hr %#x.\n", hr); + + thread = send_frame(input, 0); + hr = IMediaControl_GetState(control, 1000, &state); + ok(hr == S_OK, "Got hr %#x.\n", hr); + ok(WaitForSingleObject(thread, 100) == WAIT_TIMEOUT, "Thread should block in Receive().\n"); + + for (i = 0; i < 3; i++) + { + ticks = GetTickCount(); + hr = ISampleGrabber_GetCurrentBuffer(grabber, &size, buf); + ticks = GetTickCount() - ticks; + ok(hr == S_OK, "Got hr %#x.\n", hr); + ok(ticks < 100, "Got %u ticks.\n", ticks); + ok(size == sizeof(buf), "Got size %d.\n", size); + } + + hr = IMediaControl_Stop(control); + ok(hr == S_OK, "Got hr %#x.\n", hr); + hr = join_thread(thread); + ok(hr == S_OK, "Got hr %#x.\n", hr); + hr = IMediaControl_GetState(control, 1000, &state); + ok(hr == S_OK, "Got hr %#x.\n", hr); + ok(state == State_Stopped, "Got state %d.\n", state); + hr = ISampleGrabber_GetCurrentBuffer(grabber, &size, buf); + ok(hr == S_OK, "Got hr %#x.\n", hr); + + hr = IMediaControl_Pause(control); + ok(hr == S_FALSE, "Got hr %#x.\n", hr); + hr = IMediaControl_GetState(control, 0, &state); + ok(hr == VFW_S_STATE_INTERMEDIATE, "Got hr %#x.\n", hr); + + thread = send_frame(input, 0); + hr = IMediaControl_GetState(control, 1000, &state); + ok(hr == S_OK, "Got hr %#x.\n", hr); + ok(WaitForSingleObject(thread, 100) == WAIT_TIMEOUT, "Thread should block in Receive().\n"); + + for (i = 0; i < 3; i++) + { + ticks = GetTickCount(); + hr = ISampleGrabber_GetCurrentBuffer(grabber, &size, buf); + ticks = GetTickCount() - ticks; + ok(hr == S_OK, "Got hr %#x.\n", hr); + ok(ticks < 100, "Got %u ticks.\n", ticks); + ok(size == sizeof(buf), "Got size %d.\n", size); + } + + IPin_BeginFlush(sink); + hr = join_thread(thread); + ok(hr == S_OK, "Got hr %#x.\n", hr); + hr = ISampleGrabber_GetCurrentBuffer(grabber, &size, buf); + ok(hr == S_OK, "Got hr %#x.\n", hr); + IPin_EndFlush(sink); + + hr = IMediaControl_GetState(control, 0, &state); + todo_wine ok(hr == VFW_S_STATE_INTERMEDIATE, "Got hr %#x.\n", hr); + + ticks = GetTickCount(); + thread = send_frame(input, 150); + hr = ISampleGrabber_GetCurrentBuffer(grabber, &size, buf); + ticks = GetTickCount() - ticks; + ok(hr == S_OK, "Got hr %#x.\n", hr); + ok(ticks < 100, "Got %u ticks.\n", ticks); + ok(size == sizeof(buf), "Got size %d.\n", size); + + hr = IMediaControl_GetState(control, 1000, &state); + ok(hr == S_OK, "Got hr %#x.\n", hr); + hr = IMediaControl_Stop(control); + ok(hr == S_OK, "Got hr %#x.\n", hr); + hr = join_thread(thread); + todo_wine ok(hr == S_OK, "Got hr %#x.\n", hr); + + IPin_Release(sink); + IPin_Release(source); + IMemInputPin_Release(input); + IMediaControl_Release(control); + ref = IFilterGraph2_Release(graph); + ok(!ref, "Got outstanding refcount %d.\n", ref); + ISampleGrabber_Release(grabber); + ref = IBaseFilter_Release(filter); + ok(!ref, "Got outstanding refcount %d.\n", ref); + ref = IBaseFilter_Release(&testsource.filter.IBaseFilter_iface); + ok(!ref, "Got outstanding refcount %d.\n", ref); +} + START_TEST(samplegrabber) { IBaseFilter *filter; @@ -1059,6 +1292,7 @@ START_TEST(samplegrabber) test_aggregation(); test_media_types(); test_connect_pin(); + test_buffer_flush(); CoUninitialize(); } -- 2.21.0

5 7

Access to graphics memory mappings on upcoming WOW64 implementation
by Derek Lesho 28 Jul '22

28 Jul '22

Hi All, In the wake of the new WOW64 implementation (recent explanation [1]), there has been discussion in informal channels about how to we are going to handle pointers to mapped graphics resource memory which we receive from the graphics API, as the possibility exists that it will fall outside of the 32-bit address space. Over time, a few creative solutions have been proposed and discussed, with a common theme being that we need changes in either the kernel or the graphics drivers to do this properly. As we already know the requirements for a solution to this problem, I think it would be responsible to hash this out now and then work with the relevant project maintainers earlier as to avoid blocking work on the wine side too long and to possibly allow more users to test the new path earlier. The solutions which I've seen laid out so far: - Use the mremap(2) interface, allowing us to duplicate the mapping we receive into the 32-bit address space. This solution would match what is already done for Crossover Mac's 32on64 support using Mac's mach_vm_remap functionality [2]. However, right now it is not possible to use the MREMAP_DONTUNMAP flag with mappings that aren't private and anonymous, which rules out there use on mapped FDs from libdrm. Due to this, a kernel change would be necessary. Pro: A uniform solution across all APIs, which could help in the future with any unforeseen need to access host-allocated memory in 32-bit windows code. Cons: Requires a kernel change, which of all the options may take the longest to get up-streamed and in the hands of users. - Work with Khronos to introduce extensions into the relevant APIs enabling us to tell drivers where in the address space we want resources mapped. Pro: Wouldn't require going around the backs of the driver, resulting in a more hardened solution. (Out there, but what if a creative driver returns a mapping without read or write permission and handles accesses through a page fault handler?) Cons: The extension would have to be implemented by each individual vendor for every relevant API. This would implicitly drop support for those with cards whose graphics drivers are no longer being updated. - Hook the driver's mmap call when we invoke memory mappings function, overriding the address to something in the 32-bit address space. Pro: Unlike the other solutions, this wouldn't require any changes to other projects, and shares the advantage of the first solution. Cons: Susceptible to breakage if the driver uses their own mapping mechanism separate from mmap. (Custom IOCTL, CPU driver returning something from the heap) 1: https://www.winehq.org/pipermail/wine-devel/2022-April/213677.html 2: https://www.codeweavers.com/crossover/source - see function `remap_memory` in `wine/dlls/winemac.drv/opengl.c`

10 15

[PATCH] comctl32: Add partial support for LVM_SETBKIMAGE.
by Dmitry Timoshkov 28 Jun '22

28 Jun '22

Signed-off-by: Dmitry Timoshkov <dmitry(a)baikal.ru> --- dlls/comctl32/listview.c | 65 ++++++++++++++++++++++++++++++++++++---- 1 file changed, 59 insertions(+), 6 deletions(-) diff --git a/dlls/comctl32/listview.c b/dlls/comctl32/listview.c index 730bf4aaddd..3ca76c2ef05 100644 --- a/dlls/comctl32/listview.c +++ b/dlls/comctl32/listview.c @@ -91,7 +91,7 @@ * * Messages: * -- LVM_ENABLEGROUPVIEW - * -- LVM_GETBKIMAGE, LVM_SETBKIMAGE + * -- LVM_GETBKIMAGE * -- LVM_GETGROUPINFO, LVM_SETGROUPINFO * -- LVM_GETGROUPMETRICS, LVM_SETGROUPMETRICS * -- LVM_GETINSERTMARK, LVM_SETINSERTMARK @@ -297,6 +297,7 @@ typedef struct tagLISTVIEW_INFO COLORREF clrBk; COLORREF clrText; COLORREF clrTextBk; + HBITMAP hBkBitmap; /* font */ HFONT hDefaultFont; @@ -4567,11 +4568,30 @@ static INT LISTVIEW_GetTopIndex(const LISTVIEW_INFO *infoPtr) */ static inline BOOL LISTVIEW_FillBkgnd(const LISTVIEW_INFO *infoPtr, HDC hdc, const RECT *lprcBox) { - if (!infoPtr->hBkBrush) return FALSE; + if (infoPtr->hBkBitmap) + { + HDC hdc_src = CreateCompatibleDC(hdc); + + TRACE("(hdc=%p, lprcBox=%s, hBkBitmap=%p)\n", hdc, wine_dbgstr_rect(lprcBox), infoPtr->hBkBitmap); + + SelectObject(hdc_src, infoPtr->hBkBitmap); + BitBlt(hdc, lprcBox->left, lprcBox->top, + lprcBox->right - lprcBox->left, + lprcBox->bottom - lprcBox->top, + hdc_src, lprcBox->left, lprcBox->top, SRCCOPY); + + DeleteDC(hdc_src); - TRACE("(hdc=%p, lprcBox=%s, hBkBrush=%p)\n", hdc, wine_dbgstr_rect(lprcBox), infoPtr->hBkBrush); + return TRUE; + } + else if (infoPtr->hBkBrush) + { + TRACE("(hdc=%p, lprcBox=%s, hBkBrush=%p)\n", hdc, wine_dbgstr_rect(lprcBox), infoPtr->hBkBrush); - return FillRect(hdc, lprcBox, infoPtr->hBkBrush); + return FillRect(hdc, lprcBox, infoPtr->hBkBrush); + } + + return FALSE; } /* Draw main item or subitem */ @@ -8028,7 +8048,37 @@ static BOOL LISTVIEW_SetBkColor(LISTVIEW_INFO *infoPtr, COLORREF color) return TRUE; } -/* LISTVIEW_SetBkImage */ +static BOOL LISTVIEW_SetBkImage(LISTVIEW_INFO *infoPtr, const LVBKIMAGEW *image, BOOL isW) +{ + TRACE("%08lx,%p,%p,%u,%d,%d\n", image->ulFlags, image->hbm, image->pszImage, + image->cchImageMax, image->xOffsetPercent, image->yOffsetPercent); + + if (image->ulFlags & ~LVBKIF_SOURCE_MASK) + FIXME("not supported flags %08lx\n", image->ulFlags & ~LVBKIF_SOURCE_MASK); + + if (image->xOffsetPercent || image->yOffsetPercent) + FIXME("not supported offset %d,%d\n", image->xOffsetPercent, image->yOffsetPercent); + + switch (image->ulFlags & LVBKIF_SOURCE_MASK) + { + case LVBKIF_SOURCE_NONE: + if (infoPtr->hBkBitmap) DeleteObject(infoPtr->hBkBitmap); + infoPtr->hBkBitmap = 0; + return TRUE; + + case LVBKIF_SOURCE_HBITMAP: + if (infoPtr->hBkBitmap) DeleteObject(infoPtr->hBkBitmap); + infoPtr->hBkBitmap = image->hbm; + InvalidateRect(infoPtr->hwndSelf, NULL, TRUE); + return TRUE; + + case LVBKIF_SOURCE_URL: + FIXME("LVBKIF_SOURCE_URL: %s\n", isW ? debugstr_w(image->pszImage) : debugstr_a((LPCSTR)image->pszImage)); + break; + } + + return FALSE; +} /*** Helper for {Insert,Set}ColumnT *only* */ static void column_fill_hditem(const LISTVIEW_INFO *infoPtr, HDITEMW *lphdi, INT nColumn, @@ -10406,6 +10456,7 @@ static LRESULT LISTVIEW_NCDestroy(LISTVIEW_INFO *infoPtr) infoPtr->hFont = 0; if (infoPtr->hDefaultFont) DeleteObject(infoPtr->hDefaultFont); if (infoPtr->clrBk != CLR_NONE) DeleteObject(infoPtr->hBkBrush); + if (infoPtr->hBkBitmap) DeleteObject(infoPtr->hBkBitmap); SetWindowLongPtrW(infoPtr->hwndSelf, 0, 0); @@ -11554,7 +11605,9 @@ LISTVIEW_WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam) case LVM_SETBKCOLOR: return LISTVIEW_SetBkColor(infoPtr, (COLORREF)lParam); - /* case LVM_SETBKIMAGE: */ + case LVM_SETBKIMAGEA: + case LVM_SETBKIMAGEW: + return LISTVIEW_SetBkImage(infoPtr, (LVBKIMAGEW *)lParam, uMsg == LVM_SETBKIMAGEW); case LVM_SETCALLBACKMASK: infoPtr->uCallbackMask = (UINT)wParam; -- 2.35.3

2 12

[PATCH v4 1/8] server: Actually set initial status in set_async_direct_result handler.
by Jinoh Kang 19 Jun '22

19 Jun '22

Commit 15483b1a126 (server: Allow calling async_handoff() with status code STATUS_ALERTED., 2022-02-10) introduced the set_async_direct_result handler which calls async_set_initial_status(). However, the async_set_initial_status() call does nothing since async->terminated is set, leaving the async in a confusing state (unknown_status = 1 but pending/completed). So far, this issue is unlikely to have been a problem in practice for the following reasons: 1. async_set_initial_status() would have unset unknown_status, but it remains set instead. This is usually not a problem, since unknown_status is usually ever read by code paths effectively unreachable for non-device (e.g. socket) asyncs. It would still potentially allow set_async_direct_result to be called multiple times, but it wouldn't actually happen in practice unless something goes wrong. 2. async_set_initial_status() would have set initial_status; however, it is left with the default value STATUS_PENDING. If the actual status is something other than that, the handler closes the wait handle and async_satisfied (the only realconsumer of initial_status) would never be called anyway. For reasons above, this issue is not effectively observable or testable. Nonetheless, the current code does leave the async object in an inconsistent state. Fix this by removing the !async->terminated check in async_set_initial_status(). Signed-off-by: Jinoh Kang <jinoh.kang.kr(a)gmail.com> --- Notes: v1 -> v2: no changes v2 -> v3: no changes v3 -> v4: reuse async_set_initial_status() per feedback server/async.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/server/async.c b/server/async.c index 7d0ff10f7a4..e92d4583c1e 100644 --- a/server/async.c +++ b/server/async.c @@ -303,11 +303,8 @@ struct async *create_async( struct fd *fd, struct thread *thread, const async_da void async_set_initial_status( struct async *async, unsigned int status ) { assert( async->unknown_status ); - if (!async->terminated) - { - async->initial_status = status; - async->unknown_status = 0; - } + async->initial_status = status; + async->unknown_status = 0; } void set_async_pending( struct async *async ) -- 2.34.1

3 10

[PATCH v2] ntdll: Avoid reqeuests with null pointer but invalid size.
by Bernhard Übelacker 30 May '22

30 May '22

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51770 Signed-off-by: Bernhard Übelacker <bernhardu(a)mailbox.org> --- v1: https://www.winehq.org/pipermail/wine-devel/2021-December/202913.html https://www.winehq.org/pipermail/wine-devel/2022-April/213866.html v2: Validate pointer before calling wine_server_add_data. --- dlls/kernel32/tests/volume.c | 16 ++++++++++++++++ dlls/ntdll/unix/file.c | 4 +++- 2 files changed, 19 insertions(+), 1 deletion(-) diff --git a/dlls/kernel32/tests/volume.c b/dlls/kernel32/tests/volume.c index 9166cf228d9..4bee4207a37 100644 --- a/dlls/kernel32/tests/volume.c +++ b/dlls/kernel32/tests/volume.c @@ -618,6 +618,7 @@ static void test_disk_query_property(void) STORAGE_PROPERTY_QUERY query = {0}; STORAGE_DESCRIPTOR_HEADER header = {0}; STORAGE_DEVICE_DESCRIPTOR descriptor = {0}; + STORAGE_DEVICE_NUMBER device_number = {0}; HANDLE handle; DWORD error; DWORD size; @@ -654,6 +655,21 @@ static void test_disk_query_property(void) ok(descriptor.Version == sizeof(descriptor), "got descriptor.Version %ld\n", descriptor.Version); ok(descriptor.Size >= sizeof(descriptor), "got descriptor.Size %ld\n", descriptor.Size); + SetLastError(0xdeadbeef); + ret = DeviceIoControl(handle, IOCTL_STORAGE_GET_DEVICE_NUMBER, NULL, 0, &device_number, sizeof(device_number), &size, NULL); + error = GetLastError(); + ok(ret, "expect ret %#x, got %#x\n", TRUE, ret); + ok(error == 0xdeadbeef, "expect err %#x, got err %#x\n", 0xdeadbeef, error); + ok(size == sizeof(device_number), "got size %d\n", size); + + /* unclean call with valid in_buffer=NULL but incorrect in_size=4 */ + SetLastError(0xdeadbeef); + ret = DeviceIoControl(handle, IOCTL_STORAGE_GET_DEVICE_NUMBER, NULL, 4, &device_number, sizeof(device_number), &size, NULL); + error = GetLastError(); + ok(ret, "expect ret %#x, got %#x\n", TRUE, ret); + ok(error == 0xdeadbeef, "expect err %#x, got err %#x\n", 0xdeadbeef, error); + ok(size == sizeof(device_number), "got size %d\n", size); + CloseHandle(handle); } diff --git a/dlls/ntdll/unix/file.c b/dlls/ntdll/unix/file.c index cc8bf0c6e82..92b67280500 100644 --- a/dlls/ntdll/unix/file.c +++ b/dlls/ntdll/unix/file.c @@ -4893,7 +4893,7 @@ static NTSTATUS server_ioctl_file( HANDLE handle, HANDLE event, { req->code = code; req->async = server_async( handle, &async->io, event, apc, apc_context, iosb_client_ptr(io) ); - wine_server_add_data( req, in_buffer, in_size ); + if (in_buffer) wine_server_add_data( req, in_buffer, in_size ); if ((code & 3) != METHOD_BUFFERED) wine_server_add_data( req, out_buffer, out_size ); wine_server_set_reply( req, out_buffer, out_size ); status = virtual_locked_server_call( req ); @@ -4913,6 +4913,8 @@ static NTSTATUS server_ioctl_file( HANDLE handle, HANDLE event, if (status != STATUS_PENDING) free( async ); + if (wait_handle && status == STATUS_ACCESS_VIOLATION) + ERR("Sending request failed but wait requested. Expect the application to hang.\n"); if (wait_handle) status = wait_async( wait_handle, (options & FILE_SYNCHRONOUS_IO_ALERT) ); return status; } -- 2.35.1

2 2

TestBot News
by Francois Gouget 13 May '22

13 May '22

Hi, This last week-end I updated 5 of the test machines, impacting 29 test configurations. Here's the rundown: * w1064* w1064 is now called w1064v2009. And w1064 and all the derived snapshots are now running on Windows 10 21H2 (upgraded through Windows Update). * w10pro64v2004 This snapshot used to have some specific failures most likely because Windows Update was still installing already downloaded updates when I initially took the snapshot (see bug 52560). So I let the VM quiet down and retook the snapshot. That seems to have improved things. I'll know for sure in a few days. * w10pro64_* w10pro64 had the same issue as w10pro64v2004, plus I needed to install some more languages which requires un-metering the network at which time Windows Update kicks in... So I applied all updates and retook this snapshot. It's now on the latest 21H1; Windows did not offer installing 21H2 for some reason. It's just as well, this way test.winehq.org can separate the results from this VM with all its locale tests, from those of the w1064 VM which is more about past Windows versions and other configuration options. Then I let the TestBot recreate all the snapshots for the locale tests. Windows has a bunch of locales: formats, display language, system locale, keyboard layout, country. The old snapshots mostly had the display language right but sometimes the other locales were still stuck on English. The new snapshots are all consistent on that front (whenever possible see below). In the process I lost w10pro64_pt_PT which the new SetWinLocale have trouble with (yet this works on my test VM so I blame the latest 21H1 updates). I also wanted to add a 'mixed locales' test configuration but the scripts failed this one too. I'll investigate and get those online later on. * w10pro64_hi_u8 Before Windows 10 it was impossible to set the the system locale to some values. For instance it was impossible to set it to Hindi. So the w10pro64_hi still has English as its system locale unlike the other locale test configurations. Windows 10 lifted this restriction but this comes with two caveats: - Setting the system locale to values like Hindi is possible but it requires setting the codepage to UTF-8. - This is considered beta and requires checking an extra box in the GUI. w10pro64_hi_u8 is one such configuration: Hindi through and through with UTF-8 as the codepage. And based on the test results I think they were not kidding with the 'beta' aspect: I count at least 11 tests with UTF-8-specific failures on Windows. Some of these may be because of issues in the test but I'm pretty sure some are Windows bugs we will have to work around. I would have liked to add another UTF-8 test configuration if only to tweeze out Hindi-specific issues from the UTF-8 ones. I planned to use en-EA for that because it's an all English UTF-8-only locale which could be nice in case there are any error message that need reading... But that's another locale that requires a SetWineLocale tweak. * cw-gtx560 This is one of the two not-really-TestBot machines with real graphics cards. I added a Windows 10 21H2 snapshot. Note that again Windows did not want to update it to 21H2 so I used Windows10Upgrade9252.exe to force it. As far as I know the Nvidia driver is unchanged (391.35 iirc). That machine's other snapshots are unchanged. * cw-rx460 I also added a Windows 10 21H2 snapshot (Windows10Upgrade9252.exe again, the other snapshots are unchanged). Windows was suggesting I upgrade the GPU driver so I upgraded to the latest Adrenalin 22.4.1 driver. In the past I had trouble with some of the AMD drivers where it would either interfere with the clipboard (causing tests to fail), or crash entirely (causing WineTest to fail entirely). So consider this new driver to be on probation. * w7u* I moved this VM from one host to another on 2022-03-14 which is when I found issues with the new LibvirtTool and SetWinLocale scripts so I ended up having to create most snapshots by hand :-( I restored it again from backup to test the corrected scripts and this time all went well. The last move coincided with some new failures in mf:mf (2qxl only), user32:sysparams and user32:win (2qxl only). It's possible the 2qxl issues are because the VM is powered on for each test instead of starting from a live snapshot: I suspect Windows 7 did not correctly handle the multi-monitor setup when restored from a live snapshot. This will require some more investigation... -- Francois Gouget <fgouget(a)codeweavers.com>

5 16

[PATCH 0/1] MR16: wined3d: Reduce the size of staging BO's for texture uploads.
by Jan Sikorski (＠jsikorski) 13 May '22

13 May '22

Signed-off-by: Jan Sikorski <jsikorski(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/16

3 2

[PATCH] combase: Execute local server for correct architecture in a WoW64 setup.
by Dmitry Timoshkov 13 May '22

13 May '22

Based on implementation of create_surrogate_server(). This patch makes 64-bit application work with its own shipped 32-bit COM server. Signed-off-by: Dmitry Timoshkov <dmitry(a)baikal.ru> --- dlls/combase/rpc.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/dlls/combase/rpc.c b/dlls/combase/rpc.c index 80760ca37e7..53cb32e08e2 100644 --- a/dlls/combase/rpc.c +++ b/dlls/combase/rpc.c @@ -478,6 +478,9 @@ static HRESULT create_server(REFCLSID rclsid, HANDLE *process) { static const WCHAR embeddingW[] = L" -Embedding"; HKEY key; + int arch = (sizeof(void *) > sizeof(int)) ? 64 : 32; + REGSAM opposite = (arch == 64) ? KEY_WOW64_32KEY : KEY_WOW64_64KEY; + BOOL is_wow64 = FALSE; HRESULT hr; WCHAR command[MAX_PATH + ARRAY_SIZE(embeddingW)]; DWORD size = (MAX_PATH+1) * sizeof(WCHAR); @@ -485,7 +488,11 @@ static HRESULT create_server(REFCLSID rclsid, HANDLE *process) PROCESS_INFORMATION pinfo; LONG ret; + TRACE("Attempting to start server for %s\n", debugstr_guid(rclsid)); + hr = open_key_for_clsid(rclsid, L"LocalServer32", KEY_READ, &key); + if (FAILED(hr) && (arch == 64 || (IsWow64Process(GetCurrentProcess(), &is_wow64) && is_wow64))) + hr = open_key_for_clsid(rclsid, L"LocalServer32", opposite | KEY_READ, &key); if (FAILED(hr)) { ERR("class %s not registered\n", debugstr_guid(rclsid)); @@ -511,7 +518,19 @@ static HRESULT create_server(REFCLSID rclsid, HANDLE *process) /* FIXME: Win2003 supports a ServerExecutable value that is passed into * CreateProcess */ - if (!CreateProcessW(NULL, command, NULL, NULL, FALSE, DETACHED_PROCESS, NULL, NULL, &sinfo, &pinfo)) + if (is_wow64 && arch == 64) + { + void *cookie; + Wow64DisableWow64FsRedirection(&cookie); + if (!CreateProcessW(NULL, command, NULL, NULL, FALSE, DETACHED_PROCESS, NULL, NULL, &sinfo, &pinfo)) + { + WARN("failed to run local server %s\n", debugstr_w(command)); + hr = HRESULT_FROM_WIN32(GetLastError()); + } + Wow64RevertWow64FsRedirection(cookie); + if (FAILED(hr)) return hr; + } + else if (!CreateProcessW(NULL, command, NULL, NULL, FALSE, DETACHED_PROCESS, NULL, NULL, &sinfo, &pinfo)) { WARN("failed to run local server %s\n", debugstr_w(command)); return HRESULT_FROM_WIN32(GetLastError()); -- 2.35.3

2 2

Envisioned Gitlab workflow
by Alexandre Julliard 11 May '22

11 May '22

Folks, Here's a description of the envisioned workflow for using Gitlab as the primary platform for Wine development, should we decide to adopt it. This will probably evolve as we experiment and find out what works or doesn't work for us. All feedback/suggestions are welcome. 1. All patch series are submitted as Merge Requests, so that the proper information can be captured. The usual rules apply (small patches, small number of patches per MR, sign-off by submitter). There are various methods available for creating merge requests: - using the web interface - directly when pushing: git push -o merge_request.create cf. https://docs.gitlab.com/ee/user/project/push_options.html - from the command line, eg. 'glab mr create' cf. https://glab.readthedocs.io/en/latest/mr/create.html - by email cf. https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_reque… 2. The merge request will run through the CI pipeline, ideally including a testbot run (not implemented yet). 3. The patches of the merge request will be forwarded to wine-devel by the mail gateway, for people who prefer to use their existing email tools to manage patches. 4. Reviewers will be automatically assigned to the merge request based on the MAINTAINERS file (not implemented yet). Reviewers can also be assigned manually. People assigned as reviewers should receive a notification from gitlab. 5. When someone starts reviewing a patch, they can optionally assign the patch to themselves, so that the submitter is aware that someone is working on their patch. 6. Feedback on patches can be sent by replying to the wine-devel email, or by adding a comment on gitlab. The mail gateway will bridge things so that all comments are reflected both on gitlab and on wine-devel. Note: if you subscribe to gitlab notifications (recommended) currently you'll get many duplicate emails. There are mail headers that can be used for filtering, but we may want to handle this differently, suggestions are welcome. 7. If there are comments, the submitter can address them and update the merge request by pushing to the MR branch. The mail gateway will send the new version of the patches to wine-devel (except for trivial changes) for further review. 8. Once a reviewer approves a merge request, they should mark it approved in gitlab. The idea is that this will replace the existing "send a signoff by email" mechanism. Note that an approval applies to the whole merge request, not to individual patches. This should be one more reason to keep patch series small. Approvals can be sent by: - using the approve button on the web interface - replying to a gitlab notification with "/approve" (note: replying to a wine-devel mail won't work, it needs the magic gitlab headers) cf. https://docs.gitlab.com/ee/user/project/quick_actions.html - from the command line, eg. 'glab mr approve' cf. https://glab.readthedocs.io/en/latest/mr/approve.html 9. Once a merge request has been approved by all reviewers, I'll merge it into my tree, do a full testbot run to make sure it doesn't break anything, then push the results and mark the merge request as 'merged'. 10. If a merge request is no longer relevant, the submitter should close it. We may want to add an auto-close process for stale merge requests at some point. -- Alexandre Julliard julliard(a)winehq.org

6 9

[PATCH 0/1] MR4: wined3d: Don't transition GENERAL layouts for blits.
by Stefan Dösinger 06 May '22

06 May '22

On Radeon GPUs VK_IMAGE_LAYOUT_GENERAL images don't use Delta Color Compression, but SRC/DST optimal images do. Transitioning from GENERAL to SRC/DST causes a big performance hit. As a next step we should try harder to avoid VK_IMAGE_LAYOUT_GENERAL. Signed-off-by: Stefan Dösinger <stefan(a)codeweavers.com> --- This improves Rocket League from 50fps to 67fps when it is GPU limited. Using VK_IMAGE_LAYOUT_COLOR_ATTACHMENT_OPTIMAL instead of GENERAL further improves it to 80 fps. Switching from COLOR_ATTACHMENT_OPTIMAL to SRC/DST optimal seems cheap (it just stays compressed), but first we need logic to transition BIND_RENDER_TARGET | BIND_SHADER_RESOURCE textures between COLOR_ATTACHMENT_OPTIMAL and SHADER_READ_ONLY_OPTIMAL. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4

2 2