February 2024 - Wine-GitLab

[PATCH v3 0/4] MR5156: mshtml: Always use the event target dispex
by Brendan McGrath (＠redmcg) Feb. 28, 2024

Feb. 28, 2024

This MR ensures that document mode isn't updated on the wrong document when a DOMContentLoaded event occurs. This is done by always using the event target dispex (instead of the dispex associated with doc associated with the event listener). This fixes the launcher for Swords of Legends Online. -- v3: mshtml: Don't handle special case when doc != node->doc. https://gitlab.winehq.org/wine/wine/-/merge_requests/5156

3 8

Re: [PATCH v2 0/4] MR5161: d3drm: Implement Update and related functions
by Stefan Dösinger Feb. 28, 2024

Feb. 28, 2024

On Wed Feb 28 11:17:59 2024 +0000, Stefan Dösinger wrote: > There is room for future work, but nothing that needs to be in this > patchset IMHO: > 1) Check how multiple ForceUpdate / Clear calls influence the returned > list of rectangles > 2) Check which d3drmdevice interface is passed to the update callbacks Ah I missed your remarks on the cover letter regarding point 1. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_62913

1 0

Re: [PATCH v2 0/4] MR5161: d3drm: Implement Update and related functions
by Stefan Dösinger Feb. 28, 2024

Feb. 28, 2024

There is room for future work, but nothing that needs to be in this patchset IMHO: 1) Check how multiple ForceUpdate / Clear calls influence the returned list of rectangles 2) Check which d3drmdevice interface is passed to the update callbacks -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_62911

1 0

Re: [PATCH v2 0/4] MR5161: d3drm: Implement Update and related functions - approved
by Stefan Dösinger Feb. 28, 2024

Feb. 28, 2024

This merge request was approved by Stefan Dösinger. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161

1 0

Re: [PATCH v2 0/4] MR5161: d3drm: Implement Update and related functions
by Stefan Dösinger Feb. 28, 2024

Feb. 28, 2024

Stefan Dösinger (@stefan) commented about dlls/d3drm/tests/d3drm.c: > + hr = IDirect3DRMViewport2_ForceUpdate(viewport, vrect.left, vrect.top, vrect.right, vrect.bottom); > + todo_wine ok(hr == D3DRM_OK, "Cannot force update of viewport, hr %#lx.\n", hr); > + /* Update just to flush force updates */ > + hr = IDirect3DRMDevice3_Update(device3); > + ok(hr == D3DRM_OK, "Cannot update Direct3DRMDevice3, hr %#lx.\n", hr); > + > + /* Callbacks will receive (at least) one rectangle following a force update */ > + ctx.rect.x1 = ctx.rect.y1 = ctx.rect.x2 = ctx.rect.y2 = ~0; > + ctx.rect_count = -1; > + hr = IDirect3DRMViewport2_ForceUpdate(viewport, vrect.left, vrect.top, vrect.right, vrect.bottom); > + todo_wine ok(hr == D3DRM_OK, "Cannot force update of viewport, hr %#lx.\n", hr); > + hr = IDirect3DRMDevice3_AddUpdateCallback(device3, update_cb_modify_rect, NULL); > + todo_wine ok(hr == D3DRM_OK, "Cannot add update callback, hr %#lx.\n", hr); > + hr = IDirect3DRMDevice3_AddUpdateCallback(device3, update_cb_get_rect, &ctx); > + todo_wine ok(hr == D3DRM_OK, "Cannot add update callback, hr %#lx.\n", hr); > + hr = IDirect3DRMDevice3_Update(device3); Do I understand this right: ForceUpdate doesn't update itself, it just adds a dirty rectangle that the next Update() call will process? That would make sense, and since you add the callbacks after Viewport::ForceUpdate() but before Device::Update() it must be the case. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_62910

1 0

Re: [PATCH v2 0/4] MR5161: d3drm: Implement Update and related functions
by Stefan Dösinger Feb. 28, 2024

Feb. 28, 2024

Stefan Dösinger (@stefan) commented about dlls/d3drm/tests/d3drm.c: > + 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); > + hr = IDirect3DRM_CreateDeviceFromClipper(d3drm1, clipper, &driver, dev_width, dev_height, &device1); > + ok(hr == D3DRM_OK, "Cannot create IDirect3DRMDevice interface, hr %#lx.\n", hr); This is more a curiosity rather than something that needs to be addressed in this patch: Dies CreateDeviceFromClipper fail if the clipper has no window (but instead a cliplist or simply nothing)? I would expect it to fail, but otoh SetCooperativeLevel on a NULL HWND works in DDSCL_NORMAL I think. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_62909

1 0

Re: [PATCH v2 0/4] MR5161: d3drm: Implement Update and related functions
by Stefan Dösinger Feb. 28, 2024

Feb. 28, 2024

Stefan Dösinger (@stefan) commented about dlls/d3drm/tests/d3drm.c: > > IDirect3DRM_Release(d3drm1); > } > + > +struct update_rect_context > +{ > + int rect_count; > + D3DRECT rect; > +}; > + > +static void CDECL update_cb_modify_rect(IDirect3DRMDevice *device, void *arg, int rect_count, D3DRECT *update_rects) > +{ > + if (rect_count > 0) > + update_rects[0].x1 = 999999; > +} > +static void CDECL update_cb_get_rect(IDirect3DRMDevice *device, void *arg, int rect_count, D3DRECT *update_rects) Suggestion: Check if *device is indeed the IDirect3DRMDevice (QI IID_IDirect3DRMDevice from it and compare pointers). We have cases in plain ddraw where callbacks and getters return the interface passed in instead of what the header says and applications depend on it. IOW, if you register the callback with IDirect3DRMDevice3::AddUpdateCallback you may or may not get an IDirect3DRMDevice3 * here. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_62908

1 0

Re: [PATCH v2 0/4] MR5161: d3drm: Implement Update and related functions
by Stefan Dösinger Feb. 28, 2024

Feb. 28, 2024

Stefan Dösinger (@stefan) commented about dlls/d3drm/device.c: > } > > object->primary_surface = primary_surface; > - object->clipper = clipper; > - IDirectDrawClipper_AddRef(clipper); I am wondering if this breaks the tests (test_create_device_from_clipper1 checks the refcount), but the IDirectDrawSurface::SetClipper holds a reference itself. So we're probably fine with not holding a ref ourselves, especially if we don't use the clipper object anywhere. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_62907

1 0

[PATCH 0/1] MR5182: winevulkan: Remove unnecessary WINEVULKAN_QUIRK_ADJUST_MAX_IMAGE_COUNT quirk.
by Rémi Bernon Feb. 28, 2024

Feb. 28, 2024

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/5182

1 1

[PATCH 0/1] MR5178: winewayland.drv: set wayland app-id from the process name
by llyyr (＠llyyr) Feb. 28, 2024

Feb. 28, 2024

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56000 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5178

3 2