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