* Re: [PATCH 4/4] HID: sony: Map gyroscopes and accelerometers to axes
From: Jiri Kosina @ 2014-01-17 19:03 UTC (permalink / raw)
To: Frank Praznik; +Cc: David Herrmann, linux-input, Frank Praznik
In-Reply-To: <52D965E2.6010907@gmail.com>
On Fri, 17 Jan 2014, Frank Praznik wrote:
> Any objections to moving all of the rdesc data to an hid-sony.h header
> file?
Please don't. This doesn't really belong in a header file. Header files
are used to declare things, not to have large data structures there.
There are other drivers which contain annotated descriptor and are
readable; for example look at hid-waltop.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH v2] Input: wacom - add support for DTU-1031
From: Ping Cheng @ 2014-01-17 18:25 UTC (permalink / raw)
To: linux-input; +Cc: dmitry.torokhov, Ping Cheng
Signed-off-by: Ping Cheng <pingc@wacom.com>
---
v2: use get_unaligned_be16 instead of be16_to_cpup for
unaligned data ([3] and [5])
drivers/input/tablet/wacom_wac.c | 76 +++++++++++++++++++++++++++++++++++++++-
drivers/input/tablet/wacom_wac.h | 6 +++-
2 files changed, 80 insertions(+), 2 deletions(-)
diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
index 0bcc7a6..fed56a7 100644
--- a/drivers/input/tablet/wacom_wac.c
+++ b/drivers/input/tablet/wacom_wac.c
@@ -210,6 +210,66 @@ static int wacom_dtu_irq(struct wacom_wac *wacom)
return 1;
}
+static int wacom_dtus_irq(struct wacom_wac *wacom)
+{
+ char *data = wacom->data;
+ struct input_dev *input = wacom->input;
+ unsigned short prox, pressure = 0;
+ int retval = 0;
+
+ if (data[0] != WACOM_REPORT_DTUS && data[0] != WACOM_REPORT_DTUSPAD) {
+ dev_dbg(input->dev.parent,
+ "%s: received unknown report #%d", __func__, data[0]);
+ } else if (data[0] == WACOM_REPORT_DTUSPAD) {
+ input_report_key(input, BTN_0, (data[1] & 0x01));
+ input_report_key(input, BTN_1, (data[1] & 0x02));
+ input_report_key(input, BTN_2, (data[1] & 0x04));
+ input_report_key(input, BTN_3, (data[1] & 0x08));
+ if (data[1] & 0x0f) {
+ input_report_abs(input, ABS_MISC, PAD_DEVICE_ID);
+ } else {
+ input_report_abs(input, ABS_MISC, 0);
+ }
+ /* serial number is required when expresskeys are
+ * reported through pen interface.
+ */
+ input_event(input, EV_MSC, MSC_SERIAL, 0xf0);
+ retval = 1;
+ } else {
+
+ prox = data[1] & 0x80;
+ if (prox) {
+ switch ((data[1] >> 3) & 3) {
+ case 1: /* Rubber */
+ wacom->tool[0] = BTN_TOOL_RUBBER;
+ wacom->id[0] = ERASER_DEVICE_ID;
+ break;
+
+ case 2: /* Pen */
+ wacom->tool[0] = BTN_TOOL_PEN;
+ wacom->id[0] = STYLUS_DEVICE_ID;
+ break;
+ }
+ }
+
+ input_report_key(input, BTN_STYLUS, data[1] & 0x20);
+ input_report_key(input, BTN_STYLUS2, data[1] & 0x40);
+ input_report_abs(input, ABS_X, get_unaligned_be16(&data[3]));
+ input_report_abs(input, ABS_Y, get_unaligned_be16(&data[5]));
+ pressure = ((data[1] & 0x03) << 8) | (data[2] & 0xff);
+ input_report_abs(input, ABS_PRESSURE, pressure);
+ input_report_key(input, BTN_TOUCH, pressure > 10);
+
+ if (!prox) /* out-prox */
+ wacom->id[0] = 0;
+ input_report_key(input, wacom->tool[0], prox);
+ input_report_abs(input, ABS_MISC, wacom->id[0]);
+ input_event(input, EV_MSC, MSC_SERIAL, 1);
+ retval = 1;
+ }
+ return retval;
+}
+
static int wacom_graphire_irq(struct wacom_wac *wacom)
{
struct wacom_features *features = &wacom->features;
@@ -1371,6 +1431,10 @@ void wacom_wac_irq(struct wacom_wac *wacom_wac, size_t len)
sync = wacom_dtu_irq(wacom_wac);
break;
+ case DTUS:
+ sync = wacom_dtus_irq(wacom_wac);
+ break;
+
case INTUOS:
case INTUOS3S:
case INTUOS3:
@@ -1562,7 +1626,7 @@ int wacom_setup_input_capabilities(struct input_dev *input_dev,
wacom_abs_set_axis(input_dev, wacom_wac);
- switch (wacom_wac->features.type) {
+ switch (features->type) {
case WACOM_MO:
input_set_abs_params(input_dev, ABS_WHEEL, 0, 71, 0, 0);
/* fall through */
@@ -1773,8 +1837,14 @@ int wacom_setup_input_capabilities(struct input_dev *input_dev,
/* fall through */
+ case DTUS:
case PL:
case DTU:
+ if (features->type == DTUS) {
+ input_set_capability(input_dev, EV_MSC, MSC_SERIAL);
+ for (i = 0; i < 3; i++)
+ __set_bit(BTN_0 + i, input_dev->keybit);
+ }
__set_bit(BTN_TOOL_PEN, input_dev->keybit);
__set_bit(BTN_TOOL_RUBBER, input_dev->keybit);
__set_bit(BTN_STYLUS, input_dev->keybit);
@@ -2096,6 +2166,9 @@ static const struct wacom_features wacom_features_0xCE =
static const struct wacom_features wacom_features_0xF0 =
{ "Wacom DTU1631", WACOM_PKGLEN_GRAPHIRE, 34623, 19553, 511,
0, DTU, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
+static const struct wacom_features wacom_features_0xFB =
+ { "Wacom DTU1031", WACOM_PKGLEN_DTUS, 22096, 13960, 511,
+ 0, DTUS, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
static const struct wacom_features wacom_features_0x57 =
{ "Wacom DTK2241", WACOM_PKGLEN_INTUOS, 95840, 54260, 2047,
63, DTK, WACOM_INTUOS3_RES, WACOM_INTUOS3_RES};
@@ -2402,6 +2475,7 @@ const struct usb_device_id wacom_ids[] = {
{ USB_DEVICE_WACOM(0xF8) },
{ USB_DEVICE_DETAILED(0xF6, USB_CLASS_HID, 0, 0) },
{ USB_DEVICE_WACOM(0xFA) },
+ { USB_DEVICE_WACOM(0xFB) },
{ USB_DEVICE_WACOM(0x0307) },
{ USB_DEVICE_DETAILED(0x0309, USB_CLASS_HID, 0, 0) },
{ USB_DEVICE_LENOVO(0x6004) },
diff --git a/drivers/input/tablet/wacom_wac.h b/drivers/input/tablet/wacom_wac.h
index 3600cf7..f69c0eb 100644
--- a/drivers/input/tablet/wacom_wac.h
+++ b/drivers/input/tablet/wacom_wac.h
@@ -12,7 +12,7 @@
#include <linux/types.h>
/* maximum packet length for USB devices */
-#define WACOM_PKGLEN_MAX 64
+#define WACOM_PKGLEN_MAX 68
#define WACOM_NAME_MAX 64
@@ -29,6 +29,7 @@
#define WACOM_PKGLEN_WIRELESS 32
#define WACOM_PKGLEN_MTOUCH 62
#define WACOM_PKGLEN_MTTPC 40
+#define WACOM_PKGLEN_DTUS 68
/* wacom data size per MT contact */
#define WACOM_BYTES_PER_MT_PACKET 11
@@ -47,11 +48,13 @@
#define WACOM_REPORT_INTUOSWRITE 6
#define WACOM_REPORT_INTUOSPAD 12
#define WACOM_REPORT_INTUOS5PAD 3
+#define WACOM_REPORT_DTUSPAD 21
#define WACOM_REPORT_TPC1FG 6
#define WACOM_REPORT_TPC2FG 13
#define WACOM_REPORT_TPCMT 13
#define WACOM_REPORT_TPCHID 15
#define WACOM_REPORT_TPCST 16
+#define WACOM_REPORT_DTUS 17
#define WACOM_REPORT_TPC1FGE 18
#define WACOM_REPORT_24HDT 1
#define WACOM_REPORT_WL 128
@@ -70,6 +73,7 @@ enum {
PTU,
PL,
DTU,
+ DTUS,
INTUOS,
INTUOS3S,
INTUOS3,
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH 4/4] HID: sony: Map gyroscopes and accelerometers to axes
From: David Herrmann @ 2014-01-17 17:38 UTC (permalink / raw)
To: Frank Praznik
Cc: Jiri Kosina, Antonio Ospite, Frank Praznik,
open list:HID CORE LAYER
In-Reply-To: <52D96619.7000209@gmail.com>
Hi
On Fri, Jan 17, 2014 at 6:19 PM, Frank Praznik <frank.praznik@gmail.com> wrote:
> On 1/17/2014 07:21, Jiri Kosina wrote:
>>
>> On Fri, 17 Jan 2014, Antonio Ospite wrote:
>>
>>>> Use a modified HID descriptor for the Dualshock 4 to assign the
>>>> gyroscope
>>>> sensors and accelerometers to axes.
>>>>
>>> What about putting the descriptor fixup on hold for now?
>>> Jiri, have you already pushed these patches?
>>>
>>> Once the ABS2 stuff from David Hermann is done then proper mapping
>>> following the Gamepad API[1] and the Motion-Tracking API[2] could be
>>> added.
>>>
>>> [1] Documentation/input/gamepad.txt
>>> [2] Documentation/input/motion-tracking.txt
>>>
>>> We could even have the DS3 and DS4 expose the same mapping.
>>>
>>> Just a suggestion.
>>
>> Hi,
>>
>> yes, I have already pushed it, but we can of course discuss not including
>> it into pull for Linus if necessary.
>>
>> My understanding is that once ABS2 stuff is done, this can just be
>> switched to using it in a backwards-compatible way, and the report fixup
>> could be dropped, no?
>>
> The default descriptor doesn't map the accelerometers or gyros to anything.
> It's just a 'user defined' page that causes the HID system to skip over the
> bytes in the report. My changes to the descriptor map the accelerometers to
> usage 0x40, 0x41 and 0x42 and the gyroscope values to 0x43, 0x44 and 0x45.
> These are the proper HID usage values for accelerometers and gyros according
> to the HID spec and according to the updated motion-tracking.txt this is
> exactly what they need to be mapped to to work with the ABS2 changes.
> Unless I'm missing something, these descriptor changes should be
> forward-compatible.
Your patch is fine. Issue is, once we introduce the interfaces
described in motion-tracking.txt, we would have to decide whether we
want to adjust hid-input.c to use it. If we do that, we might break
user-space, but if we don't do that, we will never map the stuff
correctly. Not that easy to fix.
So in case we postpone your patch, we could make sure it maps to the
new bits right from the beginning. But I'm not so sure it's worth it
as ABS2 is still not fully discussed.
Thanks
David
^ permalink raw reply
* Re: [PATCH] HID: sony: Cache the output report for the Dualshock 4
From: David Herrmann @ 2014-01-17 17:34 UTC (permalink / raw)
To: Frank Praznik; +Cc: open list:HID CORE LAYER, Jiri Kosina
In-Reply-To: <alpine.DEB.2.10.1401171135240.7355@franz-virtual-machine>
Hi
On Fri, Jan 17, 2014 at 5:42 PM, Frank Praznik <frank.praznik@oh.rr.com> wrote:
> 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>
>
> ---
>
> Apply against jikos/hid.git/for-3.14/sony
>
> drivers/hid/hid-sony.c | 63 +++++++++++++++++++++++++++++++++++---------------
> 1 file changed, 44 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
> index edffe2c..4d5f6d1 100644
> --- a/drivers/hid/hid-sony.c
> +++ b/drivers/hid/hid-sony.c
> @@ -298,6 +298,7 @@ static const unsigned int buzz_keymap[] = {
> struct sony_sc {
> struct hid_device *hdev;
> struct led_classdev *leds[MAX_LEDS];
> + struct hid_report *output_report;
> unsigned long quirks;
> struct work_struct state_worker;
>
> @@ -743,26 +744,9 @@ static void dualshock4_state_worker(struct work_struct *work)
> {
> struct sony_sc *sc = container_of(work, struct sony_sc, state_worker);
> struct hid_device *hdev = sc->hdev;
> - struct list_head *head, *list;
> - struct hid_report *report;
> - __s32 *value;
> -
> - list = &hdev->report_enum[HID_OUTPUT_REPORT].report_list;
> -
> - list_for_each(head, list) {
> - report = list_entry(head, struct hid_report, list);
> -
> - /* Report 5 is used to send data to the controller via USB */
> - if ((sc->quirks & DUALSHOCK4_CONTROLLER_USB) && report->id == 5)
> - break;
> - }
> -
> - if (head == list) {
> - hid_err(hdev, "Dualshock 4 output report not found\n");
> - return;
> - }
> + struct hid_report *report = sc->output_report;
> + __s32 *value = report->field[0]->value;
>
> - value = report->field[0]->value;
> value[0] = 0x03;
>
> #ifdef CONFIG_SONY_FF
> @@ -822,6 +806,37 @@ static void sony_destroy_ff(struct hid_device *hdev)
> }
> #endif
>
> +static int sony_set_output_report(struct sony_sc *sc, int req_id, int req_size)
> +{
> + struct list_head *head, *list;
> + struct hid_report *report;
> + struct hid_device *hdev = sc->hdev;
> +
> + list = &hdev->report_enum[HID_OUTPUT_REPORT].report_list;
> +
> + list_for_each(head, list) {
> + report = list_entry(head, struct hid_report, list);
> +
> + if (report->id == req_id) {
> + if (report->size != req_size) {
> + hid_err(hdev, "Requested size of output report 0x%02x (%i bits) does not match actual size (%i bits)\n",
> + req_id, req_size, report->size);
> + return -1;
-1 is not a valid error code, please use -EINVAL (or something else if
it's not appropriate). Furthermore, are you sure you don't want to
change the "report->size != req_size" to "report->size < req_size"? In
case any future device supports a bigger report. The send will then
still work as we just set the current state.
> + }
> + sc->output_report = report;
> + break;
Change this to "return 0;" so you can remove the "if (head == list)"
below and just do a "return -EINVAL;". If you don't like this, at
least change the -1 below to -EINVAL.
> + }
> + }
> +
> + if (head == list) {
> + hid_err(hdev, "Unable to locate output report 0x%02x\n",
> + req_id);
> + return -1;
> + }
> +
> + return 0;
> +}
> +
> static int sony_probe(struct hid_device *hdev, const struct hid_device_id *id)
> {
> int ret;
> @@ -858,6 +873,16 @@ static int sony_probe(struct hid_device *hdev, const struct hid_device_id *id)
> return ret;
> }
>
> + if (sc->quirks & DUALSHOCK4_CONTROLLER_USB) {
> + /* Report 0x05 (31 bytes) is used to send data to the controller via USB */
> + ret = sony_set_output_report(sc, 0x05, 248);
Could you move this into the "else if (sc->quirks & DUALSHO...)"
below? Makes the code a lot simpler. And just move the "if (ret < 0)"
from below directly into this if() clause so the "else" is not needed.
So you end up with something like this:
else if (sc->quirks & SIXAXIS_CONTROLLER_BT)
ret = sixaxis_set_operational_bt(hdev);
else if (sc->quirks & DUALSHOCK4_CONTROLLER_USB) {
/* Report 0x05 (31 bytes) is used to send data to the controller via USB */
ret = sony_set_output_report(sc, 0x05, 248);
if (ret < 0)
goto err_stop;
INIT_WORK(&sc->state_worker, dualshock4_state_worker);
} else {
ret = 0;
}
Otherwise looks good. Thanks for the cleanup!
David
> + } else {
> + ret = 0;
> + }
> +
> + if (ret < 0)
> + goto err_stop;
> +
> if (sc->quirks & SIXAXIS_CONTROLLER_USB) {
> hdev->hid_output_raw_report = sixaxis_usb_output_raw_report;
> ret = sixaxis_set_operational_usb(hdev);
> --
> 1.8.3.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 4/4] HID: sony: Map gyroscopes and accelerometers to axes
From: Frank Praznik @ 2014-01-17 17:19 UTC (permalink / raw)
To: Jiri Kosina, Antonio Ospite; +Cc: Frank Praznik, linux-input
In-Reply-To: <alpine.LNX.2.00.1401171319500.23018@pobox.suse.cz>
On 1/17/2014 07:21, Jiri Kosina wrote:
> On Fri, 17 Jan 2014, Antonio Ospite wrote:
>
>>> Use a modified HID descriptor for the Dualshock 4 to assign the gyroscope
>>> sensors and accelerometers to axes.
>>>
>> What about putting the descriptor fixup on hold for now?
>> Jiri, have you already pushed these patches?
>>
>> Once the ABS2 stuff from David Hermann is done then proper mapping
>> following the Gamepad API[1] and the Motion-Tracking API[2] could be
>> added.
>>
>> [1] Documentation/input/gamepad.txt
>> [2] Documentation/input/motion-tracking.txt
>>
>> We could even have the DS3 and DS4 expose the same mapping.
>>
>> Just a suggestion.
> Hi,
>
> yes, I have already pushed it, but we can of course discuss not including
> it into pull for Linus if necessary.
>
> My understanding is that once ABS2 stuff is done, this can just be
> switched to using it in a backwards-compatible way, and the report fixup
> could be dropped, no?
>
The default descriptor doesn't map the accelerometers or gyros to
anything. It's just a 'user defined' page that causes the HID system to
skip over the bytes in the report. My changes to the descriptor map the
accelerometers to usage 0x40, 0x41 and 0x42 and the gyroscope values to
0x43, 0x44 and 0x45. These are the proper HID usage values for
accelerometers and gyros according to the HID spec and according to the
updated motion-tracking.txt this is exactly what they need to be mapped
to to work with the ABS2 changes. Unless I'm missing something, these
descriptor changes should be forward-compatible.
If I recall, the Dualshock 3 maps it's accelerometers and gyros to the
same set of usage values as well.
^ permalink raw reply
* Re: [PATCH] drivers/input/mouse/elantech elantech driver for Lenovo L530 trackpoint
From: David Herrmann @ 2014-01-17 17:19 UTC (permalink / raw)
To: Ulrik De Bie, Jonathan Aquilina
Cc: linux-input@vger.kernel.org, dmitry.torokhov@gmail.com
In-Reply-To: <1375220650.66420.YahooMailNeo@web120605.mail.ne1.yahoo.com>
Hi
According to Jonathan this patch is still not applied, would anyone
care to resend it as proper git patch so we can review it and
eventually apply it?
Thanks
David
On Tue, Jul 30, 2013 at 11:44 PM, Ulrik De Bie
<ulrik_opensource-kernel@yahoo.com> wrote:
> Hi,
>
> I've a new work laptop Lenovo L530. For 3.2 and 3.9 kernel, the trackpoint
> does not work out of the box. It gives sync errors as shown below when the trackpoint
> or trackpoint mouse buttons are pressed and no input is received by userspace:
> [ 29.010641] psmouse serio1: Touchpad at isa0060/serio1/input0 lost sync at byte 6
> The touchpad does work.
>
> The alternative is to do a downgrade to generic ps/2 mouse (modprobe psmouse proto=bare)
> but this has the disadvantage that touchpad can't be disabled (I want trackpoint, not touchpad).
>
> I did some analysis of the psmouse packets generated, and it became apparent that the
> generated packets are according to a very strict format as described in the elantech_report_trackpoint
> function in the patch below.
>
> With this patch, the trackpoint is provided as another input device; currently called 'My stick'
> The trackpoint now succesfully works and I can disable the touchpad with synclient TouchPadOff=1
> The patch will also output messages that do not follow the expected pattern.
> In the mean time I've seen 2 unknown packets occasionally:
> 0x04 , 0x00 , 0x00 , 0x00 , 0x00 , 0x00
> 0x00 , 0x00 , 0x00 , 0x02 , 0x00 , 0x00
> I don't know what those are for, but they can be safely ignored.
>
> Currently all packets that are not known to v3 touchpad and where packet[3] (the fourth byte) lowest
> nibble is 6 are now recognized as PACKET_TRACKPOINT and processed by the new elantech_report_trackpoint.
>
>
> The first feedback I would appreciate on the patch:
> 1a) Do you think that the creation of the extra input device is the correct way to go ? I saw also a synaptics-pt but I was not able to figure it out and the extra input gave me a desirable result fast.
>
> 1b) What would be the requirements for the name and the phys parameter of the device ?
>
>
> 2) Is the patch correct with regards to ps/2 protocol semantics ? Should it be more restrictive; maybe limited to the 4 patterns used to dump unexpected packets ?
>
> 3) Would a 'trackpoint' detection be required ? I have no idea how to do this because I have a lack of elantech version/capabilities samples, I have just the one on my laptop:
> psmouse serio1: elantech: assuming hardware version 3 (with firmware version 0x350f02)
> psmouse serio1: elantech: Synaptics capabilities query result 0xb9, 0x15, 0x0c.
>
> 4) Is there anyone else with different hardware/firmwareversion/synaptics capabilities where this patch also works ?
>
> The patch below was ported to 3.10.4 kernel (originally made for 3.2 kernel which is the default kernel on my laptop)
>
> Thanks for all feedback and your time,
> Ulrik
>
>
>
>
> diff -uprN -X linux-3.10.4-vanilla/Documentation/dontdiff linux-3.10.4-vanilla/drivers/input/mouse/elantech.c linux-3.10.4/drivers/input/mouse/elantech.c
> --- linux-3.10.4-vanilla/drivers/input/mouse/elantech.c 2013-07-29 01:30:49.000000000 +0200
> +++ linux-3.10.4/drivers/input/mouse/elantech.c 2013-07-30 23:06:12.000000000 +0200
> @@ -402,6 +402,54 @@ static void elantech_report_absolute_v2(
> input_sync(dev);
> }
>
> +static void elantech_report_trackpoint(struct psmouse *psmouse,
> + int packet_type)
> +{
> + /* byte 0: 0 0 ~sx ~sy 0 M R L */
> + /* byte 1: sx 0 0 0 0 0 0 0 */
> + /* byte 2: sy 0 0 0 0 0 0 0 */
> + /* byte 3: 0 0 sy sx 0 1 1 0 */
> + /* byte 4: x7 x6 x5 x4 x3 x2 x1 x0 */
> + /* byte 5: y7 y6 y5 y4 y3 y2 y1 y0 */
> +
> + /*
> + * x and y are written in two's complement spread
> + * over 9 bits with sx/sy the relative top bit and
> + * x7..x0 and y7..y0 the lower bits.
> + * The sign of y is opposite to what the input driver
> + * expects for a relative movement
> + */
> +
> + struct elantech_data *etd = psmouse->private;
> + struct input_dev *dev2 = etd->dev2;
> + unsigned char *packet = psmouse->packet;
> + int x, y;
> + input_report_key(dev2, BTN_LEFT, packet[0] & 0x01);
> + input_report_key(dev2, BTN_RIGHT, packet[0] & 0x02);
> + input_report_key(dev2, BTN_MIDDLE, packet[0] & 0x04);
> + x = (s32) ((u32) ((packet[1] & 0x80) ? 0UL : 0xFFFFFF00UL) | (u32)
> + packet[4]);
> + y = -(s32) ((u32) ((packet[2] & 0x80) ? 0UL : 0xFFFFFF00UL) | (u32)
> + packet[5]);
> + input_report_rel(dev2, REL_X, x);
> + input_report_rel(dev2, REL_Y, y);
> + switch ((((u32) packet[0] & 0xF8) << 24) | ((u32) packet[1] << 16)
> + | (u32) packet[2] << 8 | (u32) packet[3]) {
> + case 0x00808036UL:
> + case 0x10008026UL:
> + case 0x20800016UL:
> + case 0x30000006UL:
> + break;
> + default:
> + /* Dump unexpected packet sequences if debug=1 (default) */
> + if (etd->debug == 1)
> + elantech_packet_dump(psmouse);
> + break;
> + }
> +
> + input_sync(dev2);
> +}
> +
> /*
> * Interpret complete data packets and report absolute mode input events for
> * hardware version 3. (12 byte packets for two fingers)
> @@ -688,6 +736,8 @@ static int elantech_packet_check_v3(stru
> if ((packet[0] & 0x0c) == 0x0c && (packet[3] & 0xce) == 0x0c)
> return PACKET_V3_TAIL;
>
> + if ((packet[3]&0x0f) == 0x06)
> + return PACKET_TRACKPOINT;
> return PACKET_UNKNOWN;
> }
>
> @@ -752,7 +802,10 @@ static psmouse_ret_t elantech_process_by
> if (packet_type == PACKET_UNKNOWN)
> return PSMOUSE_BAD_DATA;
>
> - elantech_report_absolute_v3(psmouse, packet_type);
> + if (packet_type == PACKET_TRACKPOINT)
> + elantech_report_trackpoint(psmouse, packet_type);
> + else
> + elantech_report_absolute_v3(psmouse, packet_type);
> break;
>
> case 4:
> @@ -1236,8 +1289,10 @@ int elantech_detect(struct psmouse *psmo
> */
> static void elantech_disconnect(struct psmouse *psmouse)
> {
> + struct elantech_data *etd = psmouse->private;
> sysfs_remove_group(&psmouse->ps2dev.serio->dev.kobj,
> &elantech_attr_group);
> + input_unregister_device(etd->dev2);
> kfree(psmouse->private);
> psmouse->private = NULL;
> }
> @@ -1323,10 +1378,15 @@ int elantech_init(struct psmouse *psmous
> struct elantech_data *etd;
> int i, error;
> unsigned char param[3];
> + struct input_dev *dev2;
>
> psmouse->private = etd = kzalloc(sizeof(struct elantech_data), GFP_KERNEL);
> if (!etd)
> return -ENOMEM;
> + dev2 = input_allocate_device();
> + if (!dev2)
> + goto init_fail;
> + etd->dev2 = dev2;
>
> psmouse_reset(psmouse);
>
> @@ -1386,9 +1446,26 @@ int elantech_init(struct psmouse *psmous
> psmouse->reconnect = elantech_reconnect;
> psmouse->pktsize = etd->hw_version > 1 ? 6 : 4;
>
> + snprintf(etd->phys, sizeof(etd->phys), "%s/input1",
> + psmouse->ps2dev.serio->phys);
> + dev2->phys = etd->phys;
> + dev2->name = "My stick";
> + dev2->id.bustype = BUS_I8042;
> + dev2->id.vendor = 0x0002;
> + dev2->id.product = PSMOUSE_ELANTECH;
> + dev2->id.version = 0x0000;
> + dev2->dev.parent = &psmouse->ps2dev.serio->dev;
> + dev2->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_REL);
> + dev2->relbit[BIT_WORD(REL_X)] = BIT_MASK(REL_X) | BIT_MASK(REL_Y);
> + dev2->keybit[BIT_WORD(BTN_LEFT)] =
> + BIT_MASK(BTN_LEFT) | BIT_MASK(BTN_MIDDLE) | BIT_MASK(BTN_RIGHT);
> +
> + if (input_register_device(etd->dev2))
> + goto init_fail;
> return 0;
>
> init_fail:
> + input_free_device(dev2);
> kfree(etd);
> return -1;
> }
> diff -uprN -X linux-3.10.4-vanilla/Documentation/dontdiff linux-3.10.4-vanilla/drivers/input/mouse/elantech.h linux-3.10.4/drivers/input/mouse/elantech.h
> --- linux-3.10.4-vanilla/drivers/input/mouse/elantech.h 2013-07-29 01:30:49.000000000 +0200
> +++ linux-3.10.4/drivers/input/mouse/elantech.h 2013-07-30 21:14:09.000000000 +0200
> @@ -94,6 +94,7 @@
> #define PACKET_V4_HEAD 0x05
> #define PACKET_V4_MOTION 0x06
> #define PACKET_V4_STATUS 0x07
> +#define PACKET_TRACKPOINT 0x08
>
> /*
> * track up to 5 fingers for v4 hardware
> @@ -114,6 +115,8 @@ struct finger_pos {
> };
>
> struct elantech_data {
> + struct input_dev *dev2; /* Relative device */
> + char phys[32];
> unsigned char reg_07;
> unsigned char reg_10;
> unsigned char reg_11;
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/4] HID: sony: Use standard output reports instead of raw reports to send data to the Dualshock 4.
From: David Herrmann @ 2014-01-17 17:15 UTC (permalink / raw)
To: Simon Wood; +Cc: Frank Praznik, open list:HID CORE LAYER, Jiri Kosina
In-Reply-To: <da65806f5e5ea0f18f50f882ca569419.squirrel@mungewell.org>
Hi
On Fri, Jan 17, 2014 at 6:10 PM, <simon@mungewell.org> wrote:
>
>>> Use regular HID output reports instead of raw reports in the
>>> dualshock4_state_worker function. (Thanks Simon Mungewell)
>>
>> This description is actually wrong. hid_output_raw_report() is used
>> for regular HID output reports. What you do, is using SET_REPORT to
>> synchronously set output-reports. Anyhow, see below for comments.
>
> Hi David,
> Can you please confirm whether it is preferred to control the DS4 via
> 'hid_hw_request()' rather than 'hid_output_raw_report()'? They both appear
> to work OK...
It's fine. I just wanted to point out that your description is
inverted. According to the specs a device must support both, but that
is not always true. Most devices seem to require SET_REPORT like you
do, but the wiimote for instance requires async output reports (that
is, *not* via synchronous SET_REPORT).
> For the BT connected device we will have to use a different packet to a
> different report.
Given that most vendors just implement crappy HID, there's no way to
know which function is right. So as long as it works, it's usually The
Right Way.
But this patch is already merged, so no reason to worry.
Cheers
David
^ permalink raw reply
* Re: [PATCH 2/4] HID: sony: Use standard output reports instead of raw reports to send data to the Dualshock 4.
From: simon @ 2014-01-17 17:10 UTC (permalink / raw)
To: David Herrmann; +Cc: Frank Praznik, open list:HID CORE LAYER, Jiri Kosina
In-Reply-To: <CANq1E4R3ryPDaivJE-TW=zBnOp9yD5+=-vpVP9zy9OACvud1yw@mail.gmail.com>
>> Use regular HID output reports instead of raw reports in the
>> dualshock4_state_worker function. (Thanks Simon Mungewell)
>
> This description is actually wrong. hid_output_raw_report() is used
> for regular HID output reports. What you do, is using SET_REPORT to
> synchronously set output-reports. Anyhow, see below for comments.
Hi David,
Can you please confirm whether it is preferred to control the DS4 via
'hid_hw_request()' rather than 'hid_output_raw_report()'? They both appear
to work OK...
For the BT connected device we will have to use a different packet to a
different report.
Simon
^ permalink raw reply
* [PATCH] HID: sony: Cache the output report for the Dualshock 4
From: Frank Praznik @ 2014-01-17 16:42 UTC (permalink / raw)
To: linux-input; +Cc: Jiri Kosina
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>
---
Apply against jikos/hid.git/for-3.14/sony
drivers/hid/hid-sony.c | 63 +++++++++++++++++++++++++++++++++++---------------
1 file changed, 44 insertions(+), 19 deletions(-)
diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
index edffe2c..4d5f6d1 100644
--- a/drivers/hid/hid-sony.c
+++ b/drivers/hid/hid-sony.c
@@ -298,6 +298,7 @@ static const unsigned int buzz_keymap[] = {
struct sony_sc {
struct hid_device *hdev;
struct led_classdev *leds[MAX_LEDS];
+ struct hid_report *output_report;
unsigned long quirks;
struct work_struct state_worker;
@@ -743,26 +744,9 @@ static void dualshock4_state_worker(struct work_struct *work)
{
struct sony_sc *sc = container_of(work, struct sony_sc, state_worker);
struct hid_device *hdev = sc->hdev;
- struct list_head *head, *list;
- struct hid_report *report;
- __s32 *value;
-
- list = &hdev->report_enum[HID_OUTPUT_REPORT].report_list;
-
- list_for_each(head, list) {
- report = list_entry(head, struct hid_report, list);
-
- /* Report 5 is used to send data to the controller via USB */
- if ((sc->quirks & DUALSHOCK4_CONTROLLER_USB) && report->id == 5)
- break;
- }
-
- if (head == list) {
- hid_err(hdev, "Dualshock 4 output report not found\n");
- return;
- }
+ struct hid_report *report = sc->output_report;
+ __s32 *value = report->field[0]->value;
- value = report->field[0]->value;
value[0] = 0x03;
#ifdef CONFIG_SONY_FF
@@ -822,6 +806,37 @@ static void sony_destroy_ff(struct hid_device *hdev)
}
#endif
+static int sony_set_output_report(struct sony_sc *sc, int req_id, int req_size)
+{
+ struct list_head *head, *list;
+ struct hid_report *report;
+ struct hid_device *hdev = sc->hdev;
+
+ list = &hdev->report_enum[HID_OUTPUT_REPORT].report_list;
+
+ list_for_each(head, list) {
+ report = list_entry(head, struct hid_report, list);
+
+ if (report->id == req_id) {
+ if (report->size != req_size) {
+ hid_err(hdev, "Requested size of output report 0x%02x (%i bits) does not match actual size (%i bits)\n",
+ req_id, req_size, report->size);
+ return -1;
+ }
+ sc->output_report = report;
+ break;
+ }
+ }
+
+ if (head == list) {
+ hid_err(hdev, "Unable to locate output report 0x%02x\n",
+ req_id);
+ return -1;
+ }
+
+ return 0;
+}
+
static int sony_probe(struct hid_device *hdev, const struct hid_device_id *id)
{
int ret;
@@ -858,6 +873,16 @@ static int sony_probe(struct hid_device *hdev, const struct hid_device_id *id)
return ret;
}
+ if (sc->quirks & DUALSHOCK4_CONTROLLER_USB) {
+ /* Report 0x05 (31 bytes) is used to send data to the controller via USB */
+ ret = sony_set_output_report(sc, 0x05, 248);
+ } else {
+ ret = 0;
+ }
+
+ if (ret < 0)
+ goto err_stop;
+
if (sc->quirks & SIXAXIS_CONTROLLER_USB) {
hdev->hid_output_raw_report = sixaxis_usb_output_raw_report;
ret = sixaxis_set_operational_usb(hdev);
--
1.8.3.2
^ permalink raw reply related
* Re: T440s Synaptics clickpad: lost sync / KBC bad data
From: Jan Bessai @ 2014-01-17 15:24 UTC (permalink / raw)
To: linux-input
Hi all,
I'm having the same issue with a Lenovo T440p. The "lost sync" messages
occur if packets sent by the touchpad don't respect the bitmasks
specified in [1]. Adding some more debug output to the driver reveals,
that packages are garbled in a fairly random pattern, so just using the
less enforcing "SYN_NEWABS_RELAXED" bitmask
(drivers/input/mouse/synaptics.c:1165 , in accordance to manual section
6.1 last bullet point) does not help. Neither does cutting the packet
rate in halve or deactivating all wireless devices (=> not an
interference problem). As far as I can see, sleep flags are never set by
the driver, thus no luck with that either.
Interestingly my BIOS offers a switch to deactivate the touchpad and
just use the trackpoint. This however doesn't work either. As soon as I
trigger some (especially multi touch) activity, the touchpad comes back
and causes trouble. I believe the switch triggers pass-through mode
described in manual [1] section 5.3 and:
> A spontaneous reset of the TouchPad, due to internal sanity checks,
> ESD, or some other problem, will take the device out of transparent
> Pass-Through mode
Disabling the touchpad caused trouble for the Windows driver [2], too:
> <16.3.15.2>
> - (New) Fixed an issue where touchpad was still enabled after having
> been disabled by BIOS.
I was able to reproduce the bug in the Windows 8 Professional installer,
the Debian 7.1 installer, the live CD version of the Ubuntu 14.04
(Trusty Tahr) daily build (14.01.2014, kernel 3.13.x) and my installed
Gentoo system (kernel 3.12.7). I'm not sure, but I think the touchpad
was acting a bit jumpy (but no where as bad) in the pre-installed
version of Windows 7 Professional as well.
For now I'm using the Bios switch to disable the touchpad in combination
with the psmouse module parameter "proto=exps". This allows me to just
use the trackpoint with a primitive ps2 mouse driver and leave the
touchpad disabled (at least if I'm careful enough not to accidentally
rest my palm on it). Being not careful enough however still causes it to
wake up and to inject timeout and bad parity errors, triggering the
cursor to jump around, click aimlessly and finally to hang. As soon as I
can afford to be without the laptop for a few days, I'll ask Lenovo to
replace the touchpad. I don't want to lose my warranty, otherwise I'd
open the notebook [3] and check if perhaps the cables are not in place
or broken. I'll also report back here, if there is anything new.
Greetings,
Jan
[1]: Synaptics PS/2 TouchPad Interfacing Guide.
http://www.synaptics.com/sites/default/files/511-000275-01_RevB.pdf
[2]: Synaptics ThinkPad UltraNav Driver.
http://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles/gggx45ww.txt
[3]: Video training for Lenovo T440p servicing.
http://lenovoservicetraining.com/content/CourseWarePublic/22088/player.html
^ permalink raw reply
* Re: ALPS: Cirque Smart Cat Pro AG Touchpad Support
From: AJ Guillon @ 2014-01-17 16:09 UTC (permalink / raw)
To: Tommy Will; +Cc: linux-input
In-Reply-To: <CA+F6ckMgiF-TrCf1rxNGvGrPHubxdVCtTBsLOKHpg=StRt8BvA@mail.gmail.com>
Hi Tommy,
Here is the touchpad I bought:
http://www.cirque.com/desktoptouchpad/productsandorders/smartcatpro.aspx
(the black USB one).
It works somewhat as a mouse, but isn't recognized as a touchpad.
If there is no chance for Linux support, I'll just return it and
exchange for a brand that does support Linux. If there is something I
can do to help it be supported, I'm happy to do so.
AJ
On 14-01-17 11:01 AM, Tommy Will wrote:
> Hi AJ,
>
> This is Tommy from ALPS. From the PCI ID you attached, it looks like
> an external USB touchpad (?)
> If so, modify alps.c may not let touchpad work since its only for PS/2 device.
>
> I'm sorry although I work in ALPS, I'm not so familar with the
> products made by Cirque.
> However, I'll try to ask our Cirque's colleagues if they have schedule
> to support their products for Linux mainstring.
> Thanks !
>
^ permalink raw reply
* Re: ALPS: Cirque Smart Cat Pro AG Touchpad Support
From: Tommy Will @ 2014-01-17 16:01 UTC (permalink / raw)
To: AJ Guillon; +Cc: linux-input
In-Reply-To: <52D6B45A.4050202@gmail.com>
Hi AJ,
This is Tommy from ALPS. From the PCI ID you attached, it looks like
an external USB touchpad (?)
If so, modify alps.c may not let touchpad work since its only for PS/2 device.
I'm sorry although I work in ALPS, I'm not so familar with the
products made by Cirque.
However, I'll try to ask our Cirque's colleagues if they have schedule
to support their products for Linux mainstring.
Thanks !
--
Best Regards,
Tommy
2014/1/16 AJ Guillon <aj.guillon@gmail.com>:
> Hi everyone,
>
> I bought a Cirque Glidepoint (Model GP415U-5321) that I would like to
> use with Linux. I haven't hacked on the kernel before, but I'm happy to
> test and modify alps.c as required to get this device working.
>
> I downloaded alps-reg-dump from
> git://kernel.ubuntu.com/sforshee/alps-reg-dump.git and it reports:
>
> Found serio mouse at /sys/bus/serio/devices/serio1/
> Invalid ack byte 0xfe after command
> Invalid ack byte 0xfe after command
> E6 report failed, not an ALPS touchpad
>
> The PCI ID of the device is: 0488:0282
>
> I'm not sure if there is anything else I should try. I am currently
> running Ubuntu 12.04 with kernel 3.2.0-29-generic.
>
> AJ
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Patch from down stream which has been forgotten
From: Jonathan Aquilina @ 2014-01-17 12:57 UTC (permalink / raw)
To: David Herrmann; +Cc: Jonathan Aquilina, open list:HID CORE LAYER
In-Reply-To: <CANq1E4QZ22zMagrV37YDm8EYuxcJDK7vXmj9=G7UsPnADe0bkQ@mail.gmail.com>
I can confirm that the bug still exists as per the launchpad bug.
I am on kubuntu 13.10 with kernel 3.11.0
What are the next steps.
On Friday 17 January 2014 13:40:26 David Herrmann wrote:
> Hi
>
> On Tue, Jan 7, 2014 at 2:56 PM, Jonathan Aquilina
>
> <eagles051387@gmail.com> wrote:
> > I have a down stream bug from ubuntu which has been forgotten.
> >
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/967399
> >
> > This fixes multitouch track pads issue where the track pad doesnt work at
> > all.
> >
> > Can I get an update as to the status of the patch which was upstreamed.
>
> You mean that one?
> http://www.spinics.net/lists/linux-input/msg26869.html
>
> It never got applied, would be nice to hear whether that bug still
> exist and have it resubmitted.
>
> Thanks
> David
^ permalink raw reply
* Re: Patch from down stream which has been forgotten
From: David Herrmann @ 2014-01-17 12:40 UTC (permalink / raw)
To: Jonathan Aquilina; +Cc: open list:HID CORE LAYER
In-Reply-To: <49613260.WKf2LBZM10@jaquilina-satellite-s75-a>
Hi
On Tue, Jan 7, 2014 at 2:56 PM, Jonathan Aquilina
<eagles051387@gmail.com> wrote:
> I have a down stream bug from ubuntu which has been forgotten.
>
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/967399
>
> This fixes multitouch track pads issue where the track pad doesnt work at all.
>
> Can I get an update as to the status of the patch which was upstreamed.
You mean that one?
http://www.spinics.net/lists/linux-input/msg26869.html
It never got applied, would be nice to hear whether that bug still
exist and have it resubmitted.
Thanks
David
^ permalink raw reply
* Re: [PATCH 4/4] HID: sony: Map gyroscopes and accelerometers to axes
From: David Herrmann @ 2014-01-17 12:34 UTC (permalink / raw)
To: Jiri Kosina, Dmitry Torokhov
Cc: Antonio Ospite, Frank Praznik, open list:HID CORE LAYER
In-Reply-To: <alpine.LNX.2.00.1401171319500.23018@pobox.suse.cz>
Hi
On Fri, Jan 17, 2014 at 1:21 PM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Fri, 17 Jan 2014, Antonio Ospite wrote:
>
>> > Use a modified HID descriptor for the Dualshock 4 to assign the gyroscope
>> > sensors and accelerometers to axes.
>> >
>>
>> What about putting the descriptor fixup on hold for now?
>> Jiri, have you already pushed these patches?
>>
>> Once the ABS2 stuff from David Hermann is done then proper mapping
>> following the Gamepad API[1] and the Motion-Tracking API[2] could be
>> added.
>>
>> [1] Documentation/input/gamepad.txt
>> [2] Documentation/input/motion-tracking.txt
>>
>> We could even have the DS3 and DS4 expose the same mapping.
>>
>> Just a suggestion.
>
> Hi,
>
> yes, I have already pushed it, but we can of course discuss not including
> it into pull for Linus if necessary.
>
> My understanding is that once ABS2 stuff is done, this can just be
> switched to using it in a backwards-compatible way, and the report fixup
> could be dropped, no?
No. With ABS2 we can introduce ABS_GYRO_X/Y/Z and ABS_ACCEL_X/Y/Z, so
we would change the mappings. Antonio just wants to point out that if
we wait for ABS2, we could use the new mappings right from the
beginning so we never change them and will risk
backwards-incompatibility.
But Dmitry was actually concerned of adding more and more ABS_* bits
due to memory-consumption, I guess. I currently keep the ABS2 patches
on hold until we agree how to move forward. Maybe Dmitry can comment
on that? Because I see no point of introducing ABS2 if we later decide
to not add ABS_* bits for all the different axes.
Thanks
David
^ permalink raw reply
* [PATCHv3 4/4] Input: edt-ft5x06 adjust reset delays according to datasheet
From: Lothar Waßmann @ 2014-01-17 12:28 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Rob Landley, Dmitry Torokhov, Thierry Reding, Grant Likely,
Jonathan Cameron, Shawn Guo, Silvio F, Guennadi Liakhovetski,
Jingoo Han, Fugang Duan, Sachin Kamat, devicetree, linux-doc,
linux-kernel, linux-input
Cc: Lothar Waßmann
In-Reply-To: <1389961718-8130-1-git-send-email-LW@KARO-electronics.de>
The FT5x06 datasheet specifies a minimum reset width of 5ms and a
delay between deassertion of reset and start of reporting of 300ms.
Adjust the delays to conform to the datasheet.
With the original delays I sometimes experienced communication
timeouts when initializing the controller.
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
---
drivers/input/touchscreen/edt-ft5x06.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
index ec6b3e5..bd42845 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -653,9 +653,9 @@ static int edt_ft5x06_ts_reset(struct i2c_client *client,
return error;
}
- mdelay(50);
+ mdelay(5);
gpio_set_value(tsdata->reset_pin, 1);
- mdelay(100);
+ msleep(300);
}
return 0;
--
1.7.2.5
^ permalink raw reply related
* [PATCHv3 3/4] Input: edt-ft5x06: Add DT support
From: Lothar Waßmann @ 2014-01-17 12:28 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Rob Landley, Dmitry Torokhov, Thierry Reding, Grant Likely,
Jonathan Cameron, Shawn Guo, Silvio F, Guennadi Liakhovetski,
Jingoo Han, Fugang Duan, Sachin Kamat, devicetree, linux-doc,
linux-kernel, linux-input
Cc: Lothar Waßmann
In-Reply-To: <1389961718-8130-1-git-send-email-LW@KARO-electronics.de>
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
---
.../bindings/input/touchscreen/edt-ft5x06.txt | 29 +++++
drivers/input/touchscreen/edt-ft5x06.c | 121 +++++++++++++++++---
2 files changed, 132 insertions(+), 18 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
new file mode 100644
index 0000000..826b564
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
@@ -0,0 +1,29 @@
+* EDT FT5x06 Multiple Touch Controller
+
+Required properties:
+- compatible: must be "edt,ft5x06"
+- reg: i2c slave address
+- interrupt-parent: the phandle for the interrupt controller
+- interrupts: touch controller interrupt
+
+Optional properties:
+- reset-gpios: the gpio pin to be used for resetting the controller
+- wake-gpios: the gpio pin to be used for waking up the controller
+
+ The following properties provide default values for the
+ corresponding parameters (see Documentation/input/edt-ft5x06.txt)
+- edt,threshold: allows setting the "click"-threshold in the range from 20 to 80.
+- edt,gain: sensitivity (0..31) (lower value -> higher sensitivity)
+- edt,offset: edge compensation (0..31)
+- edt,report-rate: report rate (3..14) events per 100ms
+
+Example:
+
+ edt_ft5x06@38 {
+ compatible = "edt,ft5x06";
+ reg = <0x38>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <5 0>;
+ reset-gpios = <&gpio2 6 1>;
+ wake-gpios = <&gpio4 9 0>;
+ };
diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
index 583c053..ec6b3e5 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -33,6 +33,7 @@
#include <linux/debugfs.h>
#include <linux/slab.h>
#include <linux/gpio.h>
+#include <linux/of_gpio.h>
#include <linux/input/mt.h>
#include <linux/input/edt-ft5x06.h>
@@ -65,6 +66,10 @@ struct edt_ft5x06_ts_data {
u16 num_x;
u16 num_y;
+ int reset_pin;
+ int irq_pin;
+ int wake_pin;
+
#if defined(CONFIG_DEBUG_FS)
struct dentry *debug_dir;
u8 *raw_buffer;
@@ -481,7 +486,7 @@ static int edt_ft5x06_debugfs_mode_set(void *data, u64 mode)
if (mode != tsdata->factory_mode) {
retval = mode ? edt_ft5x06_factory_mode(tsdata) :
- edt_ft5x06_work_mode(tsdata);
+ edt_ft5x06_work_mode(tsdata);
}
mutex_unlock(&tsdata->mutex);
@@ -619,24 +624,37 @@ edt_ft5x06_ts_teardown_debugfs(struct edt_ft5x06_ts_data *tsdata)
static int edt_ft5x06_ts_reset(struct i2c_client *client,
- int reset_pin)
+ struct edt_ft5x06_ts_data *tsdata)
{
int error;
- if (gpio_is_valid(reset_pin)) {
+ if (gpio_is_valid(tsdata->wake_pin)) {
+ error = devm_gpio_request_one(&client->dev, tsdata->wake_pin,
+ GPIOF_OUT_INIT_LOW, "edt-ft5x06 wake");
+ if (error) {
+ dev_err(&client->dev,
+ "Failed to request GPIO %d as wake pin, error %d\n",
+ tsdata->wake_pin, error);
+ return error;
+ }
+
+ mdelay(5);
+ gpio_set_value(tsdata->wake_pin, 1);
+ }
+ if (gpio_is_valid(tsdata->reset_pin)) {
/* this pulls reset down, enabling the low active reset */
- error = devm_gpio_request_one(&client->dev, reset_pin,
+ error = devm_gpio_request_one(&client->dev, tsdata->reset_pin,
GPIOF_OUT_INIT_LOW,
"edt-ft5x06 reset");
if (error) {
dev_err(&client->dev,
"Failed to request GPIO %d as reset pin, error %d\n",
- reset_pin, error);
+ tsdata->reset_pin, error);
return error;
}
mdelay(50);
- gpio_set_value(reset_pin, 1);
+ gpio_set_value(tsdata->reset_pin, 1);
mdelay(100);
}
@@ -677,6 +695,29 @@ static int edt_ft5x06_ts_identify(struct i2c_client *client,
pdata->name <= edt_ft5x06_attr_##name.limit_high) \
edt_ft5x06_register_write(tsdata, reg, pdata->name)
+#define EDT_GET_PROP(name, var, reg) { \
+ u32 val; \
+ if (of_property_read_u32(np, name, &val) == 0) { \
+ if (val >= edt_ft5x06_attr_##var.limit_low && \
+ val <= edt_ft5x06_attr_##var.limit_high) \
+ edt_ft5x06_register_write(tsdata, reg, val); \
+ else \
+ pr_err("edt_ft5x06: property %s (%u) is out of range: %u..%u", \
+ name, val, edt_ft5x06_attr_##var.limit_low, \
+ edt_ft5x06_attr_##var.limit_high); \
+ } \
+}
+
+static void edt_ft5x06_ts_get_dt_defaults(struct device_node *np,
+ struct edt_ft5x06_ts_data *tsdata)
+{
+ /* pick up defaults from the DT data */
+ EDT_GET_PROP("edt,threshold", threshold, WORK_REGISTER_THRESHOLD);
+ EDT_GET_PROP("edt,gain", gain, WORK_REGISTER_GAIN);
+ EDT_GET_PROP("edt,offset", offset, WORK_REGISTER_OFFSET);
+ EDT_GET_PROP("edt,report-rate", report_rate, WORK_REGISTER_REPORT_RATE);
+}
+
static void
edt_ft5x06_ts_get_defaults(struct edt_ft5x06_ts_data *tsdata,
const struct edt_ft5x06_platform_data *pdata)
@@ -704,6 +745,33 @@ edt_ft5x06_ts_get_parameters(struct edt_ft5x06_ts_data *tsdata)
tsdata->num_y = edt_ft5x06_register_read(tsdata, WORK_REGISTER_NUM_Y);
}
+#ifdef CONFIG_OF
+static int edt_ft5x06_i2c_ts_probe_dt(struct device *dev,
+ struct edt_ft5x06_ts_data *tsdata)
+{
+ struct device_node *np = dev->of_node;
+
+ if (!np)
+ return -ENODEV;
+
+ /*
+ * irq_pin is not needed for DT setup.
+ * irq is associated via 'interrupts' property in DT
+ */
+ tsdata->irq_pin = -EINVAL;
+ tsdata->reset_pin = of_get_named_gpio(np, "reset-gpios", 0);
+ tsdata->wake_pin = of_get_named_gpio(np, "wake-gpios", 0);
+
+ return 0;
+}
+#else
+static inline int edt_ft5x06_i2c_ts_probe_dt(struct device *dev,
+ struct edt_ft5x06_i2c_ts_data *tsdata)
+{
+ return -ENODEV;
+}
+#endif
+
static int edt_ft5x06_ts_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -716,29 +784,42 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client,
dev_dbg(&client->dev, "probing for EDT FT5x06 I2C\n");
+ tsdata = devm_kzalloc(&client->dev, sizeof(*tsdata), GFP_KERNEL);
+ if (!tsdata) {
+ dev_err(&client->dev, "failed to allocate driver data.\n");
+ return -ENOMEM;
+ }
+
if (!pdata) {
- dev_err(&client->dev, "no platform data?\n");
- return -EINVAL;
+ error = edt_ft5x06_i2c_ts_probe_dt(&client->dev, tsdata);
+ if (error) {
+ dev_err(&client->dev,
+ "DT probe failed and no platform data present\n");
+ return error;
+ }
+ } else {
+ tsdata->reset_pin = pdata->reset_pin;
+ tsdata->irq_pin = pdata->irq_pin;
+ tsdata->wake_pin = -EINVAL;
}
- error = edt_ft5x06_ts_reset(client, pdata->reset_pin);
+ error = edt_ft5x06_ts_reset(client, tsdata);
if (error)
return error;
- if (gpio_is_valid(pdata->irq_pin)) {
- error = devm_gpio_request_one(&client->dev, pdata->irq_pin,
- GPIOF_IN, "edt-ft5x06 irq");
+ if (gpio_is_valid(tsdata->irq_pin)) {
+ error = devm_gpio_request_one(&client->dev, tsdata->irq_pin,
+ GPIOF_IN, "edt-ft5x06 irq");
if (error) {
dev_err(&client->dev,
"Failed to request GPIO %d, error %d\n",
- pdata->irq_pin, error);
+ tsdata->irq_pin, error);
return error;
}
}
- tsdata = devm_kzalloc(&client->dev, sizeof(*tsdata), GFP_KERNEL);
input = devm_input_allocate_device(&client->dev);
- if (!tsdata || !input) {
+ if (!input) {
dev_err(&client->dev, "failed to allocate input device.\n");
return -ENOMEM;
}
@@ -754,7 +835,11 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client,
return error;
}
- edt_ft5x06_ts_get_defaults(tsdata, pdata);
+ if (!pdata)
+ edt_ft5x06_ts_get_dt_defaults(client->dev.of_node, tsdata);
+ else
+ edt_ft5x06_ts_get_defaults(tsdata, pdata);
+
edt_ft5x06_ts_get_parameters(tsdata);
dev_dbg(&client->dev,
@@ -807,8 +892,8 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client,
device_init_wakeup(&client->dev, 1);
dev_dbg(&client->dev,
- "EDT FT5x06 initialized: IRQ pin %d, Reset pin %d.\n",
- pdata->irq_pin, pdata->reset_pin);
+ "EDT FT5x06 initialized: IRQ %d, WAKE pin %d, Reset pin %d.\n",
+ client->irq, tsdata->wake_pin, tsdata->reset_pin);
return 0;
}
--
1.7.2.5
^ permalink raw reply related
* [PATCHv3 2/4] Input: edt_ft5x06: use devm_* functions where appropriate
From: Lothar Waßmann @ 2014-01-17 12:28 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Rob Landley, Dmitry Torokhov, Thierry Reding, Grant Likely,
Jonathan Cameron, Shawn Guo, Silvio F, Guennadi Liakhovetski,
Jingoo Han, Fugang Duan, Sachin Kamat, devicetree, linux-doc,
linux-kernel, linux-input
Cc: Lothar Waßmann
In-Reply-To: <1389961718-8130-1-git-send-email-LW@KARO-electronics.de>
Simplify the error path and remove() function by using devm_*
functions for requesting gpios and irq and allocating memory.
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
---
drivers/input/touchscreen/edt-ft5x06.c | 66 +++++++++++---------------------
1 files changed, 23 insertions(+), 43 deletions(-)
diff --git a/drivers/input/touchscreen/edt-ft5x06.c b/drivers/input/touchscreen/edt-ft5x06.c
index af0d68b..583c053 100644
--- a/drivers/input/touchscreen/edt-ft5x06.c
+++ b/drivers/input/touchscreen/edt-ft5x06.c
@@ -366,7 +366,9 @@ static int edt_ft5x06_factory_mode(struct edt_ft5x06_ts_data *tsdata)
if (!tsdata->raw_buffer) {
tsdata->raw_bufsize = tsdata->num_x * tsdata->num_y *
sizeof(u16);
- tsdata->raw_buffer = kzalloc(tsdata->raw_bufsize, GFP_KERNEL);
+ tsdata->raw_buffer = devm_kzalloc(&client->dev,
+ tsdata->raw_bufsize,
+ GFP_KERNEL);
if (!tsdata->raw_buffer) {
error = -ENOMEM;
goto err_out;
@@ -623,8 +625,9 @@ static int edt_ft5x06_ts_reset(struct i2c_client *client,
if (gpio_is_valid(reset_pin)) {
/* this pulls reset down, enabling the low active reset */
- error = gpio_request_one(reset_pin, GPIOF_OUT_INIT_LOW,
- "edt-ft5x06 reset");
+ error = devm_gpio_request_one(&client->dev, reset_pin,
+ GPIOF_OUT_INIT_LOW,
+ "edt-ft5x06 reset");
if (error) {
dev_err(&client->dev,
"Failed to request GPIO %d as reset pin, error %d\n",
@@ -723,7 +726,7 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client,
return error;
if (gpio_is_valid(pdata->irq_pin)) {
- error = gpio_request_one(pdata->irq_pin,
+ error = devm_gpio_request_one(&client->dev, pdata->irq_pin,
GPIOF_IN, "edt-ft5x06 irq");
if (error) {
dev_err(&client->dev,
@@ -733,12 +736,11 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client,
}
}
- tsdata = kzalloc(sizeof(*tsdata), GFP_KERNEL);
- input = input_allocate_device();
+ tsdata = devm_kzalloc(&client->dev, sizeof(*tsdata), GFP_KERNEL);
+ input = devm_input_allocate_device(&client->dev);
if (!tsdata || !input) {
- dev_err(&client->dev, "failed to allocate driver data.\n");
- error = -ENOMEM;
- goto err_free_mem;
+ dev_err(&client->dev, "failed to allocate input device.\n");
+ return -ENOMEM;
}
mutex_init(&tsdata->mutex);
@@ -749,7 +751,7 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client,
error = edt_ft5x06_ts_identify(client, tsdata->name, fw_version);
if (error) {
dev_err(&client->dev, "touchscreen probe failed\n");
- goto err_free_mem;
+ return error;
}
edt_ft5x06_ts_get_defaults(tsdata, pdata);
@@ -776,27 +778,30 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client,
error = input_mt_init_slots(input, MAX_SUPPORT_POINTS, 0);
if (error) {
dev_err(&client->dev, "Unable to init MT slots.\n");
- goto err_free_mem;
+ return error;
}
input_set_drvdata(input, tsdata);
i2c_set_clientdata(client, tsdata);
- error = request_threaded_irq(client->irq, NULL, edt_ft5x06_ts_isr,
- IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
- client->name, tsdata);
+ error = devm_request_threaded_irq(&client->dev, client->irq, NULL,
+ edt_ft5x06_ts_isr,
+ IRQF_TRIGGER_FALLING | IRQF_ONESHOT,
+ client->name, tsdata);
if (error) {
dev_err(&client->dev, "Unable to request touchscreen IRQ.\n");
- goto err_free_mem;
+ return error;
}
error = sysfs_create_group(&client->dev.kobj, &edt_ft5x06_attr_group);
if (error)
- goto err_free_irq;
+ return error;
error = input_register_device(input);
- if (error)
- goto err_remove_attrs;
+ if (error) {
+ sysfs_remove_group(&client->dev.kobj, &edt_ft5x06_attr_group);
+ return error;
+ }
edt_ft5x06_ts_prepare_debugfs(tsdata, dev_driver_string(&client->dev));
device_init_wakeup(&client->dev, 1);
@@ -806,40 +811,15 @@ static int edt_ft5x06_ts_probe(struct i2c_client *client,
pdata->irq_pin, pdata->reset_pin);
return 0;
-
-err_remove_attrs:
- sysfs_remove_group(&client->dev.kobj, &edt_ft5x06_attr_group);
-err_free_irq:
- free_irq(client->irq, tsdata);
-err_free_mem:
- input_free_device(input);
- kfree(tsdata);
-
- if (gpio_is_valid(pdata->irq_pin))
- gpio_free(pdata->irq_pin);
-
- return error;
}
static int edt_ft5x06_ts_remove(struct i2c_client *client)
{
- const struct edt_ft5x06_platform_data *pdata =
- dev_get_platdata(&client->dev);
struct edt_ft5x06_ts_data *tsdata = i2c_get_clientdata(client);
edt_ft5x06_ts_teardown_debugfs(tsdata);
sysfs_remove_group(&client->dev.kobj, &edt_ft5x06_attr_group);
- free_irq(client->irq, tsdata);
- input_unregister_device(tsdata->input);
-
- if (gpio_is_valid(pdata->irq_pin))
- gpio_free(pdata->irq_pin);
- if (gpio_is_valid(pdata->reset_pin))
- gpio_free(pdata->reset_pin);
-
- kfree(tsdata);
-
return 0;
}
--
1.7.2.5
^ permalink raw reply related
* [PATCHv3 1/4] DT: Add vendor prefix for Emerging Display Technologies
From: Lothar Waßmann @ 2014-01-17 12:28 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Rob Landley, Dmitry Torokhov, Thierry Reding, Grant Likely,
Jonathan Cameron, Shawn Guo, Silvio F, Guennadi Liakhovetski,
Jingoo Han, Fugang Duan, Sachin Kamat, devicetree, linux-doc,
linux-kernel, linux-input
Cc: Lothar Waßmann
In-Reply-To: <1389961718-8130-1-git-send-email-LW@KARO-electronics.de>
Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
---
.../devicetree/bindings/vendor-prefixes.txt | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index b458760..49774c3 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -29,6 +29,7 @@ dallas Maxim Integrated Products (formerly Dallas Semiconductor)
davicom DAVICOM Semiconductor, Inc.
denx Denx Software Engineering
dmo Data Modul AG
+edt Emerging Display Technologies
emmicro EM Microelectronic
epson Seiko Epson Corp.
est ESTeem Wireless Modems
--
1.7.2.5
^ permalink raw reply related
* Input: edt-ft5x06: Add DT support
From: Lothar Waßmann @ 2014-01-17 12:28 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Rob Landley, Dmitry Torokhov, Thierry Reding, Grant Likely,
Jonathan Cameron, Shawn Guo, Silvio F, Guennadi Liakhovetski,
Jingoo Han, Fugang Duan, Sachin Kamat, devicetree, linux-doc,
linux-kernel, linux-input
Changes wrt. v1:
addressed the comments from Jingoo Han and Mark Rutland
- added another patch to convert the driver to use devm_* functions
- removed sysfs reference from bindings documentation
- changed '_' to '-' in property name
- added 'edt,' prefix to properties names
- added sanity check for parameters read from DT
- cleaned up the gpio handling code
Changes wrt. v2:
- fixed the devm_* messup reported by Dmitry Torokhov
- added unit for report-rate property to the binding doc
- added separate patch to fix the reset delays
^ permalink raw reply
* Re: [PATCH 4/4] HID: sony: Map gyroscopes and accelerometers to axes
From: Jiri Kosina @ 2014-01-17 12:21 UTC (permalink / raw)
To: Antonio Ospite; +Cc: Frank Praznik, linux-input
In-Reply-To: <20140117125137.ad402d6be31de52a25fedd4a@studenti.unina.it>
On Fri, 17 Jan 2014, Antonio Ospite wrote:
> > Use a modified HID descriptor for the Dualshock 4 to assign the gyroscope
> > sensors and accelerometers to axes.
> >
>
> What about putting the descriptor fixup on hold for now?
> Jiri, have you already pushed these patches?
>
> Once the ABS2 stuff from David Hermann is done then proper mapping
> following the Gamepad API[1] and the Motion-Tracking API[2] could be
> added.
>
> [1] Documentation/input/gamepad.txt
> [2] Documentation/input/motion-tracking.txt
>
> We could even have the DS3 and DS4 expose the same mapping.
>
> Just a suggestion.
Hi,
yes, I have already pushed it, but we can of course discuss not including
it into pull for Linus if necessary.
My understanding is that once ABS2 stuff is done, this can just be
switched to using it in a backwards-compatible way, and the report fixup
could be dropped, no?
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 4/4] HID: sony: Map gyroscopes and accelerometers to axes
From: Antonio Ospite @ 2014-01-17 11:51 UTC (permalink / raw)
To: Frank Praznik; +Cc: linux-input, Jiri Kosina
In-Reply-To: <alpine.DEB.2.10.1401162137400.15779@franz-virtual-machine>
On Thu, 16 Jan 2014 21:43:12 -0500 (EST)
Frank Praznik <frank.praznik@oh.rr.com> wrote:
> Use a modified HID descriptor for the Dualshock 4 to assign the gyroscope
> sensors and accelerometers to axes.
>
What about putting the descriptor fixup on hold for now?
Jiri, have you already pushed these patches?
Once the ABS2 stuff from David Hermann is done then proper mapping
following the Gamepad API[1] and the Motion-Tracking API[2] could be
added.
[1] Documentation/input/gamepad.txt
[2] Documentation/input/motion-tracking.txt
We could even have the DS3 and DS4 expose the same mapping.
Just a suggestion.
Thanks,
Antonio
> Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
>
> ---
>
> Apply against jikos/hid.git/for-3.14/sony
>
> drivers/hid/hid-sony.c | 78 ++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 78 insertions(+)
>
> diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
> index a7c8167..225a4cf 100644
> --- a/drivers/hid/hid-sony.c
> +++ b/drivers/hid/hid-sony.c
> @@ -73,6 +73,73 @@ static const u8 sixaxis_rdesc_fixup2[] = {
> 0xb1, 0x02, 0xc0, 0xc0,
> };
>
> +static u8 dualshock4_usb_rdesc[] = {
> + 0x05, 0x01, 0x09, 0x05, 0xa1, 0x01, 0x85, 0x01,
> + 0x09, 0x30, 0x09, 0x31, 0x09, 0x32, 0x09, 0x35,
> + 0x15, 0x00, 0x26, 0xff, 0x00, 0x75, 0x08, 0x95,
> + 0x04, 0x81, 0x02, 0x09, 0x39, 0x15, 0x00, 0x25,
> + 0x07, 0x35, 0x00, 0x46, 0x3b, 0x01, 0x65, 0x14,
> + 0x75, 0x04, 0x95, 0x01, 0x81, 0x42, 0x65, 0x00,
> + 0x05, 0x09, 0x19, 0x01, 0x29, 0x0e, 0x15, 0x00,
> + 0x25, 0x01, 0x75, 0x01, 0x95, 0x0e, 0x81, 0x02,
> + 0x06, 0x00, 0xff, 0x09, 0x20, 0x75, 0x06, 0x95,
> + 0x01, 0x15, 0x00, 0x25, 0x7f, 0x81, 0x02, 0x05,
> + 0x01, 0x09, 0x33, 0x09, 0x34, 0x15, 0x00, 0x26,
> + 0xff, 0x00, 0x75, 0x08, 0x95, 0x02, 0x81, 0x02,
> + 0x06, 0x00, 0xff, 0x09, 0x21, 0x95, 0x03, 0x81,
> + 0x02, 0x05, 0x01, 0x19, 0x40, 0x29, 0x42, 0x16,
> + 0x00, 0x80, 0x26, 0x00, 0x7f, 0x75, 0x10, 0x95,
> + 0x03, 0x81, 0x02, 0x05, 0x01, 0x19, 0x43, 0x29,
> + 0x45, 0x16, 0xff, 0xbf, 0x26, 0x00, 0x40, 0x95,
> + 0x03, 0x81, 0x02, 0x06, 0x00, 0xff, 0x09, 0x21,
> + 0x75, 0x08, 0x95, 0x27, 0x81, 0x02, 0x85, 0x05,
> + 0x09, 0x22, 0x95, 0x1f, 0x91, 0x02, 0x85, 0x04,
> + 0x09, 0x23, 0x95, 0x24, 0xb1, 0x02, 0x85, 0x02,
> + 0x09, 0x24, 0x95, 0x24, 0xb1, 0x02, 0x85, 0x08,
> + 0x09, 0x25, 0x95, 0x03, 0xb1, 0x02, 0x85, 0x10,
> + 0x09, 0x26, 0x95, 0x04, 0xb1, 0x02, 0x85, 0x11,
> + 0x09, 0x27, 0x95, 0x02, 0xb1, 0x02, 0x85, 0x12,
> + 0x06, 0x02, 0xff, 0x09, 0x21, 0x95, 0x0f, 0xb1,
> + 0x02, 0x85, 0x13, 0x09, 0x22, 0x95, 0x16, 0xb1,
> + 0x02, 0x85, 0x14, 0x06, 0x05, 0xff, 0x09, 0x20,
> + 0x95, 0x10, 0xb1, 0x02, 0x85, 0x15, 0x09, 0x21,
> + 0x95, 0x2c, 0xb1, 0x02, 0x06, 0x80, 0xff, 0x85,
> + 0x80, 0x09, 0x20, 0x95, 0x06, 0xb1, 0x02, 0x85,
> + 0x81, 0x09, 0x21, 0x95, 0x06, 0xb1, 0x02, 0x85,
> + 0x82, 0x09, 0x22, 0x95, 0x05, 0xb1, 0x02, 0x85,
> + 0x83, 0x09, 0x23, 0x95, 0x01, 0xb1, 0x02, 0x85,
> + 0x84, 0x09, 0x24, 0x95, 0x04, 0xb1, 0x02, 0x85,
> + 0x85, 0x09, 0x25, 0x95, 0x06, 0xb1, 0x02, 0x85,
> + 0x86, 0x09, 0x26, 0x95, 0x06, 0xb1, 0x02, 0x85,
> + 0x87, 0x09, 0x27, 0x95, 0x23, 0xb1, 0x02, 0x85,
> + 0x88, 0x09, 0x28, 0x95, 0x22, 0xb1, 0x02, 0x85,
> + 0x89, 0x09, 0x29, 0x95, 0x02, 0xb1, 0x02, 0x85,
> + 0x90, 0x09, 0x30, 0x95, 0x05, 0xb1, 0x02, 0x85,
> + 0x91, 0x09, 0x31, 0x95, 0x03, 0xb1, 0x02, 0x85,
> + 0x92, 0x09, 0x32, 0x95, 0x03, 0xb1, 0x02, 0x85,
> + 0x93, 0x09, 0x33, 0x95, 0x0c, 0xb1, 0x02, 0x85,
> + 0xa0, 0x09, 0x40, 0x95, 0x06, 0xb1, 0x02, 0x85,
> + 0xa1, 0x09, 0x41, 0x95, 0x01, 0xb1, 0x02, 0x85,
> + 0xa2, 0x09, 0x42, 0x95, 0x01, 0xb1, 0x02, 0x85,
> + 0xa3, 0x09, 0x43, 0x95, 0x30, 0xb1, 0x02, 0x85,
> + 0xa4, 0x09, 0x44, 0x95, 0x0d, 0xb1, 0x02, 0x85,
> + 0xa5, 0x09, 0x45, 0x95, 0x15, 0xb1, 0x02, 0x85,
> + 0xa6, 0x09, 0x46, 0x95, 0x15, 0xb1, 0x02, 0x85,
> + 0xf0, 0x09, 0x47, 0x95, 0x3f, 0xb1, 0x02, 0x85,
> + 0xf1, 0x09, 0x48, 0x95, 0x3f, 0xb1, 0x02, 0x85,
> + 0xf2, 0x09, 0x49, 0x95, 0x0f, 0xb1, 0x02, 0x85,
> + 0xa7, 0x09, 0x4a, 0x95, 0x01, 0xb1, 0x02, 0x85,
> + 0xa8, 0x09, 0x4b, 0x95, 0x01, 0xb1, 0x02, 0x85,
> + 0xa9, 0x09, 0x4c, 0x95, 0x08, 0xb1, 0x02, 0x85,
> + 0xaa, 0x09, 0x4e, 0x95, 0x01, 0xb1, 0x02, 0x85,
> + 0xab, 0x09, 0x4f, 0x95, 0x39, 0xb1, 0x02, 0x85,
> + 0xac, 0x09, 0x50, 0x95, 0x39, 0xb1, 0x02, 0x85,
> + 0xad, 0x09, 0x51, 0x95, 0x0b, 0xb1, 0x02, 0x85,
> + 0xae, 0x09, 0x52, 0x95, 0x01, 0xb1, 0x02, 0x85,
> + 0xaf, 0x09, 0x53, 0x95, 0x02, 0xb1, 0x02, 0x85,
> + 0xb0, 0x09, 0x54, 0x95, 0x3f, 0xb1, 0x02, 0xc0,
> +};
> +
Consider using gHID[3] to play with HID descriptors it can generate a C
array representation of the descriptor with indentation and comments
kernel-style.
[3] https://code.google.com/p/ghid/
> static __u8 ps3remote_rdesc[] = {
> 0x05, 0x01, /* GUsagePage Generic Desktop */
> 0x09, 0x05, /* LUsage 0x05 [Game Pad] */
> @@ -307,6 +374,17 @@ static __u8 *sony_report_fixup(struct hid_device *hdev, __u8 *rdesc,
> rdesc[55] = 0x06;
> }
>
> + /*
> + * The default Dualshock 4 USB descriptor doesn't assign
> + * the gyroscope values to corresponding axes so we need a
> + * modified one.
> + */
> + if ((sc->quirks & DUALSHOCK4_CONTROLLER_USB) && *rsize == 467) {
> + hid_info(hdev, "Using modified Dualshock 4 report descriptor with gyroscope axes\n");
> + rdesc = dualshock4_usb_rdesc;
> + *rsize = sizeof(dualshock4_usb_rdesc);
> + }
> +
> /* The HID descriptor exposed over BT has a trailing zero byte */
> if ((((sc->quirks & SIXAXIS_CONTROLLER_USB) && *rsize == 148) ||
> ((sc->quirks & SIXAXIS_CONTROLLER_BT) && *rsize == 149)) &&
> --
> 1.8.3.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Antonio Ospite
http://ao2.it
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
^ permalink raw reply
* Re: [PATCH 0/4] HID: sony: Additional fixes and improvements for the Dualshock 4
From: Antonio Ospite @ 2014-01-17 11:38 UTC (permalink / raw)
To: Frank Praznik; +Cc: linux-input, Jiri Kosina
In-Reply-To: <alpine.DEB.2.10.1401162110240.15779@franz-virtual-machine>
On Thu, 16 Jan 2014 21:42:17 -0500 (EST)
Frank Praznik <frank.praznik@oh.rr.com> wrote:
> These series of patches makes some fixes and improvements to the Dualshock
> 4 driver.
>
Frank, consider using "git send-email" to send out patches next time,
this way the patches will be sent as replies to the cover letter and we
have them grouped together.
Thanks,
Antonio
--
Antonio Ospite
http://ao2.it
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
^ permalink raw reply
* Re: [PATCH 4/4] HID: sony: Map gyroscopes and accelerometers to axes
From: David Herrmann @ 2014-01-17 11:11 UTC (permalink / raw)
To: Frank Praznik; +Cc: open list:HID CORE LAYER, Jiri Kosina
In-Reply-To: <alpine.DEB.2.10.1401162137400.15779@franz-virtual-machine>
Hi
On Fri, Jan 17, 2014 at 3:43 AM, Frank Praznik <frank.praznik@oh.rr.com> wrote:
> 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>
>
> ---
>
> Apply against jikos/hid.git/for-3.14/sony
>
> drivers/hid/hid-sony.c | 78 ++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 78 insertions(+)
>
> diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
> index a7c8167..225a4cf 100644
> --- a/drivers/hid/hid-sony.c
> +++ b/drivers/hid/hid-sony.c
> @@ -73,6 +73,73 @@ static const u8 sixaxis_rdesc_fixup2[] = {
> 0xb1, 0x02, 0xc0, 0xc0,
> };
>
> +static u8 dualshock4_usb_rdesc[] = {
> + 0x05, 0x01, 0x09, 0x05, 0xa1, 0x01, 0x85, 0x01,
> + 0x09, 0x30, 0x09, 0x31, 0x09, 0x32, 0x09, 0x35,
> + 0x15, 0x00, 0x26, 0xff, 0x00, 0x75, 0x08, 0x95,
> + 0x04, 0x81, 0x02, 0x09, 0x39, 0x15, 0x00, 0x25,
> + 0x07, 0x35, 0x00, 0x46, 0x3b, 0x01, 0x65, 0x14,
> + 0x75, 0x04, 0x95, 0x01, 0x81, 0x42, 0x65, 0x00,
> + 0x05, 0x09, 0x19, 0x01, 0x29, 0x0e, 0x15, 0x00,
> + 0x25, 0x01, 0x75, 0x01, 0x95, 0x0e, 0x81, 0x02,
> + 0x06, 0x00, 0xff, 0x09, 0x20, 0x75, 0x06, 0x95,
> + 0x01, 0x15, 0x00, 0x25, 0x7f, 0x81, 0x02, 0x05,
> + 0x01, 0x09, 0x33, 0x09, 0x34, 0x15, 0x00, 0x26,
> + 0xff, 0x00, 0x75, 0x08, 0x95, 0x02, 0x81, 0x02,
> + 0x06, 0x00, 0xff, 0x09, 0x21, 0x95, 0x03, 0x81,
> + 0x02, 0x05, 0x01, 0x19, 0x40, 0x29, 0x42, 0x16,
> + 0x00, 0x80, 0x26, 0x00, 0x7f, 0x75, 0x10, 0x95,
> + 0x03, 0x81, 0x02, 0x05, 0x01, 0x19, 0x43, 0x29,
> + 0x45, 0x16, 0xff, 0xbf, 0x26, 0x00, 0x40, 0x95,
> + 0x03, 0x81, 0x02, 0x06, 0x00, 0xff, 0x09, 0x21,
> + 0x75, 0x08, 0x95, 0x27, 0x81, 0x02, 0x85, 0x05,
> + 0x09, 0x22, 0x95, 0x1f, 0x91, 0x02, 0x85, 0x04,
> + 0x09, 0x23, 0x95, 0x24, 0xb1, 0x02, 0x85, 0x02,
> + 0x09, 0x24, 0x95, 0x24, 0xb1, 0x02, 0x85, 0x08,
> + 0x09, 0x25, 0x95, 0x03, 0xb1, 0x02, 0x85, 0x10,
> + 0x09, 0x26, 0x95, 0x04, 0xb1, 0x02, 0x85, 0x11,
> + 0x09, 0x27, 0x95, 0x02, 0xb1, 0x02, 0x85, 0x12,
> + 0x06, 0x02, 0xff, 0x09, 0x21, 0x95, 0x0f, 0xb1,
> + 0x02, 0x85, 0x13, 0x09, 0x22, 0x95, 0x16, 0xb1,
> + 0x02, 0x85, 0x14, 0x06, 0x05, 0xff, 0x09, 0x20,
> + 0x95, 0x10, 0xb1, 0x02, 0x85, 0x15, 0x09, 0x21,
> + 0x95, 0x2c, 0xb1, 0x02, 0x06, 0x80, 0xff, 0x85,
> + 0x80, 0x09, 0x20, 0x95, 0x06, 0xb1, 0x02, 0x85,
> + 0x81, 0x09, 0x21, 0x95, 0x06, 0xb1, 0x02, 0x85,
> + 0x82, 0x09, 0x22, 0x95, 0x05, 0xb1, 0x02, 0x85,
> + 0x83, 0x09, 0x23, 0x95, 0x01, 0xb1, 0x02, 0x85,
> + 0x84, 0x09, 0x24, 0x95, 0x04, 0xb1, 0x02, 0x85,
> + 0x85, 0x09, 0x25, 0x95, 0x06, 0xb1, 0x02, 0x85,
> + 0x86, 0x09, 0x26, 0x95, 0x06, 0xb1, 0x02, 0x85,
> + 0x87, 0x09, 0x27, 0x95, 0x23, 0xb1, 0x02, 0x85,
> + 0x88, 0x09, 0x28, 0x95, 0x22, 0xb1, 0x02, 0x85,
> + 0x89, 0x09, 0x29, 0x95, 0x02, 0xb1, 0x02, 0x85,
> + 0x90, 0x09, 0x30, 0x95, 0x05, 0xb1, 0x02, 0x85,
> + 0x91, 0x09, 0x31, 0x95, 0x03, 0xb1, 0x02, 0x85,
> + 0x92, 0x09, 0x32, 0x95, 0x03, 0xb1, 0x02, 0x85,
> + 0x93, 0x09, 0x33, 0x95, 0x0c, 0xb1, 0x02, 0x85,
> + 0xa0, 0x09, 0x40, 0x95, 0x06, 0xb1, 0x02, 0x85,
> + 0xa1, 0x09, 0x41, 0x95, 0x01, 0xb1, 0x02, 0x85,
> + 0xa2, 0x09, 0x42, 0x95, 0x01, 0xb1, 0x02, 0x85,
> + 0xa3, 0x09, 0x43, 0x95, 0x30, 0xb1, 0x02, 0x85,
> + 0xa4, 0x09, 0x44, 0x95, 0x0d, 0xb1, 0x02, 0x85,
> + 0xa5, 0x09, 0x45, 0x95, 0x15, 0xb1, 0x02, 0x85,
> + 0xa6, 0x09, 0x46, 0x95, 0x15, 0xb1, 0x02, 0x85,
> + 0xf0, 0x09, 0x47, 0x95, 0x3f, 0xb1, 0x02, 0x85,
> + 0xf1, 0x09, 0x48, 0x95, 0x3f, 0xb1, 0x02, 0x85,
> + 0xf2, 0x09, 0x49, 0x95, 0x0f, 0xb1, 0x02, 0x85,
> + 0xa7, 0x09, 0x4a, 0x95, 0x01, 0xb1, 0x02, 0x85,
> + 0xa8, 0x09, 0x4b, 0x95, 0x01, 0xb1, 0x02, 0x85,
> + 0xa9, 0x09, 0x4c, 0x95, 0x08, 0xb1, 0x02, 0x85,
> + 0xaa, 0x09, 0x4e, 0x95, 0x01, 0xb1, 0x02, 0x85,
> + 0xab, 0x09, 0x4f, 0x95, 0x39, 0xb1, 0x02, 0x85,
> + 0xac, 0x09, 0x50, 0x95, 0x39, 0xb1, 0x02, 0x85,
> + 0xad, 0x09, 0x51, 0x95, 0x0b, 0xb1, 0x02, 0x85,
> + 0xae, 0x09, 0x52, 0x95, 0x01, 0xb1, 0x02, 0x85,
> + 0xaf, 0x09, 0x53, 0x95, 0x02, 0xb1, 0x02, 0x85,
> + 0xb0, 0x09, 0x54, 0x95, 0x3f, 0xb1, 0x02, 0xc0,
> +};
> +
Ugh, wow, hard to review. Could you provide an annotated version like
the ps3remote_rdesc below? As it might get pretty huge, you might
wanna move it to the end of the file (or into a separate file
hid_sony_rdescs.c, I don't know..). It would also be nice to see a
comparison to the original descriptor. Anyhow, patch looks fine
otherwise.
Thanks
David
> static __u8 ps3remote_rdesc[] = {
> 0x05, 0x01, /* GUsagePage Generic Desktop */
> 0x09, 0x05, /* LUsage 0x05 [Game Pad] */
> @@ -307,6 +374,17 @@ static __u8 *sony_report_fixup(struct hid_device *hdev, __u8 *rdesc,
> rdesc[55] = 0x06;
> }
>
> + /*
> + * The default Dualshock 4 USB descriptor doesn't assign
> + * the gyroscope values to corresponding axes so we need a
> + * modified one.
> + */
> + if ((sc->quirks & DUALSHOCK4_CONTROLLER_USB) && *rsize == 467) {
> + hid_info(hdev, "Using modified Dualshock 4 report descriptor with gyroscope axes\n");
> + rdesc = dualshock4_usb_rdesc;
> + *rsize = sizeof(dualshock4_usb_rdesc);
> + }
> +
> /* The HID descriptor exposed over BT has a trailing zero byte */
> if ((((sc->quirks & SIXAXIS_CONTROLLER_USB) && *rsize == 148) ||
> ((sc->quirks & SIXAXIS_CONTROLLER_BT) && *rsize == 149)) &&
> --
> 1.8.3.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/4] HID: sony: Use standard output reports instead of raw reports to send data to the Dualshock 4.
From: David Herrmann @ 2014-01-17 11:09 UTC (permalink / raw)
To: Frank Praznik; +Cc: open list:HID CORE LAYER, Jiri Kosina
In-Reply-To: <alpine.DEB.2.10.1401162134560.15779@franz-virtual-machine>
Hi
On Fri, Jan 17, 2014 at 3:42 AM, Frank Praznik <frank.praznik@oh.rr.com> wrote:
> Use regular HID output reports instead of raw reports in the
> dualshock4_state_worker function. (Thanks Simon Mungewell)
This description is actually wrong. hid_output_raw_report() is used
for regular HID output reports. What you do, is using SET_REPORT to
synchronously set output-reports. Anyhow, see below for comments.
> Signed-off-by: Frank Praznik <frank.praznik@oh.rr.com>
>
> ---
>
> Apply against jikos/hid.git/for-3.14/sony
>
> drivers/hid/hid-sony.c | 45 ++++++++++++++++++++++++++++-----------------
> 1 file changed, 28 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/hid/hid-sony.c b/drivers/hid/hid-sony.c
> index 2f992e1..e623131 100644
> --- a/drivers/hid/hid-sony.c
> +++ b/drivers/hid/hid-sony.c
> @@ -664,28 +664,39 @@ static void sixaxis_state_worker(struct work_struct *work)
> static void dualshock4_state_worker(struct work_struct *work)
> {
> struct sony_sc *sc = container_of(work, struct sony_sc, state_worker);
> - unsigned char buf[] = {
> - 0x05,
> - 0x03, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00, 0x00, 0x00, 0x00, 0x00,
> - 0x00,
> - };
> + struct hid_device *hdev = sc->hdev;
> + struct list_head *head, *list;
> + struct hid_report *report;
> + __s32 *value;
> +
> + list = &hdev->report_enum[HID_OUTPUT_REPORT].report_list;
> +
> + list_for_each(head, list) {
> + report = list_entry(head, struct hid_report, list);
> +
> + /* Report 5 is used to send data to the controller via USB */
> + if ((sc->quirks & DUALSHOCK4_CONTROLLER_USB) && report->id == 5)
> + break;
> + }
> +
> + if (head == list) {
> + hid_err(hdev, "Dualshock 4 output report not found\n");
Are you sure you want to print this error on *every* invokation? I'd
rather like to see this "list_for_each()" in ->probe() and then print
the error once. In ->probe() after you called hid_parse(), the
report-descriptor will not get changed again so it's safe to cache the
report pointer there. At least I don't know any code-path where we'd
change it again. Maybe @Jiri can confirm that.
I'd also like to see a safety check that the given report is long
enough. Otherwise, you might write out of buffer bounds below. But you
can do all this in ->probe().
Thanks
David
> + return;
> + }
> +
> + value = report->field[0]->value;
> + value[0] = 0x03;
>
> #ifdef CONFIG_SONY_FF
> - buf[4] = sc->right;
> - buf[5] = sc->left;
> + value[3] = sc->right;
> + value[4] = sc->left;
> #endif
>
> - buf[6] = sc->led_state[0];
> - buf[7] = sc->led_state[1];
> - buf[8] = sc->led_state[2];
> + value[5] = sc->led_state[0];
> + value[6] = sc->led_state[1];
> + value[7] = sc->led_state[2];
>
> - sc->hdev->hid_output_raw_report(sc->hdev, buf, sizeof(buf),
> - HID_OUTPUT_REPORT);
> + hid_hw_request(hdev, report, HID_REQ_SET_REPORT);
> }
>
> #ifdef CONFIG_SONY_FF
> --
> 1.8.3.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox