- wine-gitlab - winehq.org

Re: [PATCH v2 0/1] MR2299: wined3d: Do not switch pixel format on non-private GL contexts. - closed
by Paul Gofman (＠gofman) 14 Mar '23

14 Mar '23

This merge request was closed by Paul Gofman. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2299

1 0

[PATCH 0/1] MR2398: d3dcompiler: Handle some newer D3D_BLOB_PART values in debug_d3dcompiler_d3d_blob_part().
by Henri Verbeet (＠hverbeet) 14 Mar '23

14 Mar '23

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

3 2

[PATCH v10 0/6] MR2275: winewayland.drv: part 1: Introduce the Wayland driver
by Alexandros Frantzis (＠afrantzis) 14 Mar '23

14 Mar '23

Introduction ------------ This is the first of (many) parts in the upstreaming of the Wayland driver for Wine. Since the amount of code and commits is large, my approach is to upstream the driver in multiple parts in a serial fashion, with each part being a cohesive (to the degree possible) set of not too many commits. When each part is reviewed and merged, I will move on to proposing the next part. My main goal with this approach is to make reviewing easier and more focused. If you have other ideas about how to improve this process for the reviewers, please let me know. A lot of pieces need to fall into place before the driver becomes even remotely functional, so, some MRs (especially the initial ones) will be a bit more preparatory in nature. To aid in the understanding of and justification for some of the code introduced in such MRs, all the remaining driver commits are always going to be available at https://gitlab.winehq.org/afrantzis/wine/-/tree/wayland. Part 1 ------- ~~This MR introduces the Wayland driver PE and unixlib components with some basic code, and prepares the makedep tool to be able to handle Wayland protocol files.~~ This MR introduces the Wayland driver PE and unixlib components with some basic code, and reports some basic monitor information to Wine. Please see the individual commit message for more details. Some questions I would appreciate some feedback on in the context of this MR: 1. Should the Wayland driver build be enabled by default at this point? (currently it's explicitly opt-in with --with-wayland) 2. How should the Wayland driver build be integrated with CI? (currently piggybacking on gitlab/build-linux by adding --with-wayland) Note that building the Wayland driver should not affect running/testing on X11/Xwayland etc, since it's placed lower in the driver priority list. ~~Part 2 preview: We will handle basic Wayland wl_output (i.e., display) events and populate the Wine monitor information.~~ Part 2 preview: We will report more monitor information and implement GetCurrentDisplaySettings. -- v10: winewayland.drv: Report all advertised monitor modes to Wine. https://gitlab.winehq.org/wine/wine/-/merge_requests/2275

2 7

[PATCH 0/5] MR2396: widl: Use bison-bridge and noyywrap options, clean up a few things.
by Rémi Bernon (＠rbernon) 14 Mar '23

14 Mar '23

Some preliminary changes, to later improve widl error messages location, as well as compatibility with Windows SDK IDLs. I'm not sure if the latter will be very useful, but it may be interesting to have. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2396

3 6

[PATCH v9 0/6] MR2275: winewayland.drv: part 1: Introduce the Wayland driver
by Alexandros Frantzis (＠afrantzis) 14 Mar '23

14 Mar '23

Introduction ------------ This is the first of (many) parts in the upstreaming of the Wayland driver for Wine. Since the amount of code and commits is large, my approach is to upstream the driver in multiple parts in a serial fashion, with each part being a cohesive (to the degree possible) set of not too many commits. When each part is reviewed and merged, I will move on to proposing the next part. My main goal with this approach is to make reviewing easier and more focused. If you have other ideas about how to improve this process for the reviewers, please let me know. A lot of pieces need to fall into place before the driver becomes even remotely functional, so, some MRs (especially the initial ones) will be a bit more preparatory in nature. To aid in the understanding of and justification for some of the code introduced in such MRs, all the remaining driver commits are always going to be available at https://gitlab.winehq.org/afrantzis/wine/-/tree/wayland. Part 1 ------- ~~This MR introduces the Wayland driver PE and unixlib components with some basic code, and prepares the makedep tool to be able to handle Wayland protocol files.~~ This MR introduces the Wayland driver PE and unixlib components with some basic code, and reports some basic monitor information to Wine. Please see the individual commit message for more details. Some questions I would appreciate some feedback on in the context of this MR: 1. Should the Wayland driver build be enabled by default at this point? (currently it's explicitly opt-in with --with-wayland) 2. How should the Wayland driver build be integrated with CI? (currently piggybacking on gitlab/build-linux by adding --with-wayland) Note that building the Wayland driver should not affect running/testing on X11/Xwayland etc, since it's placed lower in the driver priority list. ~~Part 2 preview: We will handle basic Wayland wl_output (i.e., display) events and populate the Wine monitor information.~~ Part 2 preview: We will report more monitor information and implement GetCurrentDisplaySettings. -- v9: winewayland.drv: Report all advertised monitor modes to Wine. winewayland.drv: Report basic monitor information. win32u: Allow drivers to set the null user driver. winewayland.drv: Perform basic per-process Wayland initialization. winewayland.drv: Add initial unixlib stub. winewayland.drv: Add initial driver stub. https://gitlab.winehq.org/wine/wine/-/merge_requests/2275

3 8

[PATCH 0/1] MR2393: d3d8/tests: Remove an unused call to IDirect3D8_GetAdapterDisplayMode().
by Francois Gouget (＠fgouget) 14 Mar '23

14 Mar '23

It is no longer used now that test_fpu_setup() uses create_device(). Note that there is no such call in d3d9:device so no patch is needed on that side. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2393

4 3

[PATCH 0/1] MR2400: wined3d: Sort the exports.
by Henri Verbeet (＠hverbeet) 14 Mar '23

14 Mar '23

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

3 2

[PATCH 0/1] MR2399: d3d11: Get rid of the DXBC tag definitions.
by Henri Verbeet (＠hverbeet) 14 Mar '23

14 Mar '23

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

3 3

[PATCH v3 0/1] MR2376: wintypes: Stub RoIsApiContractMajorVersionPresent().
by Daniel Tang (＠danielzgtg) 14 Mar '23

14 Mar '23

This is one of the stubs required for MS Office 365. -- v3: wintypes: Stub RoIsApiContractMajorVersionPresent(). https://gitlab.winehq.org/wine/wine/-/merge_requests/2376

4 6

[PATCH 0/1] MR2157: ntdll/unix: Init the trap handler.
by eric pouech (＠epo) 14 Mar '23

14 Mar '23

Otherwise we get nested exceptions on linux on any breakpoint in a multi-arch wow64 (AMD64) configuration, running a 32bit debuggee. With this patch, winetest kernel32:debugger runs to the end (it times out without), yet spitting a couple of failures (that don't exist in old wow64 configuration). Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2157

2 4

2025

2024

2023

2022

wine-gitlab