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

Re: [PATCH v2 0/5] MR5233: Dbghelp and debug info lookup (Part II) - approved
by Alexandre Julliard (＠julliard) 05 Mar '24

05 Mar '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5233

1 0

Re: [PATCH v2 0/1] MR5227: ntdll: Respect red zone in usr1_handler() on x64. - approved
by Alexandre Julliard (＠julliard) 05 Mar '24

05 Mar '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5227

1 0

[PATCH 0/2] MR5226: d3d10_1/tests: Add a basic test for returned preferred profiles.
by Nikolay Sivov (＠nsivov) 05 Mar '24

05 Mar '24

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5226

3 3

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

05 Mar '24

On Tue Mar 5 20:50:52 2024 +0000, Jeffrey Smith wrote: > As the documentation states that the updated region _may_ be larger than > the specified region, this seemed safer. Yeah, but I don't really want to trust that programs are following the letter of the documentation either, especially with an API this old. I'd rather at least test exact values, even if we have to mark them todo. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_63598

1 0

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

05 Mar '24

On Tue Mar 5 19:10:38 2024 +0000, Zebediah Figura wrote: > Any reason not to test the exact values? As the documentation states that the updated region _may_ be larger than the specified region, this seemed safer. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_63597

1 0

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

05 Mar '24

On Tue Mar 5 19:10:37 2024 +0000, Zebediah Figura wrote: > Can there be multiple updates? You mention the possibility of "at least" > one update in your tests; should we be storing an array instead? Multiple calls to ForceUpdate seem entirely reasonable. This was part of trying to keep things simple for the implementation and effectively have a single dirty-rectange. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_63596

1 0

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

05 Mar '24

On Tue Mar 5 19:10:31 2024 +0000, Zebediah Figura wrote: > Where do these fail? - The first fails on the testbot (XP/2003) with result DDERR_CANTLOCKSURFACE. - The second fails on a local box on Win10 (with a native d3drm.dll copied in) - the color returned from get_surface_color is always 0x00ff00ff. FWIW, the `test_update_surfaces*` tests _do_ run properly on a local box of mine, running XP bare-metal. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_63595

1 0

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

05 Mar '24

On Tue Mar 5 19:10:30 2024 +0000, Zebediah Figura wrote: > Not a big deal, but in the future I'd like to avoid this, and just > always check the actual hr value. Oops, that must've been left over from a copy-paste. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5161#note_63594

1 0

Re: [PATCH v2 0/4] MR690: Release 1.11. - approved
by Alexandre Julliard (＠julliard) 05 Mar '24

05 Mar '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/690

1 0

[PATCH v3 0/10] MR5177: winewayland.drv: part 13.1: Basic OpenGL support
by Alexandros Frantzis (＠afrantzis) 05 Mar '24

05 Mar '24

This MR introduces support for OpenGL in the Wayland driver. Since the MR started to become somewhat long I have left some things for a subsequent part 13.2: * wgl(Get)SwapIntervalEXT (which means everything is vsync-ed at the moment) * wglShareLists * wglCreateContextAttribsARB * Fix for some apps appearing translucent in certain compositors (typically when fullscreen). Missing features not planned to be part of the 13.x MRs: * Offscreen rendering through pbuffers or pixmaps, since Wayland EGL doesn't support them (perhaps we can simulate with FBOs instead?). * Front buffer rendering. Again Wayland EGL doesn't support this, and certainly not in the form needed (i.e., the surface should be available for additional rendering with GDI). In the experimental branch I implemented a workaround that seemed to work for many cases, but will need to revisit and reevaluate options. IIRC, the most common case I have seen for this is when using wined3d/gl for older (Direct)2D games, so perhaps we can find a better solution at that layer. * Child window rendering (this needs infrastructure in Wayland driver core which will enable both GL and Vulkan rendering in child windows). * Cross-process rendering. Thanks! -- v3: winewayland.drv: Handle resizing of OpenGL content. winewayland.drv: Implement wglSwapBuffers. winewayland.drv: Implement wglMakeCurrent and wglMakeContextCurrentARB. winewayland.drv: Implement OpenGL context creation. winewayland.drv: Implement wglSetPixelFormat(WINE). winewayland.drv: Implement wglDescribePixelFormat. winewayland.drv: Implement wglGetProcAddress. winewayland.drv: Implement wglGetExtensionsString{ARB,EXT}. winewayland.drv: Initialize core GL functions. winewayland.drv: Add skeleton OpenGL driver. https://gitlab.winehq.org/wine/wine/-/merge_requests/5177

3 22