The battery_charging and cable_state flags were backwards on the Sixaxis.
The low bit of report byte 30 is 0 when charging and 1 when not.
Bit 5 of byte 31 is 0 when a USB cable is connected and 1 when not.
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add the conditionals to enable rumble, battery reporting, LED and touchpad
support for the Dualshock 4 in Bluetooth mode.

Add dualshock4_set_operational_bt to initialize the controller to the proper
operational state.
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Set the initial battery level to 100% to avoid false low battery warnings if
the battery state is polled before a report with the actual battery level is
received.
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add Dualshock 4 battery and touchpad parsing for Bluetooth reports.
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add formating for the Dualshock 4 output report data in Bluetooth mode.

In Bluetooth mode the Dualshock 4 wants output reports sent on the control
channel.
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

By default, the Dualshock 4 sends controller data via report 1. Once a valid
output report 0x11 is received or a feature report of type 0x02 is requested the
controller changes from sending data in report 1 to sending data in report 17,
which is unmapped in the default descriptor. The mappings have to be moved to
report 17 to let the HID driver properly process the incoming reports.
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Switch to the low-level transport driver functions.

sony_set_output_report is removed since it is no longer used.
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add a helper to access hdev->hid_output_raw_report().

To convert the drivers, use the following snippets:

for i in drivers/hid/*.c
do
  sed -i.bak "s/[^ \t]*->hid_output_raw_report(/hid_output_raw_report(/g" $i
done

Then manually fix for checkpatch.pl
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

dev->hid_get_raw_report(X) and hid_hw_raw_request(X, HID_REQ_GET_REPORT)
are strictly equivalent. Switch the hid subsystem to the hid_hw notation
and remove the field .hid_get_raw_report in struct hid_device.
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The Dualshock4 controller contains a RGB LED, which is enabled via
the '/sys/class/leds' interface. At present the driver only returns
whether each of the RGB LEDs is lit (ie not off), but no indication
of it's brightness.

This patch fixes the reading of the current brightnes so that it
returns the value (rather than just off=0, on=LED_FULL).

Tested on the DS4 and SixAxis (for compatibility).
Signed-off-by: NSimon Wood <simon@mungewell.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add output events for the multi-touch pad on the Dualshock 4.

The touchpad has a resolution of 1920x940 and is capable of 2 simultaneous
touches. A 'Type B' stateful slot protocol is implemented as defined in
Documentation/input/multi-touch-protocol.txt

Applications can use the touchpad data by processing the ABS_MT_SLOT,
ABS_MT_TRACKING_ID, ABS_MT_POSITION_X and ABS_MT_POSITION_Y events.
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add battery status reporting for the Sixaxis and Dualshock 4 controllers.
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Use the naming scheme 'devicename:colour' for the Dualshock 4
LED lightbar controls as specified in Documentation/leds/leds-class.txt
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add annotated HID descriptor for the Dualshock 4.
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Retrieve and cache the output report for the Dualshock 4 in sony_probe()
instead of repeatedly walking the report list in the worker function.
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Use a modified HID descriptor for the Dualshock 4 to assign the gyroscope
sensors and accelerometers to axes.
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Fix cosmetic spacing in the device definitions.
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Use regular HID output reports instead of raw reports in the
dualshock4_state_worker function.  (Thanks Simon Mungewell)
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Use separate identifiers for Dualshock 4 controllers connected via USB and
Bluetooth.
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Rename sony_state_worker to sixaxis_state_worker since the function is now
sixaxis specific.
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add LED lightbar controls for the Dualshock 4.

The Dualshock 4 light bar has 3 separate RGB LEDs that can range in
brightness from 0 to 255 so a full byte is now needed to store each LED's
state

Changed the module to support an arbitrary number of LEDs instead of being
hardcoded to 4.
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Adds the Dualshock 4 to the HID device list and enables force-feedback.

Adds a Dualshock 4 specific worker function since the Dualshock 4 needs a
different report than the Sixaxis.

The right motor in the Dualshock 4 is variable so the full rumble value
is now passed to the worker function and clamped there if necessary.
Signed-off-by: NFrank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Currently the return variable ret is always 0.  Set it to other values in
error cases, as used in the direct return.

A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)

// <smpl>
(
if@p1 (\(ret < 0\|ret != 0\))
 { ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
    when != &ret
*if(...)
{
  ... when != ret = e2
      when forall
 return ret;
}

// </smpl>
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The PS3 Sixaxis controller has 4 LEDs which can be controlled using the same
command as the rumble functionality. It seems not to be possible to only change
the LED without modifying the rumble motor state. Thus both have to be stored
on the host and retransmitted when either the LED or rumble state is changed.

Third party controllers may not support to disable all LEDs at once. These
controllers automatically switch to blinking of all LEDs when no LED is active
anymore.
Signed-off-by: NSven Eckelmann <sven@narfation.org>
Tested-by: NSimon Wood <simon@mungewell.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

It is not necessary to keep the LED information in an extra struct which is
only used by the Buzz device. It can also be used by other devices.
Signed-off-by: NSven Eckelmann <sven@narfation.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

More controllers managed by the hid-sony module have 4 LEDs. These can share
most of the functionality provided by the buzz functions.
Signed-off-by: NSven Eckelmann <sven@narfation.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Signed-off-by: NSven Eckelmann <sven@narfation.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The commands used to modify the rumble motor state also modifies the LEDs at
the same time. The functionality used to modify this state in the driver has to
be shared between the rumble and LED part. It is therefore better to replace
the "rumble" part of the names with "state".
Signed-off-by: NSven Eckelmann <sven@narfation.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The ff_memless has a timer running which gets run in an atomic context and
calls the play_effect callback. The callback function for sony uses the
hid_output_raw_report (overwritten by sixaxis_usb_output_raw_report) function
to handle differences in the control message format. It is not safe for an
atomic context because it may sleep later in usb_start_wait_urb.

This "scheduling while atomic" can cause the system to lock up. A workaround is
to make the force feedback state update using work_queues and use the
play_effect function only to enqueue the work item.
Reported-by: NSimon Wood <simon@mungewell.org>
Reported-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NSven Eckelmann <sven@narfation.org>
Signed-off-by: NSimon Wood <simon@mungewell.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Sony Dualshock 3 controllers have two motors which can be used to provide
simple force feedback rumble effects. The right motor is can be used to create
a weak rumble effect but does not allow to set the force. The left motor is
used to create a strong rumble effect with adjustable intensity.

The state of both motors can be changed using HID_OUTPUT_REPORT packets and
have no timing information. FF memless is used to keep track of the timing and
the sony driver just generates the necessary URBs.
Signed-off-by: NSven Eckelmann <sven@narfation.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The usb packets are exactly the same, but it makes it a little bit more
independent of the transport layer.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This driver must validate the availability of the HID output report and
its size before it can write LED states via buzz_set_leds(). This stops
a heap overflow that is possible if a device provides a malicious HID
output report:

[  108.171280] usb 1-1: New USB device found, idVendor=054c, idProduct=0002
...
[  117.507877] BUG kmalloc-192 (Not tainted): Redzone overwritten

CVE-2013-2890
Signed-off-by: NKees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org #3.11
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

It is safe to use devres allocation within the hid subsystem:
- the devres release is called _after_ the call to .remove(), meaning
  that no freed pointers will exists while removing the device
- if a .probe() fails, devres releases all the allocated ressources
  before going to the next driver: there will not be ghost ressources
  attached to a hid device if several drivers are probed.

Given that, we can clean up a little some of the HID drivers. These ones
are trivial:
- there is only one kzalloc in the driver
- the .remove() callback contains only one kfree on top of hid_hw_stop()
- the error path in the probe is easy enough to be manually checked
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Commit f04d5140 (HID: driver for PS2/3 Buzz controllers) introduced
an input_mapping() callback, but set the return value to -1 to all devices
except the Buzz controllers. The result of this is that the Sixaxis input
device is not populated, making it useless.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Let's follow the structure we are trying to keep for most of the
specific HID drivers, and let the separation follow the producing
vendor.
Merge functionality provided by ps3remote driver into hid-sony.
Tested-by: NDavid Dillow <dave@thedillows.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The newly added support for Buzz controller

- introduced Kconfig selection of LEDS_CLASS
- introduced conditional preprocessor checking for CONFIG_LEDS_CLASS

This has multiple problems -- namely select doesn't work transitively,
so it shouldn't be used. On the other hand the code assumed that LEDS_CLASS
is enabled in some places, but not everywhere.

Put LEDS_CLASS as a Kconfig dependency for hid-sony and remove all the
CONFIG_LEDS_CLASS conditionals from hid-sony.

Reported-by: fengguang.wu@intel.com
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This patch adds support for PS2/3 Buzz controllers into hid-sony

It has been tested on Debian 7 with kernel version 3.10.0-rc2. Unfortunately
I can't test the patch with a regular six-axis controller myself.
Signed-off-by: NColin Leitner <colin.leitner@gmail.com>
Cc: Jiri Kosina <jkosina@suse.cz>
Cc: linux-input@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Document what the fix-up is does and make it more robust by ensuring
that it is only applied to the USB interface that corresponds to the
mouse (sony_report_fixup() is called once per interface during probing).

Cc: linux-input@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NFernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Some Vaio desktop computers, among them the VGC-LN51JGB multimedia PC, have
a RF receiver, multi-interface USB device 054c:0374, that is used to connect
a wireless keyboard and a wireless mouse.

The keyboard works flawlessly, but the mouse (VGP-WMS3 in my case) does not
seem to be generating any pointer events. The problem is that the mouse pointer
is wrongly declared as a constant non-data variable in the report descriptor
(see lsusb and usbhid-dump output below), with the consequence that it is
ignored by the HID code.

Add this device to the have-special-driver list and fix up the report
descriptor in the Sony-specific driver which happens to already have a fixup
for a similar firmware bug.

# lsusb -vd 054C:0374
Bus 003 Device 002: ID 054c:0374 Sony Corp.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x054c Sony Corp.
  idProduct          0x0374
  iSerial                 0
[...]
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      2 Mouse
      iInterface              2 RF Receiver
[...]
          Report Descriptor: (length is 100)
[...]
            Item(Global): Usage Page, data= [ 0x01 ] 1
                            Generic Desktop Controls
            Item(Local ): Usage, data= [ 0x30 ] 48
                            Direction-X
            Item(Local ): Usage, data= [ 0x31 ] 49
                            Direction-Y
            Item(Global): Report Count, data= [ 0x02 ] 2
            Item(Global): Report Size, data= [ 0x08 ] 8
            Item(Global): Logical Minimum, data= [ 0x81 ] 129
            Item(Global): Logical Maximum, data= [ 0x7f ] 127
            Item(Main  ): Input, data= [ 0x07 ] 7
                            Constant Variable Relative No_Wrap Linear
                            Preferred_State No_Null_Position Non_Volatile Bitfield

# usbhid-dump
003:002:001:DESCRIPTOR         1357910009.758544
 05 01 09 02 A1 01 05 01 09 02 A1 02 85 01 09 01
 A1 00 05 09 19 01 29 05 95 05 75 01 15 00 25 01
 81 02 75 03 95 01 81 01 05 01 09 30 09 31 95 02
 75 08 15 81 25 7F 81 07 A1 02 85 01 09 38 35 00
 45 00 15 81 25 7F 95 01 75 08 81 06 C0 A1 02 85
 01 05 0C 15 81 25 7F 95 01 75 08 0A 38 02 81 06
 C0 C0 C0 C0

Cc: linux-input@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: NFernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

There are some Sony clone gamepads that are incompatible
with PS3 since firmware 3.50, as they decided to prevent those
devices to work, without any good technical reason. I was one of those
'blessed' people affected by their niceness with their customers.

Marcelo also has another device with a similar problem.

Perhaps due to Sony's way to block the device, damaging the device's
eeprom, or perhaps because they just have a different, broken Report
descriptor, there are 3 buttons that don't work on both devices
(the ones equivalent to square, round and X).

What it happens is that the descriptor generate weird EV_ABS events
to those buttons, instead of EV_MSC/EV_KEY.

A fix that seems to be enough for them is to return the original
sixaxis table instead of the broken one. That's what this patch
does.

Yet, there are some missing entries at the used keytable. On my
tests, all keys are now producing the right events, but the reported
keycodes look weird:

"square" key: (Button.0010 = 1)

1355524363.460835: event type EV_MSC(0x04): scancode = 0x90010
1355524363.460835: event type EV_KEY(0x01) key_up: BTN_DEAD(0x0001)

"round" key: (Button.000e = 1)

1355524410.908705: event type EV_MSC(0x04): scancode = 0x9000e
1355524410.908705: event type EV_KEY(0x01) key_down: (0x0001)
1355524410.971788: event type EV_MSC(0x04): scancode = 0x9000e
1355524410.971788: event type EV_KEY(0x01) key_up: (0x0001)

"X" key: (Button.000f = 1)
1355524384.880813: event type EV_MSC(0x04): scancode = 0x9000f
1355524384.880813: event type EV_KEY(0x01) key_down: (0x0001)
1355524384.979815: event type EV_MSC(0x04): scancode = 0x9000f
1355524384.979815: event type EV_KEY(0x01) key_up: (0x0001)

The rationale is likely due to those entries at rdesc table, where the
Kernel were not likely able to parse:

Button.000d ---> Key.?
Button.000e ---> Key.?
Button.000f ---> Key.?
Button.0010 ---> Key.BtnDead
Button.0011 ---> Key.?
Button.0012 ---> Key.?
Button.0013 ---> Key.?

As a reference, this is the rdisc used on my clone (a Mad Catz
model 8846):

05 01 09 04 a1 01 a1 02 85 01 75 08 95 01 15 00 26 ff 00 81 03 75 01 95 0d 15 00 25 01 35 00 45 01 05 09 19 01 29 0d 81 02 75 01 95 03 06 00 ff 81 03 05 01 25 07 46 3b 01 75 04 95 01 65 14 09 39 81 42 65 00 75 01 95 0c 06 00 ff 81 03 15 00 26 ff 00 05 01 09 01 a1 00 75 08 95 04 15 00 15 00 15 00 35 00 35 00 46 ff 00 09 30 09 31 09 32 09 35 81 02 c0 05 01 75 08 95 27 09 01 81 02 75 08 95 30 09 01 91 02 75 08 95 30 09 01 b1 02 c0 a1 02 85 02 75 08 95 30 09 01 b1 02 c0 a1 02 85 ee 75 08 95 30 09 01 b1 02 c0 a1 02 85 ef 75 08 95 30 09 01 b1 02 c0 c0

This is what's returned on Marcelo's device (not sure what is
the brand name of his device):

05 01 09 04 a1 01 a1 02 85 01 75 08 95 01 15 00 26 ff 00 81 03 75 01 95 13 15 00 25 01 35 00 45 01 05 09 19 01 29 13 81 02 75 01 95 0d 06 00 ff 81 03 15 00 26 ff 00 05 01 09 01 a1 00 75 08 95 04 35 00 46 ff 00 09 30 09 31 09 32 09 35 81 02 c0 05 01 95 13 09 01 81 02 95 0c 81 01 75 10 95 04 26 ff 03 46 ff 03 09 01 81 02 c0 a1 02 85 02 75 08 95 30 09 01 b1 02 c0 a1 02 85 ee 75 08 95 30 09 01 b1 02 c0 a1 02 85 ef 75 08 95 30 09 01 b1 02 c0 c0
Reported-by: NMarcelo Leitner <mleitner@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>
Tested-by: NMarcelo Leitner <mleitner@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>