--
v10: vkd3d-shader/ir: Store code block names in struct vkd3d_shader_desc.
vkd3d-shader/ir: Flatten structured control flow instructions.
vkd3d-shader: Rename shader_instruction_array_add_icb() to shader_instruction_array_add_opaque_param().
vkd3d-shader/spirv: Emit descriptor offset loads in the function entry block.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/450
`winecoreaudio` currently uses the `AudioDeviceID` as the device string (stored in the registry and used to correlate between Core Audio devices and generated GUIDs passed to Windows applications), but an `AudioDeviceID` may change between boots or even when a device is connected/disconnected.
Use the UID instead, which is persistent across boots and connects/disconnects.
These are strings like `BuiltInSpeakerDevice` or `AppleUSBAudioEngine:Apple Inc.:Studio Display:00008030-000128469718180E:6,7`.
This only seems to be documented in the header files, from `AudioHardwareBase.h`:
"`kAudioDevicePropertyDeviceUID`: A CFString that contains a persistent identifier for the AudioDevice. An
AudioDevice's UID is persistent across boots. The content of the UID string
is a black box and may contain information that is unique to a particular
instance of an AudioDevice's hardware or unique to the CPU. Therefore they
are not suitable for passing between CPUs or for identifying similar models
of hardware."
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4632
This MR implements mouselook, which requires support for ClipCursor and relative motion events. The latter we can implement directly without using `SetCursorPos` for which no Wayland protocol exists at the moment.
1. Implement setting the foreground window, as this is required for clipping to work properly (i.e., for the ClipCursor driver callback to be called in the proper process/thread, see commit (2)). We can't unconditionally set the foreground window on keyboard focus, since compositors are eager to give the focus and some windows strongly dislike that (see https://gitlab.winehq.org/wine/wine/-/merge_requests/4102#note_51733). This MR borrows the "managed" window concept from WineX11 to detect windows that we shouldn't allow the compositor to manage, and avoids setting such windows as the foreground on keyboard focus.
2. Implement cursor clipping using the pointer-constraints protocol.
3. Switch to emitting relative motion events using the relative-pointer protocol when the cursor is not visible.
---
4. Finally, a potential fix for an issue I have been seeing where apps may transiently lose the active status (see commit message for more) as a result of the foreground state changes in this MR, which has undesirable side-effects. I have included this here for MR completeness/correctness, but it can be moved to a subsequent MR if preferred.
Note: the velocity of relative motion events when scaling is involved is somewhat inconsistent among Wayland compositors.
Thanks!
--
v5:
https://gitlab.winehq.org/wine/wine/-/merge_requests/4593
This MR implements mouselook, which requires support for ClipCursor and relative motion events. The latter we can implement directly without using `SetCursorPos` for which no Wayland protocol exists at the moment.
1. Implement setting the foreground window, as this is required for clipping to work properly (i.e., for the ClipCursor driver callback to be called in the proper process/thread, see commit (2)). We can't unconditionally set the foreground window on keyboard focus, since compositors are eager to give the focus and some windows strongly dislike that (see https://gitlab.winehq.org/wine/wine/-/merge_requests/4102#note_51733). This MR borrows the "managed" window concept from WineX11 to detect windows that we shouldn't allow the compositor to manage, and avoids setting such windows as the foreground on keyboard focus.
2. Implement cursor clipping using the pointer-constraints protocol.
3. Switch to emitting relative motion events using the relative-pointer protocol when the cursor is not visible.
---
4. Finally, a potential fix for an issue I have been seeing where apps may transiently lose the active status (see commit message for more) as a result of the foreground state changes in this MR, which has undesirable side-effects. I have included this here for MR completeness/correctness, but it can be moved to a subsequent MR if preferred.
Note: the velocity of relative motion events when scaling is involved is somewhat inconsistent among Wayland compositors.
Thanks!
--
v4: win32u: Don't deactivate the target thread when setting the foreground window.
winewayland.drv: Lock the pointer if confined without cursor.
winewayland.drv: Implement relative mouse motion.
winewayland.drv: Implement ClipCursor.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4593