--
v6: mfreadwrite/reader: Pass the device manager to the stream transforms.
winegstreamer/video_processor: Implement D3D awareness.
mf/tests: Test video processor D3D11 awareness.
mfreadwrite/tests: Add some source reader D3D11 awareness tests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5459
I'm not completely sure about the mechanism, but I think it's simple enough to consider having that upstream now. This shows at least how we can leverage win32u surface changes to decide to switch surfaces on/off-screen and fallback to manual blitting.
Having the surfaces on-screen makes sure they are presented as efficiently as possible, having them off-screen we use GDI blit to indirectly call XCopyArea and this will be suboptimal, probably with visible tearing, but hopefully not too common.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5573
This seems to be relied on by some versions of [this Unreal Engine input plugin](https://www.unrealengine.com/marketplace/en-US/product/wm-input-man…
Note: I'm not sure how to deal with `HID_USAGE_GENERIC_KEYPAD`, which (I think) would fall under `RIM_TYPEKEYBOARD`. Do we need to store extra info to differentiate these from `HID_USAGE_GENERIC_KEYBOARD` or is there something in the device info struct that can differentiate them?
--
v4: user32: Post WM_INPUT_DEVICE_CHANGE when registering for notifications
user32: Add tests for WM_INPUT_DEVICE_CHANGE messages
https://gitlab.winehq.org/wine/wine/-/merge_requests/2120
ObjC dictionary literals are autoreleased, meaning BitmapOutputTypeMap was released at the end of the first call to macdrv_copy_pasteboard_types. Any call after that was liable to crash, depending on whether it was overwritten. More complex objects on the clipboard (like a file copied in the Finder) seemed to trigger a crash, which manifested as explorer.exe taking 100% of CPU (since the main thread crashed, then the SEGV handler crashed because it's not a Wine thread).
Fixes a regression from bb2e02ab66c5c602d635722cf3a5820d6b366006.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5572
This appear to be introduced with commit 12f73ed9d851.
When This->stride is negative (bottom up image) it converts the multiplication to an UINT.
Thus causing the pointer to be incorrect when y > 0.
--
v2: windowscodecs: Avoid implicit cast changing value.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5568
This appear to be introduced with commit 12f73ed9d851.
When This->stride is negative (bottom up image) it converts the multiplication to an UINT.
Thus causing the pointer to be incorrect when y > 0.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5568
Trace output with PulseAudio:
```
0230:trace:mmdevapi:adjust_timing Requested duration 1000000 and period 0
0230:trace:mmdevapi:adjust_timing Device periods: 100000 default and 30000 minimum
0230:trace:mmdevapi:adjust_timing Adjusted duration 1000000 and period 100000
```
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5564
ucrtbase._mbsncpy_s is used by Marvel vs Capcom when trying to create multiplayer lobby.
The functions are also present in msvcrt (unlike msvcr70, msvcr71) where I didn't add it because it behaves differently: there is at least one weirdness when it doubles the number of characters to copy ('n' parameter, not buffer size). I suppose we don't need to explore and deal with this specific until something needs those functions from msvcrt.
--
v5: msvcrt: Implement _mbsncpy_s[_l]().
https://gitlab.winehq.org/wine/wine/-/merge_requests/5547
--
v3: winex11: Remove now unnecessary surface wrapper struct.
win32u: Move thread detach from winex11.
win32u: Introduce a per-window vulkan surface list.
winewayland: Get rid of the now unnecessary surface wrapper.
win32u: Return the host surface directly from vulkan_surface_create.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5551
On Wed May 1 00:08:18 2024 +0000, Alistair Leslie-Hughes wrote:
> That's really not a solution. This was working without issues for many
> years. So, forcing our users to upgrade our product isn't always an option.
> Also, how backward compatible is that solution going to be? We still
> have users on *cough* wine 5, will it work for them?
Can you tell me what the actual use case is? I believe the bug report is about `start.exe`, which this MR should fix.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5400#note_69335
--
v9: win32u: Introduce a new add_virtual_modes helper.
winex11: Let win32u decide when to force update the display cache.
win32u: Don't force refresh the display cache on thread desktop change.
winex11: Report all sources as detached in virtual desktop mode.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5422
ucrtbase._mbsncpy_s is used by Marvel vs Capcom when trying to create multiplayer lobby.
The functions are also present in msvcrt (unlike msvcr70, msvcr71) where I didn't add it because it behaves differently: there is at least one weirdness when it doubles the number of characters to copy ('n' parameter, not buffer size). I suppose we don't need to explore and deal with this specific until something needs those functions from msvcrt.
--
v4: msvcrt: Implement _mbsncpy_s[_l]().
https://gitlab.winehq.org/wine/wine/-/merge_requests/5547
--
v8: win32u: Introduce a new add_virtual_modes helper.
winex11: Let win32u decide when to force update the display cache.
win32u: Don't force refresh the display cache on thread desktop change.
winex11: Report all sources as detached in virtual desktop mode.
win32u: Set the virtual desktop display frequency to 60Hz.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5422