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

[PATCH v5 0/2] MR8178: user32: Fix uiLengthDrawn calculation in DrawTextExW().
by JiangYi Chen (＠meshine) 10 Aug '25

10 Aug '25

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. -- v5: user32: Fix uiLengthDrawn calculation in DrawTextExW(). user32/tests: Add some tests for uiLengthDrawn calculation in DrawTextExW(). https://gitlab.winehq.org/wine/wine/-/merge_requests/8178

2 2

Re: [PATCH v4 0/1] MR8178: user32: Fix uiLengthDrawn calculation in DrawTextExW().
by Zhiyi Zhang (＠zhiyi) 10 Aug '25

10 Aug '25

On Sun Aug 10 10:13:54 2025 +0000, JiangYi Chen wrote: > If the `(LPWSTR)` cast in `(LPWSTR)L"a 1\tb2c3"` is removed, the > compilation warning shown in the image below will appear during > compilation. I don't want to add constant string definitions like > `tabstring[]` inside the test_DrawTextCalcRect() function, so I directly > used the `(LPWSTR)` cast. > ![1](/uploads/8b1b93ebe967e107fcd7a1201f8d2dd3/1.png) Okay. Let's keep it then. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8178#note_112570

1 0

Re: [PATCH v4 0/1] MR8178: user32: Fix uiLengthDrawn calculation in DrawTextExW().
by JiangYi Chen (＠meshine) 10 Aug '25

10 Aug '25

On Fri Aug 8 09:27:01 2025 +0000, Zhiyi Zhang wrote: > You can remove `(LPWSTR)` cast. If the `(LPWSTR)` cast in `(LPWSTR)L"a 1\tb2c3"` is removed, the compilation warning shown in the image below will appear during compilation. I don't want to add constant string definitions like `tabstring[]` inside the test_DrawTextCalcRect() function, so I directly used the `(LPWSTR)` cast. ![1](/uploads/8b1b93ebe967e107fcd7a1201f8d2dd3/1.png) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8178#note_112569

1 0

[PATCH v3 0/1] MR8178: user32: Fix the number of characters processed by DrawTextExW.
by JiangYi Chen (＠meshine) 10 Aug '25

10 Aug '25

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> -- v3: user32: Fix the number of characters processed by DrawTextExW. https://gitlab.winehq.org/wine/wine/-/merge_requests/8178

2 1

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

09 Aug '25

For reference, [here](https://gitlab.winehq.org/wine/wine/-/blob/6f06f4d50c2042a8d68bdb97c5… is where I hard coded the initial value of `DIPROP_AUTOCENTER` to `DIPROPAUTOCENTER_ON` on for all devices. I expect it wouldn't be a big deal to change this to call a function that does something more intelligent. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8605#note_112553

1 0

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

09 Aug '25

I initially thought there was an impedance mismatch between the HID based wine bus and autocenter as well due to autocenter not being part of the USB PID specification. That is, autocenter is communicated implicitly to the backend by HID messages over the bus - the front end sending a PID reset over the bus tells the backend it should also turn autocenter on, and - the front end sending sending PID a stop all effects over the bus tells the backend it should also turn autocenter off. So, if `DIPROP_AUTOCENTER` is `DIPROPAUTOCENTER_ON`, acquisitions of the device causes the front end to just send a reset. This triggers a call to the SDL or udev input APIs in the backend to turn autocenter on, achieving the desired state. If `DIPROP_AUTOCENTER` is `DIPROPAUTOCENTER_OFF`, then acquisitions of the device causes the front end to send a reset followed by a stop all effects. This triggers calls to the SDL or udev input APIs in the backend to to first turn autocentering on (the rest) and then off (the stop all effects), achieving the final state of off as desired. These messages are also how it works in some PID devices (e.g., the Sidewinder 2) meaning autocenter also works on these devices under the udev hidraw backend. As autocenter wasn't explicitly covered in the PID specification, the SDL and udev input backends are actual the preferred option for supporting it because autocentering is done via API call that dispatches to a kernel driver that knows how to correctly tell the device to turn autocentering on or off (grepping the kernel for autocenter and looking through the hits reveals there are many ways this in done). The udev hidraw backend is not preferred as it is only (1) good for PID devices that (2) have no PID quirks that need working around and (3) do autocenter on on reset and off on stop all effects. For this reason we don't want to strip autocenter support out of the SDL and udev backends as this is where it should really shine and just work for everything because the kernel drivers can make it work for each device. Going back to how the front end and the back end communicate implicitly about autocenter, the reason I initially thought there was an impedance mismatch was because there appeared to be no way to communicate a leave-it-as-it-is situation. I believed this was be required if `DIPROP_AUTOCENTER` had never been set by the program. At some point, though, I realized, the front end never wants to communicate a leave-it-as-it-is to the backend as `DIPROP_AUTOCENTER` is always set to either `DIPROP_AUTOCENTER` was `DIPROPAUTOCENTER_ON`, so there is no impedance mismatch. That is, under direct input, `DIPROP_AUTOCENTER` has an initial value of either `DIPROPAUTOCENTER_ON` or `DIPROPAUTOCENTER_OFF` and programs [can retrieve it](https://learn.microsoft.com/en-us/previous-versions/windows/desktop/ee4…. It is therefore entirely feasible that a program first checks the initial state of `DIPROP_AUTOCENTER` and then only sets it if it isn't already what it wants. These programs require the front end to have chosen an initial state for `DIPROP_AUTOCENTER` and to tell the backend to set that state upon acquisition to work correctly. So there is never a time at which acquisition of the device is made and the front end doesn't have an explicit autocenter state it wants the backend to set. There is no leave-it-as-it-is case. There is no impedance mismatch. There is one issue though. We have to choose an initial value for `DIPROP_AUTOCENTER`, and we need to choose the same one Windows choose for each device. The reason is a good program would always check and set or just set regardless, but probably lots of programs don't as the developers never tested on any device that had a different initial value then they wanted under Windows. These programs are not going to work correctly under Wine if it uses a different initial value. I hard coded the initial value to `DIPROPAUTOCENTER_ON` as this is what the initial value for was for my Sidewinder 2 under Windows. What is likely needed instead is a good heuristic, special cases for outliers, and an option for the user to specify it if all else fails. I expect it is this initial value that is the problem when users are complaining about autocenter being incorrectly stuck on for their device. Either that or the kernel driver is unable to turn it off after turning it on. If broken kernel drivers are common, then we probably want a way to disable the backend API calls for some devices too. It is also true that Linux has no notion of taking ownership, so it is lacking in that regard too. This is an issue for someone wanting to simultaneously using the same FF device with two programs at once though, so I don't think it is really something that needs to be worried a lot about. If you have a device and want to see what it's initial value is and if device acquisition correctly sets autocenter in all cases for a given backend, please see my [test program](https://github.com/twhitehead/issue-wine-ff-autocenter) and give it go. Even better, send me the log file. Knowing what happens on more devices is so critical to understanding what is going on, where we are at, and how best to make everything work going forward. Thanks so much! -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8605#note_112552

1 0

[PATCH v2 0/2] MR8591: Draft: ntdll: Fill EnabledFeatures before return.
by Bernhard Übelacker 09 Aug '25

09 Aug '25

Followup to 03039ab2ee. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58335 If I observed it right we currently leave `init_xstate_features` on older computers with EnabledFeatures being zero. This leads in `__wine_syscall_dispatcher` to getting the xsave64 getting called with "$rax = 0x0", therefore e.g. xmm6 gets not saved to the stack. But later e.g. xmm6 gets restored from stack in `__wine_syscall_dispatcher` (see [__wine_syscall_dispatcher](https://gitlab.winehq.org/wine/wine/-/blob/wine-…) -- v2: ntdll/tests: Allow non-AVX CPUs in XState feature tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/8591

1 3

[PATCH 0/1] MR8591: ntdll: Fill EnabledFeatures before return.
by Bernhard Übelacker 09 Aug '25

09 Aug '25

Followup to 03039ab2ee. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58335 If I observed it right we currently leave `init_xstate_features` on older computers with EnabledFeatures being zero. This leads in `__wine_syscall_dispatcher` to getting the xsave64 getting called with "$rax = 0x0", therefore e.g. xmm6 gets not saved to the stack. But later e.g. xmm6 gets restored from stack in `__wine_syscall_dispatcher` (see [](https://gitlab.winehq.org/wine/wine/-/blob/wine-10.12/dlls/ntdll/unix/signal_x86_64.c?ref_type=tags#L2774-L2882)) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8591

6 19

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

09 Aug '25

On Fri Aug 8 21:48:51 2025 +0000, Tomasz Pakuła wrote: > Nothing is broken, the autocenter is just left to the drivers. The > autocenter philosphy is very different on Linux vs windows where Setting > an autocenter effect outside of the main program is a valid use-case. > Linux doesn't even have a notion of acquiring FFB devices and you're > free to send in effects from different. > Yes, this change fixes the behavior of a lot of ffb devices for a lot of > users, as can be seen here: https://github.com/ValveSoftware/Proton/issues/8395 > Until we have a better Linux ffb api that's closer to the functionality > of full PID protocol/dinput ffb api this is the best compromise. If you > truly, really, just have to have autocenter on reset without using > hidraw, please make an issue in the `hid-universal-pidff` development > repository and we could upstream it. We're already tracking the number > of effects and we could enable autocenter when there are none. @TomaszPakula we are not on the same page. You are focused on particular programs and devices. Under Windows they had autocenter off. Under Wine they had autocenter on. You fixed this by removing `DIPROP_AUTOCENTER` support from the udev input and SDL backends. The programs now work with the devices as under Windows so you say nothing was broken. I understand that. It isn't my perspective though. I put a lot of work into making `DIPROP_AUTOCENTER` work for all the backends. I want to fix whatever is wrong with it in the udev input and SDL backends for your programs and input devices rather than rip it out. If I can do this, then we all win, and Wine becomes that much better, so please give me a chance. To that end, could you please run the [test program](https://github.com/twhitehead/issue-wine-ff-autocenter) with a version of Wine before the merge request was included, as well as under Windows, and report back what happens for you device. Thank you! -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8605#note_112540

1 0

Re: [PATCH v7 0/1] MR8605: winebus: Do not touch autocenter on device reset and stop all effects
by Tomasz Pakuła 08 Aug '25

08 Aug '25

On Fri Aug 8 21:48:51 2025 +0000, Tyson Whitehead wrote: > Right. That makes sense. I don't think, however, that this merge request > makes any devices work better. Instead I believe it just breaks > `DIPROP_AUTOCENTER` support in a lot of cases. > Specifically, wrt to devices that hidraw doesn't work (e.g., so UDEV > (input) or SDL are the only option) I expect > * all non-HID driver devices for which the kernel driver supported > autocenter (e.g., the I-FORCE) are now broken wrt `DIPROP_AUTOCENTER` > for all buses > with respect to devices where hidraw wouldn't work with autocenter, but > UDEV (input) or SDL would (e.g., devices that that don't turn autocenter > on on reset and off on stop all effects) > * all HID non-pidff driver devices for which the kernel driver support > autocenter (e.g., the Logitech WingMan Force) are now broken wrt > `DIPROP_AUTOCENTER` for all buses > and with respect to devices where hidraw does work with autocenter > (e.g., devices that do turn autocenter on on reset and off on stop all effects > * all HID pdiff driver devices for which the kernel driver supported > autocenter (e.g., the USB Sidewinder 2) are broken wrt > `DIPROP_AUTOCENTER` for all buses but hidraw > Unfortunately I don't have any of these devices to test apart for the > USB Sidewinder 2 to prove this. The best I could do was to do was write > a [test program](https://github.com/twhitehead/issue-wine-ff-autocenter) > so people with them could check. It sounds like @TomaszPakula has some > wheels to test. And perhaps @JacKeTUs has some non-HID devices to test > too or knows someone who does? I would really appreciate it if everyone > could test their device as, if I am correct, there is a lot of breakage here. > The only two things I see it _fixing_ is when autocenter is desired to > be off and > * the program assumes `DIPROP_AUTOCENTER` is off by default (which it > wasn't under Wine), doesn't check or set it, and so winds up with it on, or > * the kernel driver claims autocenter support but doesn't actually > support disabling it so it gets enabled (on the internal reset) and then > winds up stuck on despite being told to turn off (on the internal stop > all effects). > Of course, if either of these circumstances exist, this doesn't really > fix anything. It just shuffles the breakage between on and off. Hence > the italics. > My expectation is that this merge request originated out of the first of > these. That is easy to fix once verified (please run the test program!), > and I would be happy to put together a merge request for it. With regard > to the second, if such drivers exist, it a kernel driver bug and needs > to be fixed there (or, worst case, an if statement can be be added to > Wine to disable autocenter support under UDEV (input) and SDL for only > that device). Nothing is broken, the autocenter is just left to the drivers. The autocenter philosphy is very different on Linux vs windows where Setting an autocenter effect outside of the main program is a valid use-case. Linux doesn't even have a notion of acquiring FFB devices and you're free to send in effects from different. Yes, this change fixes the behavior of a lot of ffb devices for a lot of users, as can be seen here: https://github.com/ValveSoftware/Proton/issues/8395 Until we have a better Linux ffb api that's closer to the functionality of full PID protocol/dinput ffb api this is the best compromise. If you truly, really, just have to have autocenter on reset without using hidraw, please make an issue in the `hid-universal-pidff` development repository and we could upstream it. We're already tracking the number of effects and we could enable autocenter when there are none. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8605#note_112532

1 0