Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56698
I'm not hugely satisfied with some of those changes (especially how looping avi_decompressor_source_get_media_type now takes O(n^2) calls to ICDecompressQuery), but it gets the video in that issue working.
If you've got a better idea for how to implement this stuff, do tell.
--
v4: msvfw32/tests: Test that Cinepak rejects unsupported output types.
iccvid: Reject unsupported output types.
quartz/tests: Add Cinepak test to avi splitter.
winegstreamer: Try DTS if PTS is absent.
winegstreamer: Implement AM_MEDIA_TYPE to wg_format converter for Cinepak video.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5744
There is a check earlier in the PSDRV_MergeDevmodes/merge_devmodes functions to update
dmDefaultSource if a slot is found, and so this member should not be
updated again with no such check.
--
v2: wineps.drv: Only merge dmDefaultSource member of devmodes when a slot is found.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5720
This is an early draft of an implementation of key auto-repeat in wineserver to get some feedback. Some open questions:
1. queue_keyboard_message requires a `current` thread, but we don't get one in timeout callbacks. At the moment I am manually setting `current` to the foreground thread, but I am wondering if that's acceptable or we should explore other ways forward (also see TODO in code).
2. This draft introduces a new server request to configure auto-repeat (`enable/delay/period`). I am thinking that for more straightforward integration with the keyboard repeat SPI parameters, the request should only support the `enable` flag and the server should query the SPI registry values to get `delay` and `period` when needed. I am wondering if there any caveats here since I don't see other code in the server querying registry values (well, except to implement the registry requests themselves).
Also, I would hope that opening and caching the `HKCU\Control Panel\Keyboard` hkey would remove most of the cost of performing this operation (if that's even a concern at all).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5741
These patches fix painting in an application that draws outside of a CS_PARENTDC child
client area in its WM_PAINT handler.
Comments and suggestions are welcome.
--
v2: win32u: Use parent rectangle for visible region calculations of a CS_PARENTDC child.
win32u: Don't clip update region to the window client rectangle.
win32u: GetUpdateRgn() should clip update region to the window client area.
win32u: GetUpdateRect() should clip update rectangle to the window client area.
win32u: Clip PAINTSTRUCT.rcPaint to the window client area.
server: For a CS_PARENTDC child use parent for visible region calculations.
server: If the being validated region covers whole window then validate everything.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5665
--
v4: win32u: Only keep DPI awareness context with window objects.
win32u: Fix SetThreadDpiAwarenessContext.
win32u: Pass the DPI awareness context in win_proc_params.
win32u: Get the thread DPI context instead of the awareness.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5738
Currently, when GPUs are being added and display driver only provides a fake one (like e.g. winex11.drv does on Xwayland), its default name and empty UUID and PCI IDs will be preferred over ones reported by Vulkan. When Vulkan-only GPUs are added later, the resulting list will look like so:
```
Xrandr GPU 0x0000:0x0000 {00000000-0000-0000-0000-000000000000}
NVIDIA GeForce RTX 4080 Laptop GPU 0x10de:0x27e0 {13938ad6-4925-b628-c068-30558bc4b489}
```
Instead, when default or empty properties were provided, we should prefer ones from Vulkan as they are more likely to be accurate:
```
Intel(R) Graphics (RPL-S) 0x8086:0xa788 {a7888086-0004-0000-0002-000000000000}
NVIDIA GeForce RTX 4080 Laptop GPU 0x10de:0x27e0 {13938ad6-4925-b628-c068-30558bc4b489}
```
This is important for LUIDs to be later correctly assigned by winevulkan which searches for matching GPU by UUID.
I'm not exactly sure if this implementation is the way to go (especially reporting and checking name for `"Wine GPU"`) but it's probably one of the simplest possible. Let me know if we already have some empty UUID around I could use for the comparison.
--
v2: win32u: Prefer Vulkan UUIDs over empty ones.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5736
--
v2: winex11: Stop using a recursive mutex for the window surfaces.
winewayland: Stop using a recursive mutex for the window surfaces.
winemac: Stop using a recursive mutex for the window surfaces.
wineandroid: Stop using a recursive mutex for the window surfaces.
win32u: Stop using a recursive mutex for the offscreen surface.
win32u: Remove surface recursive locking requirement.
win32u: Flush window surface when it is fully unlocked.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5470