- Wine-GitLab - list.winehq.org

Re: [PATCH v2 0/1] MR2327: kernel32: Implement GetFirmwareType(). - approved
by Alexandre Julliard (＠julliard) March 6, 2023

March 6, 2023

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

1 0

Re: [PATCH v2 0/1] MR2324: advapi32/tests: Fix the RegEnumValueA() tests in UTF-8 locales. - approved
by Alexandre Julliard (＠julliard) March 6, 2023

March 6, 2023

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

1 0

[PATCH v3 0/9] MR106: vkd3d-shader/hlsl: packoffset() support.
by Francisco Casas (＠fcasas) March 6, 2023

March 6, 2023

Support manually packing constant buffer elements through the `packoffset(·)` syntax. Support not included yet for simultaneously having semantics, `register(·)`, and `packoffset(·)`, for abnormalities such as: ```hlsl Texture2D tex; cbuffer buff { float4 a : packoffset(c0); sampler sam : packoffset(c0) : register(s1) : SEMANTIC; } float4 main() : sv_target { return tex.Sample(sam, float2(0, 0)) + a; } ``` but this motivated the addition of the `hlsl_ir_var.offset_reservation` field instead of reusing `hlsl_ir_var.reg_reservation`. -- v3: vkd3d-shader/hlsl: Consider register() as manual packing for resource fields. tests: Test packoffset() with resources inside cbuffers. vkd3d-shader/hlsl: Ignore packoffset() contents for SM1. vkd3d-shader/hlsl: Don't allow manual and automatic cbuffer offset packing. vkd3d-shader/hlsl: Detect overlaps in cbuffer offsets. vkd3d-shader/hlsl: Support packoffset(). vkd3d-shader/hlsl: Parse packoffset(). tests: Test packoffset(). https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/106

3 12

[PATCH 0/12] MR2292: windows.perception.stub: Implement ISpatialSurfaceObserverStatics2::IsSupported()
by Mohamad Al-Jaf (＠maljaf) March 6, 2023

March 6, 2023

Needed by the VR games Forewarned and Überlaüfer. I had to put the parameters of the header functions on newlines because they're too long. Did the same for the other headers for consistency. windows.security.cryptography.idl uses a similar style. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2292

3 18

[PATCH 0/5] MR2322: wined3d: move stubs out of state tables
by Max Figura (＠maxfigura) March 6, 2023

March 6, 2023

Removing WINED3D_RS entries from state tables and moving stubs to wined3d_device_apply_stateblock. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2322

4 7

[PATCH v2 0/3] MR115: vkd3d-shader/hlsl: Write sample count for multisampled resources declarations.
by Nikolay Sivov (＠nsivov) March 6, 2023

March 6, 2023

-- v2: vkd3d-shader/sm4: Write sample count field for multisampled texture declaration. vkd3d-shader/hlsl: Parse multisample texture type names. vkd3d-shader/trace: Output sample count for multisampled resources. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/115

3 4

[PATCH 0/1] MR2332: ir50_32: Handle 24-bit output media type.
by Anton Baskanov (＠baskanov) March 6, 2023

March 6, 2023

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

3 2

Re: [PATCH v2 0/1] MR2299: wined3d: Do not switch pixel format on non-private GL contexts.
by Zebediah Figura (＠zfigura) March 6, 2023

March 6, 2023

> Thinking of doing this x11 specific, I think that maybe we don't even need a special boolean flag if your MR !2217 gets in? Once we have a separate tracking of internal pixel format in WGL_WINE_pixel_format_passthrough we could just always fail setting internal pixel format once external is set. The extension itself will still work as if an app wants to use GL together with d3d it will be able to set GL pixel format (which will result in wined3d creating a backup context). I think that'd work, yeah. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2299#note_26227

1 0

Re: [PATCH v2 0/1] MR2299: wined3d: Do not switch pixel format on non-private GL contexts.
by Paul Gofman (＠gofman) March 6, 2023

March 6, 2023

I looked a bit into winemac driver and some GL on Mac docs and I suppose that such an issue should not be happening on Mac. If I read that right pixel format is only bound to GL context and the pixel format set by Wine only influences the contexts created with the window. I don't have any Mac setup however to check that for sure. If anyone could check if that referenced games (Richman: Classic in opengl mode or Secondhand Lands or SPORE from Bug 51848 work now on Mac without issues that would be a good confirmation that set pixel format works fine there and doesn't impose issues like on winex11. Thinking of doing this x11 specific, I think that maybe we don't even need a special boolean flag if your MR !2217 gets in? Once we have a separate tracking of internal pixel format in WGL_WINE_pixel_format_passthrough we could just always fail setting internal pixel format once external is set. The extension itself will still work as if an app wants to use GL together with d3d it will be able to set GL pixel format (which will result in wined3d creating a backup context). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2299#note_26224

1 0

Re: [PATCH v4 0/6] MR2275: winewayland.drv: part 1: Introduce the Wayland driver
by Jacek Caban (＠jacek) March 6, 2023

March 6, 2023

On Wed Mar 1 12:24:02 2023 +0000, Alexandros Frantzis wrote: > > The last patch looks worrying in terms of forward-compatibility. > Looking at your wayland branch, you use a few unstable files. What > happens if/when they get promoted to stable? Will those files be moved > in wayland-protocols causing your branch to fail to build? > TL;DR: Not a problem. > When a protocol is moved to stable, a new copy is placed in that > directory (details are different depending on whether this copy is done > from 'staging' or the legacy 'unstable'), while the old xml file(s) > remain in place for backward compatibility. If the new copy requires a > protocol name change (e.g., from unstable->stable, but not > staging->stable) compositors tend to have a long deprecation period > during which both old and new names are supported. As an example, it > took compositors several years to drop support for unstable/xdg-shell > after the introduction of stable/xdg-shell. > FWIW, the Wayland community is *very* conservative concerning promotions > to stable, so a lot of functionality is still in unstable/staging. > Compare: 3 stable protocols vs 27 staging/unstable, some of them having > been there for many years. > More information about these topics can be found at https://gitlab.freedesktop.org/wayland/wayland-protocols/ > > Also, it would be better to have commit adding build system support > for protocol files together with at least a simple use of it in the same MR. > Ack. Moved to the next MR. Thanks for explanation, staging backward compatibility guarantees should do the trick. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2275#note_26223

1 0