Use the naming scheme 'devicename:colour' for the Dualshock 4
LED lightbar controls as specified in Documentation/leds/leds-class.txt
Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: Jiri 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: Frank Praznik <frank.praznik@oh.rr.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Jiri 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: Frank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: Jiri 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: Frank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Use separate identifiers for Dualshock 4 controllers connected via USB and
Bluetooth.
Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Rename sony_state_worker to sixaxis_state_worker since the function is now
sixaxis specific.
Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: Jiri 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: Frank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: Jiri 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: Frank Praznik <frank.praznik@oh.rr.com>
Signed-off-by: Jiri 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: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Jiri 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: Sven Eckelmann <sven@narfation.org>
Tested-by: Simon Wood <simon@mungewell.org>
Signed-off-by: Jiri 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: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Jiri 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: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Jiri 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: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Jiri 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: Simon Wood <simon@mungewell.org>
Reported-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Simon Wood <simon@mungewell.org>
Signed-off-by: Jiri 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: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Jiri 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: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri 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: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org #3.11
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri 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: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Commit f04d51404f (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: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri 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: David Dillow <dave@thedillows.org>
Signed-off-by: Jiri 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: Jiri Kosina <jkosina@suse.cz>
Frank Praznik
Julia Lawall
Sven Eckelmann
Benjamin Tissoires
Kees Cook
Jiri Kosina