August 2025 - Wine-GitLab - list.winehq.org

Re: [PATCH v3 0/2] MR8737: dxcore: Add support for DriverDescription property. - approved
by Alexandre Julliard (＠julliard) Aug. 8, 2025

Aug. 8, 2025

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8737

1 0

Re: [PATCH v3 0/7] MR8739: mshtml: Misc attribute node tests and fixes. - approved
by Alexandre Julliard (＠julliard) Aug. 8, 2025

Aug. 8, 2025

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8739

1 0

Re: [PATCH v2 0/7] MR8740: opengl32: Use generated thunks for functions returning strings. - approved
by Alexandre Julliard (＠julliard) Aug. 8, 2025

Aug. 8, 2025

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8740

1 0

Re: [PATCH v2 0/1] MR8738: d3d12: Support creating devices using dxcore adapters. - approved
by Alexandre Julliard (＠julliard) Aug. 8, 2025

Aug. 8, 2025

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8738

1 0

Re: [PATCH v7 0/1] MR8605: winebus: Do not touch autocenter on device reset and stop all effects
by Rémi Bernon Aug. 8, 2025

Aug. 8, 2025

On Fri Aug 8 11:42:41 2025 +0000, Tyson Whitehead wrote: > I compiled and tested the `master` branch of wine on my machine and it > is broken exactly like I expected it would be under Linux 6.12.4. > That is, wine has went from all three busses working and giving the same > results as Windows to now only `hidraw` working. For both the the UDEV > (input) and SDL backends, autocenter is now permanently stuck on for all > test cases using my [test > program](https://github.com/twhitehead/issue-wine-ff-autocenter/tree/master… > (i.e., on regardless of what is specified or not for > `DIPROP_AUTOCENTER`). It short, this merge request has introduced a regression. > Currently updating my distro to the latest to see what effects > @TomaszPakula's merged kernel driver work might have. I almost certain > it will also be broken as well, although it may switch for permanently > stuck on to permanently stuck off depending on whether or not his work > changed the kernel default from on to off. I'll report back. The evdev and SDL backends suffer from impedence mismatch and they cannot work identically to hidraw on every possible device. You should use hidraw with your device, and every time it is supported, and evdev / SDL for every other devices where it's not. Then making sure evdev / SDL works best for devices without the hidraw alternative is more important than making all the backends work similarly for devices which can already be used with hidraw. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8605#note_112449

1 0

Re: [PATCH v7 0/1] MR8605: winebus: Do not touch autocenter on device reset and stop all effects
by Tyson Whitehead (＠twhitehead) Aug. 8, 2025

Aug. 8, 2025

On Thu Aug 7 22:34:16 2025 +0000, Tyson Whitehead wrote: > 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 > ``` I compiled and tested the `master` branch of wine on my machine and it is broken exactly like I expected it would be under Linux 6.12.4. That is, wine has went from all three busses working and giving the same results as Windows to now only `hidraw` working. For both the the UDEV (input) and SDL backends, autocenter is now permanently stuck on for all test cases using my [test program](https://github.com/twhitehead/issue-wine-ff-autocenter/tree/master… (i.e., on regardless of what is specified or not for `DIPROP_AUTOCENTER`). It short, this merge request has introduced a regression. Currently updating my distro to the latest to see what effects @TomaszPakula's merged kernel driver work might have. I almost certain it will also be broken as well, although it may switch for permanently stuck on to permanently stuck off depending on whether or not his work changed the kernel default from on to off. I'll report back. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8605#note_112448

1 0

[PATCH v2 0/2] MR8718: win32u: Create Vulkan swapchains with VkSwapchainPresentScalingCreateInfoEXT when the surface will be scaled.
by Brendan Shanks (＠bshanks) Aug. 8, 2025

Aug. 8, 2025

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

3 4

[PATCH v2 0/1] MR8178: user32: Fix the number of characters processed by DrawTextExW.
by JiangYi Chen (＠meshine) Aug. 8, 2025

Aug. 8, 2025

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

3 9

[PATCH v3 0/6] MR8445: server: Create inproc sync events for message queues.
by Rémi Bernon Aug. 7, 2025

Aug. 7, 2025

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

4 12

[PATCH v2 0/2] MR8737: dxcore: Add support for DriverDescription property.
by Nikolay Sivov (＠nsivov) Aug. 7, 2025

Aug. 7, 2025

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- v2: dxcore: Add support for DriverVersion property. dxcore: Add support for DriverDescription property. https://gitlab.winehq.org/wine/wine/-/merge_requests/8737

2 2