This serie is the first result of investigation of loops not
being played on dmusic for wave tracks.
It basically:
- extends tests so that we can check if loop work at some extend
(they don't right now)
- add and fix a couple of existing tests.
And contain fixes for crufts in existing code:
- fix an errouneous prototype
- removed unused fields.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4950
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
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
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
--
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
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