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>
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>
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>
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>
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>
The instance ID is only the third part of the "A\B\C" form, and must be
combined with the device ID to form the whole name for setupapi (the "device
instance ID").
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Spotted by Marcus Meissner (Coverity issue 1372459).
Signed-off-by: Aric Stewart <aric@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
We no longer track PNP devices, that is the PNP manager's job.
Signed-off-by: Aric Stewart <aric@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Rémi Bernon