November 2022 - Wine-gitlab

[PATCH 0/2] MR1251: d2d1: Use D2D1_ALPHA_MODE_IGNORE if D2D1_ALPHA_MODE_UNKNOWN is used for...
by Zhiyi Zhang (＠zhiyi) 06 Nov '22

06 Nov '22

These two patches are prerequisites for the render target IsSupported() patches that will be sent later. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1251

4 4

[PATCH v8 0/2] MR841: ntoskrnl.exe: processor change callback stubs
by Etaash Mathamsetty (＠etaash.mathamsetty) 06 Nov '22

06 Nov '22

required for mrac anti cheat -- v8: ntoskrnl.exe: Add KeDeregisterProcessorChangeCallback stub. ntoskrnl.exe: Add KeRegisterProcessorChangeCallback stub. https://gitlab.winehq.org/wine/wine/-/merge_requests/841

3 4

[PATCH 0/2] MR1265: netprofm: Add INetwork_GetNetworkConnections test
by Sebastián Aedo 05 Nov '22

05 Nov '22

Although I couldn't find other uses for `list_manager_create`, it seems that in this case is working just fine. The list manager should be released once the `IEnumNetworkConnections` is destroyed. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1265

2 4

[PATCH v7 0/2] MR914: ntoskrnl.exe: Implement various KeQuery* functions
by Etaash Mathamsetty (＠etaash.mathamsetty) 05 Nov '22

05 Nov '22

mrac tries to get function pointers for these functions using MmGetSystemRoutineAddress, I haven't seen them being used by it, but might as well implement it since they are very easy to implement. -- v7: ntoskrnl.exe: Implement KeQueryActiveProcessorCount. ntoskrnl.exe: implement KeQueryMaximumProcessorCount/Ex. https://gitlab.winehq.org/wine/wine/-/merge_requests/914

2 2

Re: [PATCH v5 0/1] MR826: wined3d: Add support for Renoir GPUs - closed
by Etaash Mathamsetty (＠etaash.mathamsetty) 05 Nov '22

05 Nov '22

This merge request was closed by Etaash Mathamsetty. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/826

1 0

Re: [PATCH v5 0/1] MR826: wined3d: Add support for Renoir GPUs
by Etaash Mathamsetty (＠etaash.mathamsetty) 05 Nov '22

05 Nov '22

upstream has fixed the issue (my GPU now reports as AMD Radeon Graphics rather than AMD RENOIR) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/826#note_13298

1 0

[PATCH 0/2] MR1106: Enable long types in d3d8.
by eric pouech (＠epo) 05 Nov '22

05 Nov '22

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

4 8

[PATCH v16 0/3] MR155: ntdll: Fix reading stale Information from IOSB.
by Jinoh Kang (＠iamahuman) 05 Nov '22

05 Nov '22

Enforce proper atomic update so that other threads do not read stale data from IO_STATUS_BLOCK. Signed-off-by: Jinoh Kang <jinoh.kang.kr(a)gmail.com> -- v16: ntdll: Fix reading stale Information from IOSB. https://gitlab.winehq.org/wine/wine/-/merge_requests/155

2 3

[PATCH 0/1] MR41: vkd3d-shader/hlsl: Print hlsl_fixme() messages using FIXME() as well.
by Zebediah Figura (＠zfigura) 04 Nov '22

04 Nov '22

This makes most vkd3d-shader insufficiencies a lot more obvious when used as an embedded library. The obvious disadvantage here is that vkd3d-compiler will basically print every fixme message twice. This is a bit of an RFC, since I'm not married to this patch. Other potential approaches I see (not all mutually exclusive): * Always print a FIXME if we return VKD3D_ERROR_NOT_IMPLEMENTED from compile_hlsl(), but don't print messages for individual compilation errors. Thus we clue in debuggers that a bug is related to HLSL, but let them use VKD3D_SHADER_DEBUG to find out what the actual bug is. Since the first step is most of the hard part I think this is a reasonable solution. * Or do the same thing from d3dcompiler. * Relegate hlsl_fixme to a separate vkd3d_shader_log_level, and print messages from that log level in d3dcompiler by default. This isn't quite as simple as that though, since currently all the messages are stored in a single blob. * Extra APIs to control whether FIXMES are printed. I'd also like to propose extending whichever of the above solutions to the hlsl_error() / VKD3D_ERROR_INVALID_SHADER cases. That way we catch things which we aren't going to catch via hlsl_fixme(), such as syntax errors from unrecognized keywords. There's a counterargument that compiling an invalid shader is valid usage, and that we (wine or vkd3d) shouldn't print any ERR/FIXME messages when a program does something valid and implemented, but I'd counter that in practice intentionally compiling an invalid shader should be exceedingly rare, and especially for something like wine or vkd3d where debugging is difficult, it's simply not worth insisting on "a correctly functioning program should print no messages" if it's at the cost of making debugging that much harder. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/41

3 6

Re: [PATCH v2 0/1] MR1264: winebuild: Avoid calling asm_name twice in function arguments. - approved
by Alexandre Julliard (＠julliard) 04 Nov '22

04 Nov '22

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

1 0