January 2024 - wine-gitlab

[PATCH v2 0/1] MR4944: dlls/msvcrt: Free previous environment variable when clearing
by David Kahurani (＠kahurani) 28 Jan '24

28 Jan '24

Shifting the rest of the variables by one towards indices of lesser value overwrites the variable being cleared and effectively leaks it. Signed-off-by: David Kahurani <k.kahurani(a)gmail.com> -- v2: dlls/msvcrt: Free previous environment variable when clearing https://gitlab.winehq.org/wine/wine/-/merge_requests/4944

3 2

[PATCH 0/1] MR4953: krnl386: Emulate the VGA status register.
by Alex Henrie (＠alexhenrie) 28 Jan '24

28 Jan '24

Sega Bug uses it as a timer. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4953

2 1

[PATCH 0/1] MR4948: winewayland.drv: Track and apply latest window cursor on pointer enter.
by Alexandros Frantzis (＠afrantzis) 28 Jan '24

28 Jan '24

Keep track of the window cursor set for each surface and apply it when the pointer enters the corresponding surface. This fixes a problem where due to transient disagreements between win32 pointer focus and Wayland pointer focus a cursor update may be lost. For example: 1. Assume existing cursor C1. 2. Window is created beneath cursor. 3. The SetCursor(hwnd, C2) driver callback is called, but because the wl_pointer hasn't entered the Wayland surface yet we don't update the wl_pointer cursor. 4. wl_pointer enters the surface, we apply the latest cursor we know about, which is C1. 5. Since no change in cursor window occurs, we don't get any further SetCursor(hwnd, C2) callbacks, so we get stuck with C1. This commit fixes the problem by tracking the per-surface HCURSOR in step 3, regardless of whether the cursor is actually applied. So, in step 4 we can use that HCURSOR for the surface. This change also fixes some cases of our mouselook heuristics not kicking in properly due to missing a SetCursor(hwnd, NULL) in the manner described above. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4948

3 2

[PATCH v4 0/4] MR4857: Draft: gdi32,win32u: Implement D3DKMTEnumAdapters2.
by Krzysztof Bogacki (＠Saancreed) 27 Jan '24

27 Jan '24

An alternative approach to `EnumAdapters2` that does not directly call to GDI driver and therefore does not require GDI driver functions to be expanded. The implementation now lives in `sysparams.c` to make it closer to win32u caches it accesses. It still uses `OpenAdapterFromLuid` internally because that's where adapter handles are actually assigned and to make sure returned handles are usable with other functions that rely on GDI driver being aware of what the handle represents to be able to function correctly (like `QueryVideoMemoryInfo`). See !4791 for some background and why this version might be preferable over the one submitted there. -- v4: win32u: Implement NtGdiDdDDIEnumAdapters2. win32u: Maintain a list of GPUs in cache. gdi32,win32u: Add stubs for D3DKMTEnumAdapters2 and NtGdiDdDDIEnumAdapters2. gdi32/tests: Add D3DKMTEnumAdapters2 tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/4857

3 5

[PATCH v11 0/6] MR4092: user32: Actually implement RealGetWindowClass{A/W}.
by Connor McAdams (＠cmcadams) 27 Jan '24

27 Jan '24

-- v11: user32: Pass real argument to NtUserGetClassName in RealGetWindowClass{A/W}. win32u: Add support for retrieving real window class ID across processes. user32: Set real window class ID for user32 static controls. win32u/tests: Add a test for real window class name retrieval. comctl32/tests: Add tests for RealGetWindowClass. user32/tests: Add tests for RealGetWindowClass. https://gitlab.winehq.org/wine/wine/-/merge_requests/4092

2 6

[PATCH v11 0/5] MR3103: server: Create and use a desktop shared mapping for GetCursorPos.
by Rémi Bernon (＠rbernon) 27 Jan '24

27 Jan '24

First part of Proton shared memory series. The full branch can be seen at https://gitlab.winehq.org/rbernon/wine/-/commits/mr/shared-memories. -- v11: user32: Use the desktop shared data for GetCursorPos(). server: Add a sequence number to the shared data. server: Move the cursor position and last change time to the shared data. server: Use the helper to update the cursor last change time. server: Create a desktop shared mapping. https://gitlab.winehq.org/wine/wine/-/merge_requests/3103

3 9

[PATCH v2 0/1] MR4739: ntdll: Don't hardcode page size
by Fabian Maurer (＠DarkShadow44) 27 Jan '24

27 Jan '24

While this is not needed for 16k pages to work, it does seem sensible. -- v2: ntdll: Don't hardcode page size https://gitlab.winehq.org/wine/wine/-/merge_requests/4739

2 1

Re: [PATCH v3 0/4] MR4888: wined3d: Avoid assuming the GL backend in (what can be) common code.
by Stefan Dösinger (＠stefan) 27 Jan '24

27 Jan '24

Oh and I believe part of the historic mess is that ddraw sets color keys per-surface, so on paper you might set a different key on a mipmap sublevel or cube face. Not that I expect that to do anything useful in practise. test_ck_complex shows mipmap sub levels return DDERR_NOTONMIPMAPSUBLEVEL in ddraw7, but not earlier. I guess ddraw_surface_set_color_key() could use a FIXME for the !surface->is_root case... -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4888#note_59256

1 0

Re: [PATCH v3 0/4] MR4888: wined3d: Avoid assuming the GL backend in (what can be) common code.
by Stefan Dösinger (＠stefan) 27 Jan '24

27 Jan '24

I just noticed this on wine-gitlab, and I am pretty sure the check was necessary at the time for the (IWineD3DTextureImpl *) stateblock->textures[0] cast. Color keys have since been moved from surfaces to textures, and as Henri mentioned, textures unified. I don't know of a particular design reason why D3DRS_COLORKEYENABLE wouldn't work with cube textures. I don't know of any application that combines them though (the only ddraw thing I know that uses cube textures is a dx7 sdk sample), so I wouldn't be surprised if you hit driver bugs if you try. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4888#note_59255

1 0

Re: [PATCH v3 0/3] MR4857: Draft: gdi32,win32u: Implement D3DKMTEnumAdapters2.
by Zhiyi Zhang (＠zhiyi) 27 Jan '24

27 Jan '24

On Tue Jan 23 10:02:40 2024 +0000, Krzysztof Bogacki wrote: > I'm trying to follow the suggestion to read SetupAPI registry data but > I'm having some difficulties, with the major one being: I'm not actually > sure where that data is. Your sample code doesn't seem to read the > registry and just returns/enumerates an empty device set. What am I > missing here? > On the other hand, I had a look at where win32u writes stores > information when `add_gpu` is called and figured that I can (probably) > use whatever this function writes. This gives me two possible leads: > 1. > `HKML\System\CurrentControlSet\Control\Class\{4D36E968-E325-11CE-BFC1-08002BE10318}\${gpu_id}`. > Although easier to enumerate, this doesn't have the most important piece > of data: GPU LUID, which I'd have to retrieve from the second key anyway > and it doesn't have any links to second keys I could use to open it > directly, so it's not very viable for my purposes here. > 2. `HKML\System\CurrentControlSet\Enum\PCI\${pci_id}\${gpu_idx}`. This > does have GPU LUID I can easily retrieve but some of the other data is > kept only as wide strings which I'd need to parse if I wanted to use > them (if only for bookkeeping purposes). E.g. the only way I see to > retrieve PCI vendor and device IDs would be parsing `${pci_id}` but as > far as I can tell, I can't just use `snwscanf` to process 2-byte wide > strings in Unixlibs. > Of course, I could pick the second version and read only the LUID while > ignoring PCI IDs and GPU ID/index completely, but I'd like to ask first > if it's correct thing to do before I commit to that. HKML\\System\\CurrentControlSet\\Enum\\PCI is the correct key to enumerate GPUs. > the only way I see to retrieve PCI vendor and device IDs would be parsing ${pci_id} but as far as I can tell, I can't just use snwscanf to process 2-byte wide strings in Unixlibs. Do you really need PCI IDs for D3DKMTEnumAdapters2? If you do, I am sure there is a way to parse them. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4857#note_59247

1 0

2025

2024

2023

2022

wine-gitlab January 2024