This fixes several games (e.g. ICEY) not working well with DS4 gamepad
over bluetooth, as we fixup the input report sizes, and the game expects
them to be longer.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
And add some warnings when we do.
This otherwise makes the effect state reports from the tests to be
always dropped as they are shorter than the returned length, which is
the read buffer size and the maximum input report length.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
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>
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>
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>
Handle IRP_MN_SURPRISE_REMOVAL and notify device thread to stop it, but
only wait for it in IRP_MN_REMOVE_DEVICE, as it's probably waiting for
an IRP sent to the lower driver, which needs to be notified of removal
too first.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Rémi Bernon