As documented on MSDN, and as testing shows.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
And internal hid_value_caps struct, and use them to store items and
usages.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Buttons are really just values with BitSize == 1, and having a union for
that makes the code more complicated than it needs.
We'll simplify the code a lot using HIDP_VALUE_CAPS everywhere, as the
two structure types are compatible.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
When INPUT type is INPUT_HARDWARE and hi.uMsg is WM_INPUT_DEVICE_CHANGE,
the RAWINPUT structure usage is a non-standard extension for Wine
internal usage:
* header.wParam contains the message GIDC_ARRIVAL / GIDC_REMOVAL wparam,
* hid.bRawData contains two words, which are the HID device UsagePage
and Usage words, instead of a real HID report.
This will let us use the same entry point and structures to send device
notifications as for the HID reports in the future (which will be sent
with INPUT_HARDWARE type / WM_INPUT uMsg instead).
This currently does nothing, because the INPUT_HARDWARE messages are
currently dropped, and because winedevice.exe desktop is different from
the default desktop.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=50506
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Otherwise setupapi may fail to find the device on which to set the
property. This triggers messages like the following the first time a
device is created (on prefix creation for mouse and keyboard devices):
IoSetDevicePropertyData Failed to open device, error 0xe000020b.
Some IoSetDevicePropertyData implementation detail makes it always
return successfully but it's not doing anything and user32 will then
ignore the device when it enumerates rawinput devices.
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>
This is necessary to allow the Hauppauge CIR receiver driver for cx2310x drivers
(hcw10cir.sys) to start.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The handles are just numeric values and not real object handles, they
are used in the hDevice field of the RAWINPUTHEADER struct.
They will also be used as an HID rawinput device array index on the
server side.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=50506
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Arkadiusz Hiler <ahiler@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Doing otherwise may result in memory corruption. The lower driver should complete its IRPs on device removal anyway.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
We can rely on ntoskrnl to do this for us.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
DualSense controller's report descriptor comes with a 1 bit vendor specific
(Usage Page & Usage) element repeated through 'report count'.
Those were correctly interpreted as non-ranged buttons (exposed as button caps
with appropriate usage values) but their size was incorrectly assumed to be 1
ignoring the 'report count'.
Because of that the InputReportByteLength is miscalculated as 63 instead of
64. If the buffer passed to HidD_GetInputReport() is allocated using that
value the call will fail with ERROR_INSUFFICIENT_BUFFER.
This change fixes the above and cleans up the code a bit so the size for each
case is calculated directly from the count and size instead of using the
values that were derived from them.
Signed-off-by: Arkadiusz Hiler <ahiler@codeweavers.com>
Signed-off-by: Aric Stewart <aric@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Rémi Bernon