If the swapchain image size is not equal to the presentation size (e.g. because of DPI virtualization or display mode change emulation), MoltenVK's `vkQueuePresentKHR` returns `VK_SUBOPTIMAL_KHR` (see [`MVKSwapchain::hasOptimalSurface()`](https://github.com/KhronosGroup/MoltenVK/blob/a046e779df332f5c23a03df1cb6de4607847d6e0/MoltenVK/MoltenVK/GPUObjects/MVKSwapchain.mm#L132). I can see this with a vkcube hacked to run in fullscreen, and it's especially problematic with wined3d which recreates the swapchain on `VK_SUBOPTIMAL_KHR` (every frame).
Create the swapchain with `VkSwapchainPresentScalingCreateInfoEXT` when the window is being scaled to avoid this. I'm not sure if it's proper to be enabling the extension in winevulkan and then using it in win32u, but I don't see an obvious way to hook `vkCreateDevice` in win32u.
--
v2: win32u: Create Vulkan swapchains with VkSwapchainPresentScalingCreateInfoEXT when the surface will be scaled.
winevulkan: Enable VK_EXT_swapchain_maintenance1 when available.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8718
`IMap` is implemented on top of a `rb_tree` guarded with an `SRWLOCK`. We need the map to be thread safe as:
* `PropertySet` is marked as `IAgileObject`.
* I plan to use `PropertySet` as the backing store for [`DeviceInformation::Properties`](https://learn.microsoft.com/en-us/uwp/api/windows.devices.enumeration.deviceinformation.properties?view=winrt-26100). These properties can be updated by apps after receiving an [`Updated`](https://learn.microsoft.com/en-us/uwp/api/windows.devices.enumeration.devicewatcher.updated?view=winrt-26100#windows-devices-enumeration-devicewatcher-updated) event from the device watcher with [`DeviceInformation::Update`](https://learn.microsoft.com/en-us/uwp/api/windows.devices.enumeration.deviceinformation.update?view=winrt-26100). The current `DeviceWatcher` implementation dispatches the event delegates for `Update` from a separate thread.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8685
uiLengthDrawn should represent the number of characters that have been processed.
However, the original implementation uses len (the count of displayed characters
in the current line), which is not accurate.
When text requires line breaks or special processing (such as adding an ellipsis),
the actual number of processed characters may differ from the number of displayed
characters.
When the DT_CALCRECT flag is absent, len gets decremented to 0 during the drawing loop.
Consequently, uiLengthDrawn becomes inaccurate since it relies on len's value for statistics.
@zhiyi @julliard
Signed-off-by: chenjiangyi <chenjiangyi(a)uniontech.com>
--
v2: user32: Fix the number of characters processed by DrawTextExW.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8178
Fix a regression from 31fda1f4, which allowed the visible rect to be larger than the monitor rect.
After 31fda1f4, CHRONO TRIGGER (613830) sets a window rect slightly larger than the monitor rect and
will change the window rect to the rect it previously set if the game detects a different window rect.
Adding __NET_WM_STATE_FULLSCREEN will cause WMs to move the window to cover exactly the monitor rect.
So the window rect will be repeatedly changed by the WM and the game, causing a flickering effect. Limit
fullscreen visible rects to the virtual screen rect so that the visible rects in winex11.drv are of
the same size as the monitor rect. Thus, adding __NET_WM_STATE_FULLSCREEN won't trigger a size change.
--
v2: winex11.drv: Limit fullscreen visible rects to the virtual screen rect.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8731
Supersedes https://gitlab.winehq.org/wine/wine/-/merge_requests/8338
The header cannot seem to be generated easily from an IDL, gameinput has some unfortunate versioning which reuses the same identifiers across versions, in an incompatible way and sometimes sharing only a subset of them (for instance enum values), and uses C++ namespaces to separate versions.
The implementation needs to support every interface version at the same time, which is implemented by wrapping identifiers and adding version suffixes whenever it is included by the implementing code. The tests are also using that so we can tests multiple versions in the same file.
--
v3: dinput/tests: Add some gameinput tests.
gameinput: Introduce new DLL.
include: Add gameinput.h.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8733
avdec_h264 will fail when combined with h264parse and a drain request
is made during caps neg.
To fix this, a capsfilter was added to force a stream-format of
byte-stream for all h.264 decoders. However, this introduced a new
issue with the vtdec element, as it only supports the avc stream-format.
Therefore, this patch looks to address both problems by only introducing
the capsfilter when the avdec_h264 element is used.
It also removes the stream-format and alignment requirements from
the parsed caps, applying them only to the capsfilter.
--
v2: winegstreamer: Only add the capsfilter for avdec_h264.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8719
The message queue needs both an inproc sync, to wake inproc waits on a message and trigger a server request, and a server sync, for when the wait is only on the queue and should be optimized into a single server request.
It could be better to avoid a dedicated request to retrieve the queue inproc sync fd, for instance by sending an fd on thread init, but we can use this to duality to gradually introduce inproc syncs requests instead and avoid dead code (even though the code ultimately returns STATUS_NOT_IMPLEMENTED for now). We can change the way queue inproc sync fds are retrieved later on.
--
v3: ntdll: Check inproc sync handle access rights on wait.
server: Add a request to retrieve the inproc sync fds.
server: Create inproc sync events for message queues.
ntdll: Retrieve and cache an ntsync device on process init.
ntdll: Add stub functions for in-process synchronization.
ntdll: Add some traces to synchronization methods.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8445
On Thu Aug 7 19:21:24 2025 +0000, Tomasz Pakuła wrote:
> This is not a wine issue though and I think you're still missing the
> dofference between hidraw and SDL/udev buses.
> Your device will work perfectly with hidraw as it goes around system
> drivers and in this casez wine handles THE driver. Cheers
I wrote the `DIPROP_AUTOCENTER` implementation and the test cases for it and believe I came to understand it then. It's been a bit, but, IIRC, the bus protocol is HID messages. This is what the dinput code talks. The backends interpret them. For hidraw it pretty much passes them on. For UDEV (input) and SDL it interpreters to the native API calls.
I have tested my device using the code I posted with all the backends by setting the `DisableHidraw`, `DisableInput`, and `Enable SDL` registry entries. With wine 10.0 it agrees perfectly with what Windows does. I don't think this will be the case anymore now that this merge request has been accepted. I could be wrong though. I will compile it up and try.
Here is the relevant WINEDEBUG=+hid log line show the USB Sidewinder 2 (045e:001b) being taken by each backend under Wine 10.0 when running my test program. With hidraw (requires adding `rw` access to the relevant `/dev/hidraw*` device)
```
00bc:trace:hid:udev_add_device udev "/dev/hidraw13" syspath /sys/devices/pci0000:00/0000:00:14.0/usb3/3-11/3-11:1.0/0003:045E:001B.02B1/hidraw/hidraw13
...
00bc:trace:hid:bus_main_thread creating hidraw device 045e:001b with usages 0001:0004
00bc:trace:hid:bus_create_hid_device desc {vid 045e, pid 001b, version 0a00, input 0, uid 00000000, is_gamepad 0, is_hidraw 1, is_bluetooth 0}, unix_device 0x7e503200
```
with UDEV (input) (picks up twice as both `/dev/event*` and `/dev/js*` devices)
```
00c0:trace:hid:udev_add_device udev "/dev/input/event30" syspath /sys/devices/pci0000:00/0000:00:14.0/usb3/3-11/3-11:1.0/0003:045E:001B.02B0/input/input1990/event30
...
00c0:trace:hid:udev_add_device udev "/dev/input/js1" syspath /sys/devices/pci0000:00/0000:00:14.0/usb3/3-11/3-11:1.0/0003:045E:001B.02B0/input/input1990/js1
...
00c0:trace:hid:bus_main_thread creating non-hidraw device 045e:001b with usages 0001:0005
00c0:trace:hid:bus_create_hid_device desc {vid 045e, pid 001b, version 0100, input 0, uid 00000000, is_gamepad 0, is_hidraw 0, is_bluetooth 0}, unix_device 0x7e50bcb0
...
00c0:trace:hid:bus_main_thread creating non-hidraw device 045e:001b with usages 0001:0005
00c0:trace:hid:bus_create_hid_device desc {vid 045e, pid 001b, version 0a00, input 0, uid 00000000, is_gamepad 0, is_hidraw 0, is_bluetooth 0}, unix_device 0x7e55bd90
```
and with SDL
```
00bc:trace:hid:sdl_add_device Making up serial number for Microsoft SideWinder Force Feedback 2 Joystick: 030043cf5e0400001b00000000010000.1
...
00bc:trace:hid:bus_main_thread creating non-hidraw device 045e:001b with usages 0001:0004
00bc:trace:hid:bus_create_hid_device desc {vid 045e, pid 001b, version 0100, input -1, uid 00000000, is_gamepad 0, is_hidraw 0, is_bluetooth 0}, unix_device 0x7e5bc630
```
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8605#note_112410