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
On Thu Aug 7 19:15:21 2025 +0000, Tyson Whitehead wrote:
> I hacked together [some ugly Windows
> code](https://github.com/twhitehead/issue-wine-ff-autocenter) to test
> all possible setting of `DIPROP_AUTOCENTER` (not set, set
> `DIPROPAUTOCENTER_OFF`, and set `DIPROPAUTOCENTER_ON`). There is a
> precompiled version in the `bin` directory. It
> * gets the initial `DIPROP_AUTOCENTER` value and show that in a message box
> * acquires the device with the intial `DIPROP_AUTOCENTER` and prompts to continue,
> * acquires the device after setting `DIPROP_AUTOCENTER` to
> `DIPROPAUTOCENTER_OFF` and prompts to continue, and
> * acquires the device after setting `DIPROP_AUTOCENTER` to
> `DIPROPAUTOCENTER_ON` and prompts to continue.
> For the original Wine code, there was perfect agreement using my USB
> Sidewinder 2
> * the default value is `DIPROPAUTOCENTER_ON`,
> * when acquired without setting `DIPROP_AUTOCENTER` the default value, I
> feel the spring effect,
> * when acquired after explicitly setting `DIPROPAUTOCENTER_OFF`, I feel
> it go limp, and
> * when acquired after explicitly setting `DIPROPAUTOCENTER_ON`, I feel
> the spring effect.
> Based on this merged code, I would expect it will now be stuck in
> `DIPROPAUTOCENTER_ON` for older kernels and `DIPROPAUTOCENTER_OFF` for
> newer kernels.
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
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8605#note_112407
On Thu Aug 7 19:08:42 2025 +0000, Rémi Bernon wrote:
> Fwiw you can create different device types in the tests and check
> whether autocenter has a different default value, but I suspect like
> @TomaszPakula says, that it's just unspecified behavior. The DInput
> autocenter feature doesn't seem to be well defined, even on the HID PID
> side, and sends a generic (reset / stop all) command that drivers are
> free to interpret the way they like.
I hacked together [some ugly Windows code](https://github.com/twhitehead/issue-wine-ff-autocenter) to test all possible setting of `DIPROP_AUTOCENTER` (not set, set `DIPROPAUTOCENTER_OFF`, and set `DIPROPAUTOCENTER_ON`). There is a precompiled version in the `bin` directory. It
* gets the initial `DIPROP_AUTOCENTER` value and show that in a message box
* acquires the device with the intial `DIPROP_AUTOCENTER` and prompts to continue,
* acquires the device after setting `DIPROP_AUTOCENTER` to `DIPROPAUTOCENTER_OFF` and prompts to continue, and
* acquires the device after setting `DIPROP_AUTOCENTER` to `DIPROPAUTOCENTER_ON` and prompts to continue.
For the original Wine code, there was perfect agreement using my USB Sidewinder 2
* the default value is `DIPROPAUTOCENTER_ON`,
* when acquired without setting `DIPROP_AUTOCENTER` the default value, I feel the spring effect,
* when acquired after explicitly setting `DIPROPAUTOCENTER_OFF`, I feel it go limp, and
* when acquired after explicitly setting `DIPROPAUTOCENTER_ON`, I feel the spring effect.
Based on this merged code, I would expect it will now be stuck in `DIPROPAUTOCENTER_ON` for older kernels and `DIPROPAUTOCENTER_OFF` for newer kernels.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8605#note_112406
On Thu Aug 7 19:05:40 2025 +0000, Tomasz Pakuła wrote:
> You're thinking too much. It's no the default of the Windows/API but how
> drivers behave. A lot of wheels use custom protocol and they can do
> whatever they want with autocenter and PID wheels just don't support any
> explicit autocenter method. It's more likelay an omission on the part of
> developer that still works because wheel manufacturers work around it.
> The current handling of autocenter is correct and works in all three
> cases (hidraw/SDL/udev).
Fwiw you can create different device types in the tests and check whether autocenter has a different default value, but I suspect like @TomaszPakula says, that it's just unspecified behavior. The DInput autocenter feature doesn't seem to be well defined, even on the HID PID side, and sends a generic (reset / stop all) command that drivers are free to interpret the way they like.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8605#note_112404
On Thu Aug 7 19:03:03 2025 +0000, Tyson Whitehead wrote:
> My thinking is that the default under Windows in `DIPROPAUTOCENTER_ON`
> for joysticks and `DIPROPAUTOCENTER_OFF` for wheels. Could this be possible?
> It would perfectly explain @TomaszPakula issue of his wheel not working
> the same under Windows (no autocentering) and Wine (autocentering) for
> his truck simulations assuming ETS2/ATS doesn't explicitly set it as the
> developers only tested wheels on Windows and therefore assumed it would
> be off.
You're thinking too much. It's no the default of the Windows/API but how drivers behave. A lot of wheels use custom protocol and they can do whatever they want with autocenter and PID wheels just don't support any explicit autocenter method. It's more likelay an omission on the part of developer that still works because wheel manufacturers work around it.
The current handling of autocenter is correct and works in all three cases (hidraw/SDL/udev).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8605#note_112403
On Thu Aug 7 18:58:37 2025 +0000, Rémi Bernon wrote:
> It is the default value because that's what makes the tests to pass.
> Setting `DIPROPAUTOCENTER_OFF` by default doesn't pass the tests. The
> tests also pass on Windows so we can conclude that it's also
> `DIPROPAUTOCENTER_ON` by default on Windows.
My thinking is that the default under Windows in `DIPROPAUTOCENTER_ON` for joysticks and `DIPROPAUTOCENTER_OFF` for wheels. Could this be possible?
It would perfectly explain @TomaszPakula issue of his wheel not working the same under Windows (no autocentering) and Wine (autocentering) for his truck simulations assuming ETS2/ATS doesn't explicitly set it as the developers only tested wheels on Windows and therefore assumed it would be off.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8605#note_112402