- Mar 01, 2025
-
-
-
This allows higher precision waits, to match the other platforms where we can already use a timespec directly. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57849
-
Instead of first converting to milliseconds, then back to a nanosecond-precision timespec. This mitigates a side effect of the global current_time and monotonic_time being updated on every server call's timeout, where the end time of any unrelated server call is moved into the future (depending on the frequency of server calls). By using a more granular timeout, the overall frequency of server calls doesn't have as great of an effect on each individual timeout, as we don't have to wait for an entire millisecond (which was due to the ceiling operation in get_next_timeout). Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57849
-
-
We're not going to use it anyway, but prevent DXGI from implicitly wait on it. That wouldn't change the result result because Present() eventually times out anyway, but it would uselessly waste a few seconds.
-
The client is expected to wait on the frame latency semaphore when the swapchain is created with DXGI_SWAP_CHAIN_FLAG_FRAME_LATENCY_WAITABLE_OBJECT. But when it is not, we're supposed to do it ourselves.
-
As it should be, given that it is supposed to keep the count of how many frames are currently in flight.
-
It is now useless: we signal signal it directly and use it to set an event, without having anything to do with the CPU. We can set the event directly instead.
-
Instead of going through the command queue again. That's because at that point we just submitted the frame for presentation to Vulkan, so the best approximation we have for when the frame will be presented is now, not after the currently outstanding work in the command queue is processed. It's still a rather poor approximation, but for something better we need VK_KHR_present_wait.
-
The bias was a broken solution for handling the maximum frame latency changes. However we now already set the event (and, in the future, release the sempahore) when the maximum frame latency is increased, so there is no need for the bias anymore.
-
This is only partially correct, because the frame latency waitable should be a semaphore instead. However, it's a step in the right direction, in preparation to make the waitable an actual semaphore.
-
The new vkd3d API allows submitting presentation as soon as the internal vkd3d work is flushed to Vulkan. Now we're also waiting for it to be executed, which is useless.
-
-
-
-
-
-
-
-
-
d3d9 and d3d10 YUV formats generally have completely different behaviour, even after accounting for the fundamental differences between the APIs. d3d9 can blit between YUV and RGB formats, with associated format conversion, and can use the entire resource in blits and clears, whereas d3d10 cannot do either of these things, and must use views of individual planes. This causes some friction given that we implement d3d9 APIs using views internally. In particular, 4caa93a3 inadvertently breaks clears of d3d1-9 YUV surfaces. The two formats have almost no actual functionality in common, so address this by using two different format enumerants. Fixes: 4caa93a3
-
Instead of linking both versions to version 47.
-
This reflects native, and may be necessary to reflect changes in behaviour before version 33 (although no such differences are yet known to matter). By supplying the D3DX SDK version we also now reflect differences in behaviour between different D3DX versions. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=33770
-
-
-
-
-
-
-
Test additional subtypes without MF_MT_USER_DATA.
-
winebth.sys: Update properties for tracked remote devices on receiving PropertiesChanged for org.bluez.Device1 objects from BlueZ. When the unix bluez watcher receives a PropertiesChanged signal for a org.bluez.Device1 object, queue a BLUETOOTH_WATCHER_EVENT_TYPE_DEVICE_PROPERTIES_CHANGED event, containing the changed and invalidated properties for the associated remote device.
-
winebth.sys: Only set the updated properties for local radios on BLUETOOTH_WATCHER_EVENT_TYPE_RADIO_PROPERTIES_CHANGED. A PropertiesChanged signal only contains the updated properties for the object, so the PE driver should only modify the properties which have their corresponding mask bit set. Additionally, unset the mask bits for invalidated properties.
-
-
On BlueZ, "Trusted" devices are saved to the local cache, which makes them equivalent to Win32 devices with the BDIF_PERSONAL flag set.
-
-
-
-
-
-
-