Some games are checking the hid product string of connected gamepads in
order to decide whether or not to activate rumble.
Wine usually delegates these queries to the backend driver, but they
don't always report the same product strings as on Windows. This will
allow to override backend strings with the actual strings as reported
by native drivers.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Some games are using the HID device id as the gamepad index for xinput
API. When hotplugging devices, SDL increases its instance id and it
doesn't match anymore with xinput gamepad numbers.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
As we are going to reuse the same device id when re-plugging a
previously plugged SDL controller, the device interfaces are still
present in the tree and IoRegisterDeviceInterface was not updating the
device pointer.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This makes no logical sense, but the native AVI splitter never sets this field.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
For instance winebus driver is sometimes referred as WineBus, when
loaded by winedevice.exe, and sometimes as winebus, when loaded from
devices. This makes Wine try to load it twice and initializes the
backend twice as well.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
If a window with an OpenGL surface attached is reparented as a child window,
and then reparented as a top-level window, so that its whole window is
destroyed and then recreated, it will be recreated with the colormap of its
child window, which more than likely has a different visual. This violates
the X11 specification, which states that a window's colormap must have the
same visual as the window itself, and causes the X server to return BadMatch
to the CreateWindow request.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This is required to correctly support out reference parameters,
otherwise server method receives not initialized pointers during
the CALLSERVER phase and crashes.
Signed-off-by: Dmitry Timoshkov <dmitry@baikal.ru>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
RPC_CONTEXT_HANDLE_FLAGS contain the values RPC_CONTEXT_HANDLE_SERIALIZE
or RPC_CONTEXT_HANDLE_DONT_SERIALIZE, however all the calls to underlying
binding->Assoc are guarded by a critical section, so it's redundant to
take any action about passed in Flags parameter.
Signed-off-by: Dmitry Timoshkov <dmitry@baikal.ru>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Contains tests added by Jeff Smith <whydoubt@gmail.com>
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Jeff Smith <whydoubt@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
When the same thread repeatedly calls ClipCursor, a message window is
created for every call, then stored in x11drv_thread_data->clip_hwnd.
The WM_X11DRV_CLIP_CURSOR notification is then sent to the desktop
window, then to the previous clipping thread in order for it to destroy
its clip_hwnd. But as the clipping thread is the same, and because
x11drv_thread_data->clip_hwnd has been overwritten, it does not satisfy
the "hwnd == data->clip_hwnd" condition and the window leaked.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Nikolay Sivov