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

[PATCH 0/1] MR4892: msvcp140: Add stub for _XGetLastError.
by Vijay Kiran Kamuju (＠infyquest) 20 Jan '24

20 Jan '24

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

3 2

[PATCH v2 0/1] MR4891: wine.inf: Create security directory.
by Vijay Kiran Kamuju (＠infyquest) 20 Jan '24

20 Jan '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52399 -- v2: wine.inf: Create security directory. https://gitlab.winehq.org/wine/wine/-/merge_requests/4891

2 1

[PATCH 0/1] MR4891: wine.inf: Create security directory.
by Vijay Kiran Kamuju (＠infyquest) 20 Jan '24

20 Jan '24

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

2 1

[PATCH 0/1] MR4890: dbghelp: Return early if HeapAlloc failed.
by Bernhard Übelacker 20 Jan '24

20 Jan '24

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

1 1

Re: [PATCH v2 0/1] MR4692: loader: Associate folder with explorer.
by Rémi Bernon 20 Jan '24

20 Jan '24

Fwiw this broke the shell32 tests on Linux. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4692#note_58270

1 0

[PATCH 0/6] MR4858: wined3d: GL format detection refactoring, part 1.
by Zebediah Figura (＠zfigura) 20 Jan '24

20 Jan '24

This series begins the process of moving GL format detection code to a separate file, for reasons described in 1/6 and [1]. Still, if this is deemed undesirable or not worthwhile, I don't particularly mind dropping this and/or further refactoring work. At this point my initial goal, viz. to find all of the code in wined3d that implicitly assumes it's running under the GL backend, has basically been accomplished. [1] https://gitlab.winehq.org/wine/wine/-/merge_requests/3238 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4858

3 12

[PATCH v5 0/6] MR3454: user32: Implement UOI_TIMERPROC_EXCEPTION_SUPPRESSION.
by Jinoh Kang (＠iamahuman) 20 Jan '24

20 Jan '24

This is required to avoid silencing (potentially fatal) exceptions from timer procedures. -- v5: win32u: Ignore unhandled info index in NtUserSetObjectInformation. win32u/tests: Add tests for NtUserSetObjectInformation. user32: Implement UOI_TIMERPROC_EXCEPTION_SUPPRESSION. user32/tests: Add tests for UOI_TIMERPROC_EXCEPTION_SUPPRESSION. include: Add definition for UOI_TIMERPROC_EXCEPTION_SUPPRESSION user32/tests: Make test_unicode_wm_char robust against superfluous messages. https://gitlab.winehq.org/wine/wine/-/merge_requests/3454

2 7

Re: [PATCH v3 0/3] MR4857: Draft: gdi32,win32u: Implement D3DKMTEnumAdapters2.
by Krzysztof Bogacki (＠Saancreed) 19 Jan '24

19 Jan '24

Thanks for reviewing, I'll probably need a few days to figure this out. I'll mark this MR as draft while it's work-in-progress and I'll unmark it when the next version is ready. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4857#note_58259

1 0

Re: [PATCH v3 0/3] MR4857: Draft: gdi32,win32u: Implement D3DKMTEnumAdapters2.
by Krzysztof Bogacki (＠Saancreed) 19 Jan '24

19 Jan '24

On Fri Jan 19 04:03:17 2024 +0000, Zhiyi Zhang wrote: > D3DKMT_ENUMADAPTERS2 already has an array for this. I think you can > avoid this memory allocation. Indeed, but I thought it would be safer to allocate some memory for a temporary working area, try enumerating adapters and only copy the result if the entire operation did not fail halfway through rather than using the array I was passed by the caller directly and risk writing some partially misleading garbage to it. I also wasn't sure how to proceed in such case: if I already wrote some LUIDs and handles, should I try to `memset(0)` them just in case or leave the data there and trust that all callers of this API will ignore whatever was written, treating the content as unspecified? It's also somewhat tricky to cause Windows to fail here so I don't know how exactly does it behave when it encounters some error internally. Copying the full result only on full success seemed like an easy way out that allowed me to not bother figuring this out, even if it costs an extra allocation. But I can revert to writing to `pAdapters` directly if you'd prefer it that way. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4857#note_58256

1 0

Re: [PATCH v3 0/3] MR4857: Draft: gdi32,win32u: Implement D3DKMTEnumAdapters2.
by Krzysztof Bogacki (＠Saancreed) 19 Jan '24

19 Jan '24

> This is wrong. adapters in sysparams.c are GDI adapters, they are not the same adapter in D3DKMT terms. Adapters in D3DKMT terms mean GPUs. So you need to add a list of GPUs to the cache and then do enumeration from that. Ah, okay, I see. I was unaware of GDI having a different concept of adapters than D3D(KMT), my bad there :sweat_smile: > You should do the initialization from the SetupAPI registry data. For example, basically with the following code. However, since you're in win32u. You can't use SetupAPI directly and you need to convert these to NT registry calls instead. See prepare_devices() for some example code for how to do it. Thanks, I'll see if I can figure this out. > Then `NumOfSources` is the number of GDI adapters with the same GPU LUID. Okay. From what I've observed, on Windows (checking 2 separate machines), it seems to be constant 4 for adapters that represent physical GPUs and 0 for adapter that seems to represent Microsoft's Basic Render thingy. > As for bPrecisePresentRegionsPreferred, I guess you can just return TRUE. For what it's worth, I haven't seen any adapter to report `TRUE` here on Windows. So it might be safer to default to `FALSE` instead. > The GPU list construction can be done in update_display_cache_from_registry(). Got it, thanks. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4857#note_58257

1 0