linux-stable.git/drivers/input/joystick, branch linux-4.5.y

Input: xpad - prevent spurious input from wired Xbox 360 controllers

2016-06-08T01:18:47+00:00

commit 1ff5fa3c6732f08e01ae12f12286d4728c9e4d86 upstream.

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: Cameron Gutman 
Signed-off-by: Pavel Rojtberg 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman

Input: xpad - move pending clear to the correct location

2016-06-08T01:18:47+00:00

commit 4efc6939a83c54fb3417541be48991afd0290ba3 upstream.

otherwise we lose ff commands: https://github.com/paroj/xpad/issues/27

Signed-off-by: Pavel Rojtberg 
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman

Input: xpad - remove unused function

2016-01-27T23:55:06+00:00

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: Arnd Bergmann 
Fixes: cae705baa40b ("Input: xpad - re-send LED command on present event")
Signed-off-by: Dmitry Torokhov

Merge branch 'next' into for-linus

2016-01-22T01:27:27+00:00

Prepare second round of input updates for 4.5 merge window.

Input: xpad - correct xbox one pad device name

2016-01-13T00:28:44+00:00

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/19

Signed-off-by: Pavel Rojtberg 
Signed-off-by: Dmitry Torokhov

Merge branch 'next' into for-linus

2016-01-12T01:47:25+00:00

Prepare first round of input updates for 4.5 merge window.

Input: xpad - use LED API when identifying wireless controllers

2016-01-04T22:35:15+00:00

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: Dmitry Torokhov

Input: xpad - workaround dead irq_out after suspend/ resume

2016-01-04T22:35:06+00:00

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/6

Signed-off-by: Pavel Rojtberg 
Signed-off-by: Dmitry Torokhov

Input: xpad - update Xbox One Force Feedback Support

2016-01-04T19:39:46+00:00

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: Pavel Rojtberg 
Signed-off-by: Dmitry Torokhov

Input: xpad - correctly handle concurrent LED and FF requests

2016-01-04T19:39:38+00:00

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.html

Signed-off-by: Pavel Rojtberg 
Signed-off-by: Dmitry Torokhov