Hi,
It looks like your patch introduced the new failures shown below.
Please investigate and fix them before resubmitting your patch.
If they are not new, fixing them anyway would help a lot. Otherwise
please ask for the known failures list to be updated.
The full results can be found at:
https://testbot.winehq.org/JobDetails.pl?Key=118690
Your paranoid android.
=== w10pro64 (64 bit report) ===
user32:
win.c:4558: Test failed: hwnd 00000000000B0234/00000000000B0234 message 0200
win.c:4563: Test failed: hwnd 00000000000B0234/00000000000B0234 message 0203
win.c:4567: Test failed: message 0202 available
=== w10pro64_ar (64 bit report) ===
user32:
win.c:4558: Test failed: hwnd 00000000000200D2/00000000000200D2 message 0200
win.c:4563: Test failed: hwnd 00000000000200D2/00000000000200D2 message 0203
win.c:4567: Test failed: message 0202 available
Hi,
It looks like your patch introduced the new failures shown below.
Please investigate and fix them before resubmitting your patch.
If they are not new, fixing them anyway would help a lot. Otherwise
please ask for the known failures list to be updated.
The full results can be found at:
https://testbot.winehq.org/JobDetails.pl?Key=118684
Your paranoid android.
=== w7u_adm (32 bit report) ===
user32:
win.c:1237: Test failed: wrong dwWindowStatus: 0000 != 0001 active 0149017A fg 00050124 in hook HCBT_MINMAX
=== w1064 (32 bit report) ===
user32:
win.c:10890: Test failed: pos = 014a015e
=== w10pro64_ar (64 bit report) ===
user32:
win.c:4419: Test failed: message 0200 available
win.c:4642: Test failed: hwnd 00000000000801FA/00000000000801FA message 0200
win.c:4644: Test failed: wparam 0
win.c:4655: Test failed: hwnd 00000000000801FA/00000000000801FA message 0203
win.c:4659: Test failed: message 0202 available
Hi,
It looks like your patch introduced the new failures shown below.
Please investigate and fix them before resubmitting your patch.
If they are not new, fixing them anyway would help a lot. Otherwise
please ask for the known failures list to be updated.
The full results can be found at:
https://testbot.winehq.org/JobDetails.pl?Key=118670
Your paranoid android.
=== w7u_el (32 bit report) ===
mfplat:
0884:mfplat: unhandled exception c0000005 at 71EC7D1C
Hi,
It looks like your patch introduced the new failures shown below.
Please investigate and fix them before resubmitting your patch.
If they are not new, fixing them anyway would help a lot. Otherwise
please ask for the known failures list to be updated.
The full results can be found at:
https://testbot.winehq.org/JobDetails.pl?Key=118668
Your paranoid android.
=== w7u_el (32 bit report) ===
mfplat:
0854:mfplat: unhandled exception c0000005 at 722C7D1C
Hi,
It looks like your patch introduced the new failures shown below.
Please investigate and fix them before resubmitting your patch.
If they are not new, fixing them anyway would help a lot. Otherwise
please ask for the known failures list to be updated.
The tests also ran into some preexisting test failures. If you know how
to fix them that would be helpful. See the TestBot job for the details:
The full results can be found at:
https://testbot.winehq.org/JobDetails.pl?Key=118666
Your paranoid android.
=== w10pro64_ar (64 bit report) ===
riched20:
editor.c:5552: Test failed: test paste: strcmp = 99, actual = 'cut'
editor.c:5558: Test failed: test paste: strcmp = 1, actual = 'testing'
editor.c:5573: Test failed: test paste: strcmp = 1, actual = 'testing'
Hi,
It looks like your patch introduced the new failures shown below.
Please investigate and fix them before resubmitting your patch.
If they are not new, fixing them anyway would help a lot. Otherwise
please ask for the known failures list to be updated.
The tests also ran into some preexisting test failures. If you know how
to fix them that would be helpful. See the TestBot job for the details:
The full results can be found at:
https://testbot.winehq.org/JobDetails.pl?Key=118663
Your paranoid android.
=== w7u_el (32 bit report) ===
mfplat:
086c:mfplat: unhandled exception c0000005 at 72497D1C
Hi,
It looks like your patch introduced the new failures shown below.
Please investigate and fix them before resubmitting your patch.
If they are not new, fixing them anyway would help a lot. Otherwise
please ask for the known failures list to be updated.
The full results can be found at:
https://testbot.winehq.org/JobDetails.pl?Key=118639
Your paranoid android.
=== debian11 (build log) ===
../wine/dlls/win32u/sysparams.c:576:32: error: ‘mode_countW’ undeclared (first use in this function)
../wine/dlls/win32u/sysparams.c:578:32: error: ‘driver_extraW’ undeclared (first use in this function); did you mean ‘driver_extra’?
../wine/dlls/win32u/sysparams.c:587:18: error: too many arguments to function ‘read_adapter_mode’
Task: The win32 Wine build failed
=== debian11 (build log) ===
../wine/dlls/win32u/sysparams.c:576:32: error: ‘mode_countW’ undeclared (first use in this function)
../wine/dlls/win32u/sysparams.c:578:32: error: ‘driver_extraW’ undeclared (first use in this function); did you mean ‘driver_extra’?
../wine/dlls/win32u/sysparams.c:587:18: error: too many arguments to function ‘read_adapter_mode’
Task: The wow64 Wine build failed
Hi,
It looks like your patch introduced the new failures shown below.
Please investigate and fix them before resubmitting your patch.
If they are not new, fixing them anyway would help a lot. Otherwise
please ask for the known failures list to be updated.
The full results can be found at:
https://testbot.winehq.org/JobDetails.pl?Key=118636
Your paranoid android.
=== debian11 (32 bit report) ===
ntoskrnl.exe:
driver_pnp.c:703: Test failed: Got 1 remove events.
=== debian11 (32 bit Arabic:Morocco report) ===
ntoskrnl.exe:
driver_pnp.c:703: Test failed: Got 1 remove events.
=== debian11 (32 bit Chinese:China report) ===
ntoskrnl.exe:
driver_pnp.c:703: Test failed: Got 1 remove events.
Hi,
TL;DR: for the past few weeks, I've been trying to implement the necessary
changes to get games with DualSense support to properly work with Wine. While
I have made significant progress (I got a few patches merged that should make
a small portion of games work properly, and I wrote a few more experimental
patches that make most features work in most games), I do not think I can
finish this work, or at least not without significant help. This mail contains
details about the DualSense controller features, technical details about how
they are used in games, and discusses implementation ideas.
The DualSense controller is the Playstation 5 controller, which provides
multiple specific features, including:
- Adaptive triggers, a technology to basically let games dynamically alter the
resistance of the triggers
- Haptic feedback based on Voice Coil Motors
- an onboard speaker
Some Windows games offer support for these features when the controller is
plugged into USB (the controller itself also offers these features wirelessly,
but this involves more ad-hoc complicated protocols that I have seen no
documentation on, and are, to my knowledge, not fully supported in any other
context that on the PS5 itself).
Adaptive triggers is controlled by HID output reports, so this already works
under Wine.
VCM-based haptics and the onboard speaker work by outputing sound to an USB
audio device made available alongside the HID device. That device exposes 4
channels, with the back channels being used for the VCM-based haptics, and
the front channels used both for the (mono) speaker and the audio jack.
Different games use different methods to find that audio device for different
purposes, and that generally does not work on Wine.
I have tried understanding how a few different games find the audio device,
and here are my finding:
- Final Fantasy XIV Online finds the device by enumerating devices through
MMDevAPI and filtering on their FriendlyName property, selecting the first
that contains “Wireless Controller”. This device is then used for a stream
that is used both for the speaker output and the VCM-based haptic feedback.
- Final Fantasy VII Remake Intergrade finds the device the same way and uses
it for the VCM-based haptic feedback (to my knowledge, it does not make use
of the speaker).
- Ghostwire: Tokyo first uses SetupApi to retrieve the HID device's containerID
(specifically, it calls `SetupDiGetDeviceRegistryPropertyW` with a value of
`36` for `PropertyValue`). Then, it enumerates audio outputs through
MMDevAPI and filters on their containerID property. It selects the first one
that matches and uses it to open a stream for VCM-based haptic feedback.
To my knowledge, it does not use the speaker (although I have read it does
use it on PS5).
- Deathloop selects the audio device the same way as Ghostwire: Tokyo for the
VCM-based haptic feedback. But it also opens a second stream for use with the
speaker. I have not figured out how it does so yet, but it involves
enumerating DEVINTERFACE_AUDIO_RENDER interfaces through SetupApi. If the
audio device cannot be found this way, the stream is opened on the default
audio output instead.
I expect Deathloop and Ghostwire: Tokyo to be representative of the majority
of games with DualSense support, since they use the Wwise audio engine, which
seems to be pushed by Sony and be the preferred audio engine for PS5 games.
I have tried summing up and replicating these API calls in a short program that
can be used to test Wine's compatibility without running or owning any of these
games (it requires a DualSense controller to be plugged through USB, though):
https://github.com/ClearlyClaire/dualsense-games-compat-check
I also have recently submitted patches that should be enough for FF14 and FF7R:
- https://gitlab.winehq.org/wine/wine/-/merge_requests/338
- https://gitlab.winehq.org/wine/wine/-/merge_requests/337
I have also written patches that are enough to get VCM-based haptics to work in
Ghostwire: Tokyo and Deathloop:
- https://gitlab.winehq.org/wine/wine/-/merge_requests/359
- https://gitlab.winehq.org/wine/wine/-/merge_requests/360
- https://github.com/ClearlyClaire/wine/commit/52678e2cc77d0ad1a28649005f2745…
This last set of patches however exhibit a few issues, mainly:
- code duplication
- containerID is generated very crudely from low entropy instead of being a
proper GUID
- more importantly, the ContainerID being based entirely on the sysfs path
means it will end up being re-used across devices plugged in the same port
at different times. No two plugged-in devices will share the containerID,
but a plugged-in device may share one with devices that are not plugged in
anymore. This may actually be an issue, because the MMDevAPI device
enumeration performed by Deathloop and Ghostwire: Tokyo also lists
unavailable devices. I haven't checked, however, if it stops at the first
matching device regardless of availability, or continues enumerating if
the first device ends up being unavailable.
Attributing containerIDs the same exact way Windows does[1] is probably
unreasonably complex, as it would basically entail representing every USB
hub in the device tree.
An alternative that has been suggested is have Winebus walk the sysfs and
expose sibling audio devices whenever adding a HID device. Winebus would be
responsible for attributing the same ContainerID to those devices, and MMDevAPI
or another component would subsequently match these devices with audio-driver
exposed ones and expose the DEVINTERFACE_AUDIO_RENDER interface to SetupAPI.
This would also likely help, if not be sufficient, to get Deathloop to open
the appropriate audio device for the speaker output.
However, I have spent a few hours trying to do that and I'm getting nowhere.
Here are thoughts regarding what would be needed to achieve that:
- refactor Winebus to expose other kind of devices than HID devices.
This seems like a lot of work and I don't think I have a firm enough grasp on
how winebus or the driver stack works to do that.
- in bus_udev.c, walk the sysfs to get sibling audio devices and queue them
for addition. This is fairly easy, and I have drafted code for that.
- presumably in bus_udev.c, generate a containerID for the HID device and
its siblings. One difficulty is that `bus_udev.c` is part of the unixlib
and thus does not have access to CoCreateGuid as far as I know.
It might also be possible to make the audio devices subdevices of the HID
device and have them inherit the containerID. This doesn't replicate the
real device hierarchy but it might work.
- somehow make the sysfs path of the audio device available to SetupAPI
users. I don't think I have a good enough grasp on how everything works to
know how to do that.
- probably need to remove the audio devices when the sibling HID device is
removed
- somehow make the MMDevice sysfs path available somewhere
- have something match the MMDevAPI devices with the winebus ones (based on
sysfs), copy the containerID from SetupAPI to the MMDevice store, create
a SetupAPI subdevice with the proper instance ID and expose the AudioRender
interface.
I'm not sure what component should do that, and I don't understand Wine's
architecture enough to extend an existing component to do that or create a
new one, to be honest.
[1]: https://docs.microsoft.com/en-us/windows-hardware/drivers/install/how-conta…