Although not completely correct it should be usable already, and running
the tests would require setting the registry key before and cleaning it
up after otherwise.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
For DIPROP_RANGE property on POVs and Axes, and initialize it on
creation.
This uses the value caps physical range, as it's exactly the purpose and
we don't use it for anything else otherwise.
We'll scale values from their logical range directly anyway to save a
conversion.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Removing the trace as it can get pretty verbose otherwise.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This adds a new joystick backend, implemented on top of HID and without
any host dependencies. This will be progressively implementated, and
it's not going to be usable until at least a few more patches.
Because of that, and because it may also introduce regressions compared
to the existing backends, it is disabled by default and is optionally
enabled using the following global registry key:
[HKCU\\Software\\Wine\\DirectInput\\Joysticks]
"HID"="enabled"
Or using the corresponding AppDefaults registry key:
[HKCU\\Software\\Wine\\AppDefaults\\<app.exe>\\DirectInput\\Joysticks]
"HID"="enabled"
This setting will be removed later, when it becomes usable enough, to
use the individual device disable mechanism available in joy.cpl.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
It's accessed on Release, and this will make it easier to handle device
creation failure cleanup.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Both Acquire() and event processing with DirectInput seem to be
asynchronous. In most cases we can just keep hammering GetDeviceData()
until the event gets processed.
Things get pretty racy around Acquire() though. If we fire event right
after the device is acquired we can find ourselves in one of the three
situations:
1. Event happened after acquiring has completed - the wait will suffice.
2. Event happened before acquiring did any real work - the device will
pick up the state as if the event was processed, but there's nothing
in GetDeviceData(). Because of that we cannot fail on wait.
3. Event happened somewhere in the middle of acquiring - we ended up
both missing the event for GetDeviceData() and we have outdated
state. Sending event again will register as if the button was not
already pressed.
This change covers all three scenarios.
Signed-off-by: Arkadiusz Hiler <ahiler@codeweavers.com>
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This helps when dealing with the quirky c_dfDIJoystick2 format,
which defines all the sliders as overlapping, i.e. rglSlider[2],
rglVSlider[2], rglASlider[2] and rglFSlider[2] all share the same
offset.
With the Linux backends, if the device exposes enough axes (e.g. some
HOTAS) we end up using rglSlider.
Let's make sure we don't unnecessarily override the values there.
Signed-off-by: Arkadiusz Hiler <ahiler@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
To factor out device allocation and initialization.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Instead of a separate duplicate implementation.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Instead of sometimes using IDirectInputDevice8A.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
To make it more likely it gets focused on X11 and fix spurious failures.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
FlatOut2 demo calls FreeLibrary on the dinput8 module more times than
it has loaded it, and the module reference that the internal thread has
is getting decremented before its exit.
Having an internal window to destroy also makes it more likely to crash
as it takes more time to exit calls the window procedure function.
Waiting for the thread to complete when all the dinput instances are
destroyed ensures that the thread isn't alive when the game frees the
DLL, and prevents the thread from crashing.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=50673
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Rémi Bernon