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

[PATCH v5 0/4] MR5161: d3drm: Implement Update and related functions
by Jeffrey Smith (＠whydoubt) March 4, 2024

March 4, 2024

Regarding dirty rectangles:<br> 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. -- v5: d3drm: Add support for device update callbacks. d3drm: Blit render target to primary surface on device update. d3drm: Implement parameter validation for viewport force update. d3drm/tests: Add tests for Direct3DRMDevice Update https://gitlab.winehq.org/wine/wine/-/merge_requests/5161

2 4

[PATCH v2 0/1] MR5083: server: Try to retrieve the unix name on handles created from file descriptors.
by Gabriel Ivăncescu March 4, 2024

March 4, 2024

Useful with unix integration of redirected standard handles. Simple testcase: ```c #include <windows.h> #include <stdio.h> int main(int argc, char **argv) { char buf[4096] = {0}; FILE_NAME_INFO *name_info = (FILE_NAME_INFO*)buf; if (!GetFileInformationByHandleEx(GetStdHandle(STD_OUTPUT_HANDLE), FileNameInfo, name_info, sizeof(buf))) { fprintf(stderr, "GetFileInformationByHandleEx failed %08lx\n", GetLastError()); return 1; } WriteFile(GetStdHandle(STD_ERROR_HANDLE), name_info->FileName, name_info->FileNameLength, NULL, NULL); return 0; } ``` On Windows: ``` test.exe > C:\Temp\test.txt ``` Output: ``` \Temp\test.txt ``` On wine: ``` wine test.exe > /tmp/wine/testprefix/drive_c/Temp/test.txt ``` Upstream output: ``` GetFileInformationByHandleEx failed 00000006 ``` With this MR: ``` \Temp\test.txt ``` -- v2: server: Try to retrieve the unix name on handles created from file https://gitlab.winehq.org/wine/wine/-/merge_requests/5083

2 5

Re: [PATCH v5 0/1] MR5157: evr/dshow: List NV12 as supported, improve warnings - approved
by Zebediah Figura (＠zfigura) March 4, 2024

March 4, 2024

This merge request was approved by Zebediah Figura. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5157

1 0

[PATCH v3 0/3] MR5195: ws2_32: Implement TCP_KEEPALIVE, TCP_KEEPCNT and TCP_KEEPINTVL socket options
by Florian Will (＠w-flo) March 4, 2024

March 4, 2024

Application "ZusiDisplay" wants to set these socket options. setsockopt() currently returns an error on wine, which prevents the application from working correctly. I'm not really sure if I'm using the IOCTL_AFD_WINE_SET/GET_* correctly. Maybe the new ones should have different "function" numbers and be sorted below the one for TCP_NODELAY? Also, not sure if anything needs to be done in unix/socket.c for portability. Are these TCP_KEEPIDLE etc. constants defined on all OSes supported by wine? If not, how should I handle this? ZusiDisplay seems to work fine if the setsockopt() call is ignored in wine, without returning an error. So if this merge request is not that great, I'd be happy to send a merge request to ignore the call instead. -- v3: ws2_32: Implement TCP_KEEP{ALIVE,CNT,INTVL} options. ws2_32/tests: Test TCP_KEEP{ALIVE,CNT,INTVL} options. include: Add TCP_KEEPCNT and TCP_KEEPINTVL definitions. https://gitlab.winehq.org/wine/wine/-/merge_requests/5195

4 10

Re: [PATCH v4 0/1] MR3422: ddraw tests for Pick and GetPickRecords
by Stefan Dösinger March 4, 2024

March 4, 2024

My memory on this patchset is a bit rusty, but largely this looks good. I'll give it a try on my windows box tomorrow or Wednesday and report back. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3422#note_63423

1 0

Re: [PATCH v4 0/1] MR3422: ddraw tests for Pick and GetPickRecords
by Stefan Dösinger March 4, 2024

March 4, 2024

Stefan Dösinger (@stefan) commented about dlls/ddraw/tests/ddraw1.c: > + pick_rect.y1 = pick_rect.y2 = 360; > + record_count = get_pickrecords(device, execute_buffer, viewport, &pick_rect, 3, &record[0]); > + if (record_count == 3) > + { > + /* Documentation states this list is z-ordered, but it appears that it is not. */ > + check_pickrecord(&record[0], D3DOP_TRIANGLE, quad_offset + 4, 0.25f); > + check_pickrecord(&record[1], D3DOP_TRIANGLE, quad_offset + 32, 0.75f); > + check_pickrecord(&record[2], D3DOP_TRIANGLE, quad_offset + 44, 0.5f); > + } > + > + /* Pick a pixel outside of viewport */ > + pick_rect.x1 = pick_rect.x2 = -8; > + pick_rect.y1 = pick_rect.y2 = -8; > + record_count = get_pickrecords(device, execute_buffer, viewport, &pick_rect, 1, &record[0]); > + if (record_count == 1) > + check_pickrecord(&record[0], D3DOP_TRIANGLE, quad_offset + 64, 0.2f); Interesting :-) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3422#note_63422

1 0

Re: [PATCH v4 0/1] MR3422: ddraw tests for Pick and GetPickRecords
by Stefan Dösinger March 4, 2024

March 4, 2024

Stefan Dösinger (@stefan) commented about dlls/ddraw/tests/ddraw1.c: > + /* Pick a pixel where no quads are present */ > + pick_rect.x1 = pick_rect.x2 = 480; > + pick_rect.y1 = pick_rect.y2 = 360; > + get_pickrecords(device, execute_buffer, viewport, &pick_rect, 0, NULL); > + > + /* Pick a pixel where one quad is present */ > + pick_rect.x1 = pick_rect.x2 = 120; > + pick_rect.y1 = pick_rect.y2 = 120; > + record_count = get_pickrecords(device, execute_buffer, viewport, &pick_rect, 1, &record[0]); > + if (record_count == 1) > + check_pickrecord(&record[0], D3DOP_TRIANGLE, quad_offset + 12, 0.25f); > + > + /* Pick a pixel where quad is clipped */ > + pick_rect.x1 = pick_rect.x2 = 40; > + pick_rect.y1 = pick_rect.y2 = 120; > + get_pickrecords(device, execute_buffer, viewport, &pick_rect, 0, NULL); What does clipped mean here? Outside of the 0.0;1.0 depth range? In the TLVERTEX case you get depth values -0.5, 6.5 and -3.0, suggesting that the near and far clip planes don't matter. If I understand this test here right they do matter for LVERTEX. That is consistent with later d3d versions where Z clipping is essentially disabled when drawing pretransformed geometry with the right settings. Another way to look at this is that Z clipping is done by D3DPROCESSVERTICES_TRANSFORM not the draw op (D3DOP_TRIANGLE). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3422#note_63421

1 0

Re: [PATCH v4 0/1] MR3422: ddraw tests for Pick and GetPickRecords
by Stefan Dösinger March 4, 2024

March 4, 2024

Stefan Dösinger (@stefan) commented about dlls/ddraw/tests/ddraw1.c: > + > + /* Pick a pixel where multiple quads are present */ > + pick_rect.x1 = pick_rect.x2 = 64; > + pick_rect.y1 = pick_rect.y2 = 360; > + record_count = get_pickrecords(device, execute_buffer, viewport, &pick_rect, 3, &record[0]); > + if (record_count == 3) > + { > + /* Documentation states this list is z-ordered, but it appears that it is not. */ > + check_pickrecord(&record[0], D3DOP_TRIANGLE, quad_offset + 12, -0.5f); > + check_pickrecord(&record[1], D3DOP_TRIANGLE, quad_offset + 32, 6.5f); > + check_pickrecord(&record[2], D3DOP_TRIANGLE, quad_offset + 52, -3.0f); > + > + /* If the count is wrong, do not populate any records */ > + memset(&record, 0, sizeof(record)); > + record_count = 1; > + hr = IDirect3DDevice_GetPickRecords(device, &record_count, &record[0]); I would expect it to write 3 pick records if the input size in record_count is larger than the number retrieved. I.e., if you set record_count = 4 and make the array large enough it should write 3 and leave the 4th untouched. That's the usual pattern for getters like this at least. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3422#note_63420

1 0

Re: [PATCH v2 0/1] MR685: vkd3d-shader/hlsl: Write the SFI0 section and "REQUIRES_ROVS" flag when ROVs are used.
by Zebediah Figura (＠zfigura) March 4, 2024

March 4, 2024

Yes, both of those were my thought process as well. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/685#note_63419

1 0

[PATCH 0/6] MR5224: Explicitly request debug info in critical sections.
by Paul Gofman (＠gofman) March 4, 2024

March 4, 2024

See https://gitlab.winehq.org/wine/wine/-/merge_requests/5071 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5224

5 9