Otherwise it's pointless to have it configurable.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Some games expect the DS4 gamepads to be named like native drivers, and
they aren't detected xinput-compatible when access through hidraw, so
it's not possible to override their product string in winexinput.sys.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
For the same reason we don't send WM_INPUT messages.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Based on a patch from Ivo Ivanov <logos128@gmail.com>.
The issue causes severe skipping and non smooth movement tracking in
apps/games, when the HidP/HidD APIs are used to control the device
(joysticks, controllers, steering wheels, etc.).
Usually such devices use constant stream of INPUT reports to report
their coords, so any report skipping or change of the sequence,
when the interested apps are reading, would lead to such issues.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51824
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Based on a patch from Ivo Ivanov <logos128@gmail.com>.
Instead of using the descriptor input report length, which is the
maximum length of all input reports.
Tests show that the reports should be dropped, in non-polled mode, when
their length is invalid, but we were dropping too many of them.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51828
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
As it now also queues IRPs.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Aric Stewart <aric@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Since d15358518b83384b137e81b71729c4f47fac0665 we only complete one
pending IRP per HID report, but there may be more than one IRP queued,
from different readers.
This causes trouble and report interleaving when more than one reader
accesses a device at a time. We need to complete only one for each
report queue instead.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Aric Stewart <aric@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
And not for the internal WINEXINPUT devices.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Although these devices will be HID compatible we need to not have them
listed on the HID class, as they should only be used internally by Wine
XInput implementation.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Instead of requiring the ring buffer to keep previously read packets.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
From HID_IOCTL_GET_INPUT_REPORT code, to factor report buffer transfer,
and use it for HID_IOCTL_GET_FEATURE.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Instead of STATUS_BUFFER_TOO_SMALL when input report buffer length is
less than InputReportByteLength.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Alexandre Julliard