March 2024 - Wine-gitlab - list.winehq.org

Re: [PATCH v6 0/4] MR5161: d3drm: Implement Update and related functions
by Zebediah Figura (＠zfigura) 05 Mar '24

05 Mar '24

> Documentation for `ForceUpdate` states that "The system might update any region that is larger than the specified rectangle, including possibly the entire window". While native seems to use a sort of dirty-rectangle approach, for this MR, I am simply dirtying the entire surface. If someday someone did want to more-closely match the behavior of native, much can be learned from the rectangles passed to the update callbacks. Yeah, I can't say I'm thrilled about this. It doesn't seem like it should be that hard to implement more granular rects, at least for the cases covered here, and assuming that rects are indeed granular. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_63579

1 0

Re: [PATCH v6 0/4] MR5161: d3drm: Implement Update and related functions
by Zebediah Figura (＠zfigura) 05 Mar '24

05 Mar '24

Zebediah Figura (@zfigura) commented about dlls/d3drm/tests/d3drm.c: > + todo_wine ok(hr == D3DRM_OK, "Cannot force update of viewport, hr %#lx.\n", hr); > + hr = IDirect3DRMDevice_AddUpdateCallback(device1, update_cb_modify_rect, NULL); > + todo_wine ok(hr == D3DRM_OK, "Cannot add update callback, hr %#lx.\n", hr); > + hr = IDirect3DRMDevice_AddUpdateCallback(device1, update_cb_get_rect, &ctx); > + todo_wine ok(hr == D3DRM_OK, "Cannot add update callback, hr %#lx.\n", hr); > + hr = IDirect3DRMDevice_Update(device1); > + ok(hr == D3DRM_OK, "Cannot update Direct3DRMDevice, hr %#lx.\n", hr); > + hr = IDirect3DRMDevice_DeleteUpdateCallback(device1, update_cb_modify_rect, NULL); > + todo_wine ok(hr == D3DRM_OK, "Cannot delete update callback, hr %#lx.\n", hr); > + hr = IDirect3DRMDevice_DeleteUpdateCallback(device1, update_cb_get_rect, &ctx); > + todo_wine ok(hr == D3DRM_OK, "Cannot delete update callback, hr %#lx.\n", hr); > + todo_wine ok(ctx.rect_count == 1, "Got unexpected rect count %d, expected 1.\n", ctx.rect_count); > + todo_wine > + ok(ctx.rect.x1 == 999999 && ctx.rect.y1 <= vrect.top && > + ctx.rect.x2 >= vrect.right && ctx.rect.y2 >= vrect.bottom, > + "Got unexpected rect %s.\n", wine_dbgstr_rect((RECT *)&ctx.rect)); Any reason not to test the exact values? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_63578

1 0

Re: [PATCH v6 0/4] MR5161: d3drm: Implement Update and related functions
by Zebediah Figura (＠zfigura) 05 Mar '24

05 Mar '24

Zebediah Figura (@zfigura) commented about dlls/d3drm/device.c: > + RECT rt_rect = { 0, 0, device->width, device->height }; > + RECT ps_rect = rt_rect; > + > + ClientToScreen(device->window, (POINT *)&ps_rect.left); > + ClientToScreen(device->window, (POINT *)&ps_rect.right); > + > + TRACE("primary surface rect %s, render target rect %s\n", > + wine_dbgstr_rect(&ps_rect), wine_dbgstr_rect(&rt_rect)); > + > + hr = IDirectDrawSurface_Blt(device->primary_surface, &ps_rect, > + device->render_target, &rt_rect, DDBLT_WAIT, NULL); > + } > + > + device->needs_update = FALSE; > + } > + Can there be multiple updates? You mention the possibility of "at least" one update in your tests; should we be storing an array instead? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_63577

1 0

Re: [PATCH v6 0/4] MR5161: d3drm: Implement Update and related functions
by Zebediah Figura (＠zfigura) 05 Mar '24

05 Mar '24

Zebediah Figura (@zfigura) commented about dlls/d3drm/device.c: > device->width = desc.dwWidth; > device->height = desc.dwHeight; > > + device->needs_update = FALSE; > + The device is zero-initialized, so I don't think this hunk is necessary. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_63576

1 0

Re: [PATCH v6 0/4] MR5161: d3drm: Implement Update and related functions
by Zebediah Figura (＠zfigura) 05 Mar '24

05 Mar '24

Zebediah Figura (@zfigura) commented about dlls/d3drm/d3drm_private.h: > IDirect3DRM *d3drm; > IDirectDraw *ddraw; > IDirectDrawSurface *primary_surface, *render_target; > - IDirectDrawClipper *clipper; This should ideally be a separate patch. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_63575

1 0

Re: [PATCH v6 0/4] MR5161: d3drm: Implement Update and related functions
by Zebediah Figura (＠zfigura) 05 Mar '24

05 Mar '24

Zebediah Figura (@zfigura) commented about dlls/d3drm/viewport.c: > - FIXME("iface %p, x1 %lu, y1 %lu, x2 %lu, y2 %lu stub!\n", iface, x1, y1, x2, y2); > + struct d3drm_viewport *viewport = impl_from_IDirect3DRMViewport2(iface); > + D3DVIEWPORT vp = { sizeof(vp) }; > + HRESULT hr; > > - return E_NOTIMPL; > + TRACE("iface %p, x1 %lu, y1 %lu, x2 %lu, y2 %lu.\n", iface, x1, y1, x2, y2); > + > + if (!viewport->d3d_viewport) > + return D3DRMERR_BADOBJECT; > + > + if (FAILED(hr = IDirect3DViewport_GetViewport(viewport->d3d_viewport, &vp))) > + return hr; > + > + if (x1 > x2 || y1 > y2 || x1 < vp.dwX || y1 < vp.dwY || > + x2 > (vp.dwX + vp.dwWidth) || y2 > (vp.dwY + vp.dwHeight)) It'd be nice to rename these parameters to left/right/top/bottom. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_63574

1 0

Re: [PATCH v6 0/4] MR5161: d3drm: Implement Update and related functions
by Zebediah Figura (＠zfigura) 05 Mar '24

05 Mar '24

Zebediah Figura (@zfigura) commented about dlls/d3drm/tests/d3drm.c: > + struct update_surface_context ctx; > + D3DCOLOR ret_color = 0; > + DWORD clip_list_size; > + RGNDATA *clip_list; > + HWND window; > + HRESULT hr; > + > + window = create_window(); > + > + /* Set up device */ > + hr = DirectDrawCreateClipper(0, &clipper, NULL); > + ok(hr == DD_OK, "Cannot get IDirectDrawClipper interface, hr %#lx.\n", hr); > + hr = IDirectDrawClipper_SetHWnd(clipper, 0, window); > + ok(hr == DD_OK, "Cannot set HWnd to Clipper, hr %#lx.\n", hr); > + hr = Direct3DRMCreate(&d3drm1); > + ok(SUCCEEDED(hr), "Cannot create IDirect3DRM instance, hr %#lx.\n", hr); Not a big deal, but in the future I'd like to avoid this, and just always check the actual hr value. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_63572

1 0

Re: [PATCH v6 0/4] MR5161: d3drm: Implement Update and related functions
by Zebediah Figura (＠zfigura) 05 Mar '24

05 Mar '24

Zebediah Figura (@zfigura) commented about dlls/d3drm/tests/d3drm.c: > + > + /* Set color of a pixel on primary surface and on render target */ > + ClientToScreen(window, &client_pos); > + hr = set_surface_color(d3drm_primary, 320 + client_pos.x, 240 + client_pos.y, 0x00123456); > + if (FAILED(hr)) > + { > + win_skip("Cannot lock/unlock primary surface, hr %#lx, skipping tests\n", hr); > + goto cleanup; > + } > + ret_color = get_surface_color(d3drm_primary, 320 + client_pos.x, 240 + client_pos.y); > + if (!compare_color(ret_color, 0x00123456, 1)) > + { > + win_skip("Cannot set color of pixel on primary surface, color 0x%08lx, skipping tests\n", ret_color); > + goto cleanup; > + } > + hr = set_surface_color(surface, 320, 240, 0x000000ff); Where do these fail? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_63573

1 0

[PATCH 0/3] MR5237: Use futexes on macOS for thread-ID alerts.
by Marc-Aurel Zent (＠mzent) 05 Mar '24

05 Mar '24

This also bumps the minimum supported version of macOS to 10.12 to unconditionally assume the ulock syscalls are present. As discussed with @Gcenx this shouldn't be an issue, as the current minimum support version of 10.8 does not work anyways at the moment with only 10.10+ being useable and even then virtually no-one using wine on versions < 10.12 (and also being unsupported by the prebuilt binaries). Bumping to 10.12 would also have the side-benefit of allowing some cleanup of deprecated functions or legacy codepaths (like `mach_continuous_time` vs `mach_absolute_time` and probably much more). In my testing ulock futexes are about 2x faster for synchronization than kevents. Using the syscall wrappers here should provide protection against changing syscall numbers, and given that ulock is also directly used by libc++, the probability of an incompatible API change here is basically zero imo. By default ulock is also process-private, similar to the current linux implementation, cross-process synchronization would require darwin 19+ (macOS 10.15+) with `UL_COMPARE_AND_WAIT_SHARED`. The diff is a bit bigger than it actually is in effect, since https://gitlab.winehq.org/mzent/wine/-/commit/28a8a991c165f0d37dbf78ca3cdee… is only moving some code around and not actually changing anything. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5237

3 5

[PATCH 0/4] MR5228: Administrator tokens, part 2: Create Wine processes with a limited token.
by Zebediah Figura (＠zfigura) 05 Mar '24

05 Mar '24

Second half of <https://gitlab.winehq.org/wine/wine/-/merge_requests/5118>. This uses a different approach, setting the process token from within the process after it is created. This avoids the need to always relay through start.exe. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5228

2 5