October 2023 - Wine-GitLab - list.winehq.org

Re: [PATCH v2 0/6] MR4081: dmime: Implement sequence and band track messages. - approved
by Alexandre Julliard (＠julliard) Oct. 16, 2023

Oct. 16, 2023

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

1 0

[PATCH 0/3] MR3839: kernel32: Add structure size checks to CreateActCtx().
by Dmitry Timoshkov (＠dmitry) Oct. 16, 2023

Oct. 16, 2023

Signed-off-by: Dmitry Timoshkov <dmitry(a)baikal.ru> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3839

4 12

[PATCH 0/4] MR4093: mfmedaengine: Use media extension object for CanPlayType().
by Nikolay Sivov (＠nsivov) Oct. 16, 2023

Oct. 16, 2023

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

2 4

[PATCH 0/1] MR4086: d3dx9: Check for tx_1_0 blob magic earlier in D3DXCreateTextureShader().
by Nikolay Sivov (＠nsivov) Oct. 16, 2023

Oct. 16, 2023

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

3 2

[PATCH 0/5] MR4085: wined3d: Old-GL fixes
by Matteo Bruni (＠Mystral) Oct. 16, 2023

Oct. 16, 2023

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

3 9

[PATCH v2 0/1] MR4084: user32/tests: Improve the GetWindowModuleFileName() checks.
by Francois Gouget (＠fgouget) Oct. 16, 2023

Oct. 16, 2023

Check that NULL has no special meaning. Check GetLastError() for systray windows. Trace the module filename in case of unexpected success and enclose it in quotes in case there are leading or trailing spaces. Fix the filename buffer initialization. --- The buf2[0] = 0 line at the top of the patch was introduced in 914cb228685b but buf2 was not used after that. So clearly it is buf1 that should have been initialized there. That said I'm not sure initializing buf1 & buf2 is really necessary as they are only used in case of success. I guess the fear was that GetWindowModuleFileName() would sometimes return success without touching the buffer but I'm not convinced that fear is justified. Still I decided to be conservative and preserve the initializations. I'm fine with removing them though (maybe the buf2 case is a bit special). Finally this is meant to help figure out the reason for the failure decribed in bug 55777. -- v2: user32/tests: Don't test GetWindowModuleFileName() on windows belonging to another process. https://gitlab.winehq.org/wine/wine/-/merge_requests/4084

2 2

[PATCH 0/5] MR4092: user32: Actually implement RealGetWindowClass{A/W}.
by Connor McAdams (＠cmcadams) Oct. 16, 2023

Oct. 16, 2023

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

2 5

[PATCH 0/4] MR4091: advapi32:eventlog tweaks
by Francois Gouget (＠fgouget) Oct. 16, 2023

Oct. 16, 2023

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

2 5

[PATCH v4 0/7] MR4014: winewayland.drv: part 8: More window management
by Alexandros Frantzis (＠afrantzis) Oct. 16, 2023

Oct. 16, 2023

This MR improves window management related behavior and adds support for more scenarios. Some highlights (please see the full commit list and messages for more info): 1. Better support for tiled states. 2. Detect and handle fullscreen windows. 3. Increased robustness against state disagreements between Wine and the Wayland compositor. 4. Move top-level windows to (0,0) (using that fixed point for now, we will later generalize this mechanism for multiple monitors), in order to: a. maximize the accessible mouse input region (which may be clipped in Windows virtual screen space, but still accessible in Wayland space). b. introduce the basic mechanism to allow windows applications to (very roughly!) track which output(s) they are really on (to be continued in the full multi-monitor form). Although (4) is not a perfect solution for the lack of absolute positioning, it has worked well in practice in its full, multi-monitor implementation (i.e., in the experimental branch). I wonder if for (4a) in particular we can do better, e.g., by being able to emit input that circumvents the normal virtual screen clipping. Is there a way to do this already? If not, do you think that such an approach would be a feasible and acceptable way forward, or is virtual screen input clipping fundamentally baked in the current core design and assumptions? Thanks! -- v4: winewayland.drv: Avoid resizing fullscreen windows. winewayland.drv: Rename wayland_surface_configure_is_compatible for consistency. winewayland.drv: Use surface geometry to satisfy state size constraints. winewayland.drv: Handle application-initiated fullscreen state. winewayland.drv: Store and use the latest window config for a wayland_surface. https://gitlab.winehq.org/wine/wine/-/merge_requests/4014

4 10

[PATCH v2 0/2] MR4089: mmdevapi/tests: Don't initialize the audio client twice.
by Hans Leidekker (＠hans) Oct. 16, 2023

Oct. 16, 2023

-- v2: mmdevapi/tests: Relax a capture test. https://gitlab.winehq.org/wine/wine/-/merge_requests/4089

2 3