commit feee70f4568650cf44c573488798ffc0a2faeea3 upstream.
While doing my research to improve the xpad device names I noticed
that the 1532:0037 VID/PID seems to be used by the DeathAdder 2013,
so that Razer Sabertooth instance looked wrong and very suspect to
me. I didn't see any mention in the official drivers, either.
After doing more research, it turns out that the xpad list
is used by many other projects (like Steam) as-is [1], this
issue was reported [2] and Valve/Sam Lantinga fixed it [3]:
[1]: dcc5eef0e2/src/joystick/controller_type.h (L251)
[2]: https://steamcommunity.com/app/353380/discussions/0/1743392486228754770/
[3]: https://hg.libsdl.org/SDL/rev/29809f6f0271
(With multiple Internet users reporting similar issues, not linked here)
After not being able to find the correct VID/PID combination anywhere
on the Internet and not receiving any reply from Razer support I did
some additional detective work, it seems like it presents itself as
"Razer Sabertooth Gaming Controller (XBOX360)", code 1689:FE00.
Leaving us with this:
* Razer Sabertooth (1689:fe00)
* Razer Sabertooth Elite (24c6:5d04)
* Razer DeathAdder 2013 (1532:0037) [note: not a gamepad]
So, to sum things up; remove this conflicting/duplicate entry:
{ 0x1532, 0x0037, "Razer Sabertooth", 0, XTYPE_XBOX360 },
As the real/correct one is already present there, even if
the Internet as a whole insists on presenting it as the
Razer Sabertooth Elite, which (by all accounts) is not:
{ 0x1689, 0xfe00, "Razer Sabertooth", 0, XTYPE_XBOX360 },
Actual change in SDL2 referencing this kernel issue:
e5e5416975
For more information of the device, take a look here:
https://github.com/xboxdrv/xboxdrv/pull/59
You can see a lsusb dump here: https://github.com/xboxdrv/xboxdrv/files/76581/Qa6dBcrv.txt
Fixes: f554f619b7 ("Input: xpad - sync device IDs with xboxdrv")
Signed-off-by: Ismael Ferreras Morezuelas <swyterzone@gmail.com>
Reviewed-by: Cameron Gutman <aicommander@gmail.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/5c12dbdb-5774-fc68-5c58-ca596383663e@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a17b9841152e7f4621619902b347e2cc39c32996 upstream.
Suspending and resuming the system can sometimes cause the out
URB to get hung after a reset_resume. This causes LED setting
and force feedback to break on resume. To avoid this, just drop
the reset_resume callback so the USB core rebinds xpad to the
wireless pads on resume if a reset happened.
A nice side effect of this change is the LED ring on wireless
controllers is now set correctly on system resume.
Cc: stable@vger.kernel.org
Fixes: 4220f7db1e ("Input: xpad - workaround dead irq_out after suspend/ resume")
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Link: https://lore.kernel.org/r/20220818154411.510308-3-rojtberg@gmail.com
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license as published by
the free software foundation either version 2 of the license or at
your option any later version this program is distributed in the
hope that it will be useful but without any warranty without even
the implied warranty of merchantability or fitness for a particular
purpose see the gnu general public license for more details you
should have received a copy of the gnu general public license along
with this program if not write to the free software foundation inc
59 temple place suite 330 boston ma 02111 1307 usa
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-or-later
has been chosen to replace the boilerplate/reference in 1334 file(s).
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Allison Randal <allison@lohutok.net>
Reviewed-by: Richard Fontana <rfontana@redhat.com>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070033.113240726@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Add support for the SteelSeries Stratus Duo, a wireless Xbox 360
controller. The Stratus Duo ships with a USB dongle to enable wireless
connectivity, but it can also function as a wired controller by connecting
it directly to a PC via USB, hence the need for two USD PIDs. 0x1430 is the
dongle, and 0x1431 is the controller.
Signed-off-by: Tom Panfil <tom@steelseries.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The "Xbox One PDP Wired Controller - Camo series" has a different
product-id than the regular PDP controller and the PDP stealth series,
but it uses the same initialization sequence. This patch adds the
product-id of the camo series to the structures that handle the other
PDP Xbox One controllers.
Signed-off-by: Ramses Ramírez <ramzeto@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
This fixes using the controller with SDL2.
SDL2 has a naive algorithm to apply the correct settings to a controller.
For X-Box compatible controllers it expects that the controller name
contains a variation of a 'XBOX'-string.
This patch changes the identifier to contain "X-Box" as substring. Tested
with Steam and C-Dogs-SDL which both detect the controller properly after
adding this patch.
Fixes: c1ba08390a ("Input: xpad - add GPD Win 2 Controller USB IDs")
Cc: stable@vger.kernel.org
Signed-off-by: Enno Boland <gottox@voidlinux.eu>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Fix some coding style issues reported by checkpatch.pl. Mostly brackets
in macros, spacing and comment style.
Signed-off-by: Leo Sperling <leosperling97@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Adds support for a PDP Xbox One controller with device ID
(0x06ef:0x02a4). The Product string for this device is "PDP Wired
Controller for Xbox One - Stealth Series | Phantom Black".
Signed-off-by: Francis Therien <frtherien@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Adds support for the current lineup of Xbox One controllers from PDP
(Performance Designed Products). These controllers are very picky with
their initialization sequence and require an additional 2 packets before
they send any input reports.
Signed-off-by: Mark Furneaux <mark@furneaux.ca>
Reviewed-by: Cameron Gutman <aicommander@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Inline macro for MODULE_LICENSE to make the license information easy to
find, eg with grep. Inline the other module-related macros at the same
time.
A simplified version of the semantic patch for the MODULE_LICENSE
case is as follows: (http://coccinelle.lip6.fr/)
// <smpl>
@s@
identifier i; expression e;
@@
@@
declarer name MODULE_LICENSE;
identifier s.i;
expression s.e;
@@
MODULE_LICENSE(
- i
+ e
);
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
[dtor: added a couple of drivers missed by the script, removed a few unused
DRIVER_VERSION macros]
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
We should only see devices with interrupt endpoints. Ignore any other
endpoints that we find, so we don't send try to send them interrupt URBs
and trigger a WARN down in the USB stack.
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Tested-by: Andrey Konovalov <andreyknvl@google.com>
Cc: <stable@vger.kernel.org> # c01b5e7464 Input: xpad - don't depend on endpoint order
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The PowerA gamepad initialization quirk worked with the PowerA
wired gamepad I had around (0x24c6:0x543a), but a user reported [0]
that it didn't work for him, even though our gamepads shared the
same vendor and product IDs.
When I initially implemented the PowerA quirk, I wanted to avoid
actually triggering the rumble action during init. My tests showed
that my gamepad would work correctly even if it received a rumble
of 0 intensity, so that's what I went with.
Unfortunately, this apparently isn't true for all models (perhaps
a firmware difference?). This non-working gamepad seems to require
the real magic rumble packet that the Microsoft driver sends, which
actually vibrates the gamepad. To counteract this effect, I still
send the old zero-rumble PowerA quirk packet which cancels the
rumble effect before the motors can spin up enough to vibrate.
[0]: https://github.com/paroj/xpad/issues/48#issuecomment-313904867
Reported-by: Kyle Beauchamp <kyleabeauchamp@gmail.com>
Tested-by: Kyle Beauchamp <kyleabeauchamp@gmail.com>
Fixes: 81093c9848 ("Input: xpad - support some quirky Xbox One pads")
Cc: stable@vger.kernel.org # v4.12
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
usb_device_id are not supposed to change at runtime. All functions
working with usb_device_id provided by <linux/usb.h> work with
const usb_device_id. So mark the non-const structs as const.
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
XBCD [0][1] is an OpenSource driver for Xbox controllers on Windows.
Later it also started supporting Xbox360 controllers (presumably before
the official Windows driver was released).
It contains a couple device IDs unknown to the Linux driver, so I extracted
those from xbcd.inf and added them to our list.
It has a special type for Wheels and I have the feeling they might need
some extra handling. They all have 'Wheel' in their name, so that
information is available for future improvements.
[0] https://www.s-config.com/xbcd-original-xbox-controllers-win10/
[1] http://www.redcl0ud.com/xbcd.html
Reviewed-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Benjamin Valentin <benpicco@googlemail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
360Controller [0] is an OpenSource driver for Xbox/Xbox360/XboxOne
controllers on macOS.
It contains a couple device IDs unknown to the Linux driver, so I wrote a
small Python script [1] to extract them and feed them into my previous
script [2] to compare them with the IDs known to Linux.
For most devices, this information is not really needed as xpad is able to
automatically detect the type of an unknown Xbox Controller at run-time.
I've therefore stripped all the generic/vague entries.
I've excluded the Logitech G920, it's handled by a HID driver already.
I've also excluded the Scene It! Big Button IR, it's handled by an
out-of-tree driver. [3]
[0] https://github.com/360Controller/360Controller
[1] http://codepad.org/v9GyLKMq
[2] http://codepad.org/qh7jclpD
[3] https://github.com/micolous/xbox360bb
Reviewed-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Benjamin Valentin <benpicco@googlemail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Add USB IDs for two more Xbox 360 controllers.
I found them in the pull requests for the xboxdrv userspace driver, which
seems abandoned.
Thanks to psychogony and mkaito for reporting the IDs there!
Signed-off-by: Benjamin Valentin <benpicco@googlemail.com>
Reviewed-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Some entries in the table of supported devices are out of order.
To not create a mess when adding new ones using a script, sort them first.
Signed-off-by: Benjamin Valentin <benpicco@googlemail.com>
Reviewed-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
There are several quirky Xbox One pads that depend on initialization
packets that the Microsoft pads don't require. To deal with these,
I've added a mechanism for issuing device-specific initialization
packets using a VID/PID-based quirks list.
For the initial set of init quirks, I have added quirk handling from
Valve's Steam Link xpad driver[0] and the 360Controller project[1] for
macOS to enable some new pads to work properly.
This should enable full functionality on the following quirky pads:
0x0e6f:0x0165 - Titanfall 2 gamepad (previously fully non-functional)
0x0f0d:0x0067 - Hori Horipad (analog sticks previously non-functional)
0x24c6:0x541a - PowerA Xbox One pad (previously fully non-functional)
0x24c6:0x542a - PowerA Xbox One pad (previously fully non-functional)
0x24c6:0x543a - PowerA Xbox One pad (previously fully non-functional)
[0]: https://github.com/ValveSoftware/steamlink-sdk/blob/master/kernel/drivers/input/joystick/xpad.c
[1]: https://github.com/360Controller/360Controller
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Set the LED_CORE_SUSPENDRESUME flag on our LED device so the
LED state will be automatically restored by LED core on resume.
Since Xbox One pads stop flashing only when reinitialized, we'll
send them the initialization packet so they calm down too.
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The Xbox One S requires an ack to its mode button report, otherwise it
continuously retransmits the report. This makes the mode button appear to
be stuck down after it is pressed for the first time.
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
The order of endpoints is well defined on official Xbox pads, but
we have found at least one 3rd-party pad that doesn't follow the
standard ("Titanfall 2 Xbox One controller" 0e6f:0165).
Fortunately, we get lucky with this specific pad because it uses
endpoint addresses that differ only by direction. We know that
there are other pads out where this is not true, so let's go
ahead and fix this.
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Replace first goto with simple returns as we really are just returning
one error code.
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
xbox one was the only device that has a *_process_buttons routine.
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
currently the controllers get the same product id as the wireless
receiver. However the controllers actually have their own product id.
The patch makes the driver expose the same product id as the windows
driver.
This improves compatibility when running applications with WINE.
see https://github.com/paroj/xpad/issues/54
Signed-off-by: Pavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Unlike previous Xbox pads, the Xbox One pad doesn't have "sticky" rumble
packets. The duration is encoded into the command and expiration is handled
by the pad firmware.
ff-memless needs pseudo-sticky behavior for rumble effects to behave
properly for long duration effects. We already specify the maximum rumble
on duration in the command packets, but it's still only good for about 2.5
seconds of rumble. This is easily reproducible running fftest's sine
vibration test.
It turns out there's a repeat count encoded in the rumble command. We can
abuse that to get the pseudo-sticky behavior needed for rumble to behave as
expected for effects with long duration.
By my math, this change should allow a single ff_effect to rumble for 10
minutes straight, which should be more than enough for most needs.
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
This is the new gamepad that ships with the Xbox One S which
includes Bluetooth functionality.
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
When the USB wireless adapter is suspended, the controllers
lose their connection. This causes them to start flashing
their LED rings and searching for the wireless adapter
again, wasting the controller's battery power.
Instead, we will tell the controllers to power down when
we suspend. This mirrors the behavior of the controllers
when connected to the console itself and how the official
Xbox One wireless adapter behaves on Windows.
Signed-off-by: Cameron Gutman <aicommander@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
