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
I think it would be very nice to have something like that to reduce the burden of implementing COM interfaces. This shows for instance on the windows.gaming.input module a 30% LoC reduction (from ~6800 to ~4700), even though the module already had a boilerplate helper macros already.
The MR introduces macros to automatically implement each IUnknown method, as well as all of them at once. It also includes a helper to implement IInspectable methods at once, as well as macros to forward both interface methods to a base interface or an outer object. Last, it provides higher-level macros to implement a main interface and any number of sub interfaces and generate IUnknown, forwarding and vtables for all of them at once, with IInspectable support when needed.
It uses widl to generate additional per-interface macros, for things like inheritance and vtable generation. The rest of the macros are otherwise shared in a Wine-specific header.
The implementation is split to show individual macro being used, although they are later replaced by higher-level macros. The individual helpers are still useful in some corner cases where specific behavior needs to be implemented, or for aggregating classes.
--
v6: widl: Generate return traces for COM classes.
widl: Generate method traces for COM classes.
widl: Generate COM class code for IClassFactory.
windows.gaming.input: Generate the provider COM class.
windows.gaming.input: Generate the vector COM classes.
windows.gaming.input: Generate the async COM classes.
windows.gaming.input: Generate the manager COM classes.
windows.gaming.input: Generate the force feedback COM classes.
windows.gaming.input: Generate the ramp effect COM classes.
windows.gaming.input: Generate the periodic effect COM classes.
windows.gaming.input: Generate the constant effect COM classes.
windows.gaming.input: Generate the condition effect COM classes. (broken)
windows.gaming.input: Generate the racing wheel COM classes.
windows.gaming.input: Generate the gamepad COM classes.
windows.gaming.input: rename controller to raw_controller
widl: Generate initializers for COM classes.
widl: Generate vtables for COM classes.
widl: Generate impl unwrappers for COM classes.
widl: Generate QueryInterface for COM classes.
widl: generate some query interface helpers
widl: Generate default IUnknown / IInspectable implementation.
widl: Generate IUnkonwn and IInspectable forwarding for COM classes.
widl: Generate impl_from helpers for COM classes.
windows.gaming.input: Use the generated COM class structs.
widl: Generate some structs for COM classes.
widl: Parse a widl-specific impl attribute on structs.
makedep: Generate some new impl.h headers from the IDLs.
widl: Generate some new impl.h headers from the IDLs.
windows.gaming.input: Use a separate interface for IAgileObject.
widl: Introduce a new append_declspec helper.
widl: Inline write_args into write_type_right.
widl: Cleanup indentation and variables in write_type_right.
widl: Remove now unnecessary write_callconv argument.
widl: Introduce a new append_type_left helper.
widl: Split write_type_left into a write_type_definition_left helper.
widl: Cleanup indentation and variables in write_type_left.
widl: Introduce a new write_record_type_definition helper.
widl: Move some type name construction out of write_type_left.
widl: Remove unnecessary recursion for TYPE_BITFIELD.
widl: Introduce a new append_basic_type helper.
widl: Wrap strappend parameters in a new struct strbuf.
This merge request has too many patches to be relayed via email.
Please visit the URL below to see the contents of the merge request.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6207
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
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
If a session is shutdown when its command_state is already COMPLETE,
session_handle_source_shutdown calls session_set_stopped, which calls
session_command_complete which will submit the op at the head of commands again,
despite it having already been submitted.
Given that only the op at the head of commands can be in the submitted state,
tracking it as a command state makes more sense to me. And if the command state
is SUBMITTED we know not to submit the op again.
* * *
Superceded !8270
--
v3: mf: Add a SUBMITTED command state to avoid multiple submission of the same op.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8722
On Fri Aug 8 12:08:40 2025 +0000, Rémi Bernon wrote:
> 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.
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,
* 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 switches the breakage from permanently on to permanently 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 only for only that device).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8605#note_112517