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: NBenjamin Valentin <benpicco@googlemail.com>
Reviewed-by: NCameron Gutman <aicommander@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The userspace xboxdrv driver [0] contains some USB IDs unknown to the
kernel driver. I have created a simple script [1] to extract the missing
devices and add them to xpad.

A quick google search confirmed that all the new devices called
Fightstick/pad are Arcade-type devices [2] where the
MAP_TRIGGERS_TO_BUTTONS option should apply.

There are some similar devices in the existing device table where this
flag is not set, but I did refrain from changing those.

[0] https://github.com/xboxdrv/xboxdrv/blob/stable/src/xpad_device.cpp
[1] http://codepad.org/CHV98BNH
[2] https://www.google.com/search?q=SFxT+Fightstick+Pro&tbm=ischSigned-off-by: NBenjamin Valentin <benpicco@googlemail.com>
Reviewed-by: NCameron Gutman <aicommander@gmail.com>
Signed-off-by: NDmitry 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: NBenjamin Valentin <benpicco@googlemail.com>
Reviewed-by: NCameron Gutman <aicommander@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Cc: stable@vger.kernel.org
Signed-off-by: NCameron Gutman <aicommander@gmail.com>
Signed-off-by: NDmitry 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/360ControllerSigned-off-by: NCameron Gutman <aicommander@gmail.com>
Signed-off-by: NDmitry 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: NCameron Gutman <aicommander@gmail.com>
Signed-off-by: NDmitry 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: NCameron Gutman <aicommander@gmail.com>
Signed-off-by: NDmitry 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: NCameron Gutman <aicommander@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Replace first goto with simple returns as we really are just returning
one error code.
Signed-off-by: NPavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

xbox one was the only device that has a *_process_buttons routine.
Signed-off-by: NPavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Signed-off-by: NDaniel Tobias <dan.g.tob@gmail.com>
Signed-off-by: NPavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: NDmitry 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/54Signed-off-by: NPavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: NDmitry 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: NCameron Gutman <aicommander@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This is the new gamepad that ships with the Xbox One S which
includes Bluetooth functionality.
Signed-off-by: NCameron Gutman <aicommander@gmail.com>
Signed-off-by: NDmitry 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: NCameron Gutman <aicommander@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This prevents a malicious USB device from causing an oops.
Signed-off-by: NCameron Gutman <aicommander@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Xbox One controllers have multiple interfaces which all have the
same class, subclass, and protocol. One of the these interfaces
has only a single endpoint. When Xpad attempts to bind to this
interface, it causes an oops when trying initialize the output URB
by trying to access the second endpoint's descriptor.

This situation was avoided for known Xbox One devices by checking
the XTYPE constant associated with the VID and PID tuple. However,
this breaks when new or previously unknown Xbox One controllers
are attached to the system.

This change addresses the problem by deriving the XTYPE for Xbox
One controllers based on the interface protocol before checking
the interface number.

Fixes: 1a48ff81 ("Input: xpad - add support for Xbox One controllers")
Signed-off-by: NCameron Gutman <aicommander@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Xbox One controllers that shipped with or were upgraded to the 2015
firmware discard the current rumble packets we send. This patch changes
the Xbox One rumble packet to a form that both the newer and older
firmware will accept.

It is based on changes made to support newer Xbox One controllers in
the SteamOS brewmaster-4.1 kernel branch.
Signed-off-by: NCameron Gutman <aicommander@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

added the according id and incresed XPAD_PKT_LEN to 64 as the elite
controller sends at least 33 byte messages [1].
Verified to be working by [2].

[1]: https://franticrain.github.io/sniffs/XboxOneSniff.html
[2]: https://github.com/paroj/xpad/issues/23Signed-off-by: NPierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: NPavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Signed-off-by: NPierre-Loup A. Griffais <eduke32@plagman.net>
Signed-off-by: NThomas Debesse <dev@illwieckz.net>
Signed-off-by: Naronschatz <aronschatz@aselabs.com>
Signed-off-by: NPavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

After initially connecting a wired Xbox 360 controller or sending it
a command to change LEDs, a status/response packet is interpreted as
controller input. This causes the state of buttons represented in
byte 2 of the controller data packet to be incorrect until the next
valid input packet. Wireless Xbox 360 controllers are not affected.

Writing a new value to the LED device while holding the Start button
and running jstest is sufficient to reproduce this bug. An event will
come through with the Start button released.

Xboxdrv also won't attempt to read controller input from a packet
where byte 0 is non-zero. It also checks that byte 1 is 0x14, but
that value differs between wired and wireless controllers and this
code is shared by both. I think just checking byte 0 is enough to
eliminate unwanted packets.

The following are some examples of 3-byte status packets I saw:
01 03 02
02 03 00
03 03 03
08 03 00
Signed-off-by: NCameron Gutman <aicommander@gmail.com>
Signed-off-by: NPavel Rojtberg <rojtberg@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

otherwise we lose ff commands: https://github.com/paroj/xpad/issues/27Signed-off-by: NPavel Rojtberg <rojtberg@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This adds the VID/PID combination for the Xbox One version of the Mad
Catz FightStick TE 2.

The functionality that this provides is about on par with what the
Windows drivers for the stick manage to deliver.

What works:
- Digital stick
- 6 main buttons
- Xbox button
- The two buttons on the back
- The locking buttons (preventing accidental Xbox button press)

What doesn't work:
- Two of the main buttons (don't work on Windows either)
- The "Haptic" button setting does not have an effect (not sure if it
  works on Windows)

I added the MAP_TRIGGERS_TO_BUTTONS option but in my (limited) testing
there was no practical difference with or without. The FightStick does
not have triggers though so adding it makes sense.
Signed-off-by: NSilvan Jegen <s.jegen@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

There are two definitions of xpad_identify_controller(), one is used
when CONFIG_JOYSTICK_XPAD_LEDS is set, but the other one is empty
and never used, and we get a gcc warning about it:

drivers/input/joystick/xpad.c:1210:13: warning: 'xpad_identify_controller' defined but not used [-Wunused-function]

This removes the second definition.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Fixes: cae705ba ("Input: xpad - re-send LED command on present event")
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This reverts commit 27b9d5a2.

I am reverting this one, while keeping the rest of the G920 support in,
so that it immediately starts working once proper HID-mode switching
is implemented.

Quoting Dmitry Torokhov for rationale:

==
It is wrong. Aside form the fact that IMO xpad.c is the wrong place for
this code to be in, why are we waiting for the input device to be
opened by userspace before we do the switch instead of doing it
immediately?
==

Several people (Simon Wood and Michal Maly) expressed the intent to work
on proper HID switching in a short term.
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Apparently the Covert Forces ID is not Covert Forces pad exclusive, but
rather denotes a new firmware version that can be found on all new
controllers and can be also updated on old hardware using Windows 10.

see: https://github.com/paroj/xpad/issues/19Signed-off-by: NPavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

When lighting up the segment identifying wireless controller, Instead of
sending command directly to the controller, let's do it via LED API (usinf
led_set_brightness) so that LED object state is in sync with controller
state and we'll light up the correct segment on resume as well.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The irq_out urb is dead after suspend/ resume on my x360 wr pad. (also
reproduced by Zachary Lund [0]) Work around this by implementing
suspend, resume, and reset_resume callbacks and properly shutting down
URBs on suspend and restarting them on resume.

[0]: https://github.com/paroj/xpad/issues/6Signed-off-by: NPavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

There's apparently a serial number woven into both input and output
packets; neglecting to specify a valid serial number causes the controller
to ignore the rumble packets.

The scale of the rumble was also apparently halved in the packets.

The initialization packet had to be changed to allow force feedback to
work.

see https://github.com/paroj/xpad/issues/7 for details.
Signed-off-by: NPavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Track the status of the irq_out URB to prevent submission iof new requests
while current one is active. Failure to do so results in the "URB submitted
while active" warning/stack trace.

Store pending brightness and FF effect in the driver structure and replace
it with the latest requests until the device is ready to process next
request. Alternate serving LED vs FF requests to make sure one does not
starve another. See [1] for discussion. Inspired by patch of Sarah Bessmer
[2].

[1]: http://www.spinics.net/lists/linux-input/msg40708.html
[2]: http://www.spinics.net/lists/linux-input/msg31450.htmlSigned-off-by: NPavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Handle the "a new device is present" message properly by dynamically
creating the input device at this point in time. This means we now do not
"preallocate" all 4 devices when a single wireless base station is seen.
This requires a workqueue as we are in interrupt context when we learn
about this.

Also properly disconnect any devices that we are told are removed.
Signed-off-by: N"Pierre-Loup A. Griffais" <pgriffais@valvesoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NPavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

When powering up a wireless xbox 360 controller, some wrong joystick
events are generated. It is annoying because, for example, it makes
unwanted moves in Steam big picture mode's menu.

When my controller is powering up, this packet is received by the
driver:
00000000: 00 0f 00 f0 00 cc ff cf 8b e0 86 6a 68 f0 00 20  ...........jh..
00000010: 13 e3 20 1d 30 03 40 01 50 01 ff ff              .. .0.@.P...

According to xboxdrv userspace driver source code, this packet is only
dumping a serial id and should not be interpreted as joystick events.
This issue can be easily seen with jstest:
$ jstest --event /dev/input/js0

This patch only adds a way to filter out this "serial" packet and as a
result it removes the spurous events.
Signed-off-by: NClement Calmels <clement.calmels@free.fr>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

When plugged in the Logitech G920 wheel starts with USBID 046d:c261
and behaviors as a vendor specific class. If a 'magic' byte sequence
is sent the wheel will detach and reconnect as a HID device with the
USBID 046d:c262.
Signed-off-by: NSimon Wood <simon@mungewell.org>
Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Do not call xpad_identify_controller at init with wireless devices: it
conflicts with the already sent presence packet and will be called by
xpad360w_process_packet as needed anyway.
Signed-off-by: NPavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

When we initialize the driver/device, we really don't know how many
controllers are connected.  So send a "query presence" command to the
base-station. (Command discovered by Zachary Lund)

Presence packet taken from:

https://github.com/computerquip/xpad5Signed-off-by: NPavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

To allow us to later create / destroy the input device from the urb
callback, we need to initialize/ deinitialize the input device from a
separate function.  So pull that logic out now to make later patches
more "obvious" as to what they do.
Signed-off-by: N"Pierre-Loup A. Griffais" <pgriffais@valvesoftware.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NPavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

as discussed here[0], x360w is the only pad that maps dpad_to_button.
This is bad for downstream developers as they have to differ between
x360 and x360w which is not intuitive.

This patch implements the suggested solution of exposing the dpad both
as axes and as buttons. This retains backward compatibility with software
already dealing with the difference while makes new software work as
expected across x360/ x360w pads.

[0] http://www.spinics.net/lists/linux-input/msg34421.htmlSigned-off-by: NPavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

Move submission logic to a single point at the end of the function.
This makes it easy to add locking/ queuing code later on.
Signed-off-by: NPavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

This code was probably wrong ever since and is redundant with
xpad_send_led_command. Both try to send a similar command to the xbox360
controller. However xpad_send_led_command correctly uses the pad_nr instead
of bInterfaceNumber to select the led and re-uses the irq_out URB instead
of creating a new one.

Note that this change only affects the two supported wireless controllers.
Tested using the xbox360 wireless controller (PC).
Signed-off-by: NPavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>

The pad_nr corresponds to the lit up LED on the controller. Therefore there
should be no gaps when enumerating. Currently a LED is only re-assigned
after a controller is re-connected 4 times.

This patch uses ida to track connected pads - this way we can re-assign
freed up pad number immediately.

Consider the following case:
1. pad A is connected and gets pad_nr = 0
2. pad B is connected and gets pad_nr = 1
3. pad A is disconnected
4. pad A is connected again

using ida_simple_get() controller A now correctly gets pad_nr = 0 again.
Signed-off-by: NPavel Rojtberg <rojtberg@gmail.com>
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>