hid-sony: fix troubles with Sony remote clones

RFC PATCH Applied Mauro Carvalho Chehab 3 participants 6 messages Dec 14, 2012 – Jan 3, 2013 HID

Share & tools

Mauro Carvalho Chehab

author

2012-12-14 22:58 UTC #0 lore raw

RFC PATCH 1/1 hid-sony: fix troubles with Sony remote clones

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 Marcelo Leitner <[email protected]>

Signed-off-by Mauro Carvalho Chehab <[email protected]>

Marcelo,

Could you please test this patch?

drivers/hid/hid-sony.c +28 -0

index 7f33ebf..16df4d8 100644
@@ -33,6 +33,28 @@ static const u8 sixaxis_rdesc_fixup[] = {
 	0x03, 0x46, 0xFF, 0x03, 0x09, 0x01, 0x81, 0x02
 };
 
+static const u8 sixaxis_rdesc_fixup2[] = {
+	0x05, 0x01, 0x09, 0x04, 0xa1, 0x01, 0xa1, 0x02,
+	0x85, 0x01, 0x75, 0x08, 0x95, 0x01, 0x15, 0x00,
+	0x26, 0xff, 0x00, 0x81, 0x03, 0x75, 0x01, 0x95,
+	0x13, 0x15, 0x00, 0x25, 0x01, 0x35, 0x00, 0x45,
+	0x01, 0x05, 0x09, 0x19, 0x01, 0x29, 0x13, 0x81,
+	0x02, 0x75, 0x01, 0x95, 0x0d, 0x06, 0x00, 0xff,
+	0x81, 0x03, 0x15, 0x00, 0x26, 0xff, 0x00, 0x05,
+	0x01, 0x09, 0x01, 0xa1, 0x00, 0x75, 0x08, 0x95,
+	0x04, 0x35, 0x00, 0x46, 0xff, 0x00, 0x09, 0x30,
+	0x09, 0x31, 0x09, 0x32, 0x09, 0x35, 0x81, 0x02,
+	0xc0, 0x05, 0x01, 0x95, 0x13, 0x09, 0x01, 0x81,
+	0x02, 0x95, 0x0c, 0x81, 0x01, 0x75, 0x10, 0x95,
+	0x04, 0x26, 0xff, 0x03, 0x46, 0xff, 0x03, 0x09,
+	0x01, 0x81, 0x02, 0xc0, 0xa1, 0x02, 0x85, 0x02,
+	0x75, 0x08, 0x95, 0x30, 0x09, 0x01, 0xb1, 0x02,
+	0xc0, 0xa1, 0x02, 0x85, 0xee, 0x75, 0x08, 0x95,
+	0x30, 0x09, 0x01, 0xb1, 0x02, 0xc0, 0xa1, 0x02,
+	0x85, 0xef, 0x75, 0x08, 0x95, 0x30, 0x09, 0x01,
+	0xb1, 0x02, 0xc0, 0xc0,
+};
+
 struct sony_sc {
 	unsigned long quirks;
 };

@@ -56,6 +78,12 @@ static __u8 *sony_report_fixup(struct hid_device *hdev, __u8 *rdesc,
 		hid_info(hdev, "Fixing up Sony Sixaxis report descriptor\n");
 		memcpy((void *)&rdesc[83], (void *)&sixaxis_rdesc_fixup,
 			sizeof(sixaxis_rdesc_fixup));
+	} else if (sc->quirks & SIXAXIS_CONTROLLER_USB &&
+		   *rsize > sizeof(sixaxis_rdesc_fixup2)) {
+		hid_info(hdev, "Sony Sixaxis clone detected. Using original report descriptor (size: %d clone; %d new)\n",
+			 *rsize, (int)sizeof(sixaxis_rdesc_fixup2));
+		*rsize = sizeof(sixaxis_rdesc_fixup2);
+		memcpy(rdesc, &sixaxis_rdesc_fixup2, *rsize);
 	}
 	return rdesc;
 }

Jiri Kosina

2012-12-16 20:37 UTC #1 lore raw

Quoted 57 lines · Mauro Carvalho Chehab

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

Quoted 7 lines

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 Marcelo Leitner <[email protected]>
Signed-off-by Mauro Carvalho Chehab <[email protected]>

Yeah, this is the way I'd like to have it fixed.

Waiting for Marcelo's Tested-by: before merging it.

Thanks,

Signature · 2 lines

Jiri Kosina
SUSE Labs

Mauro Carvalho Chehab

author

2012-12-17 14:18 UTC #2 lore raw

Hi Jiri,

Em Sun, 16 Dec 2012 21:37:07 +0100 (CET)
Jiri Kosina <[email protected]> escreveu:

Quoted 62 lines · Mauro Carvalho Chehab

Quoted 61 lines
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):

Quoted 8 lines

Quoted 4 lines
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 Marcelo Leitner <[email protected]>
Signed-off-by Mauro Carvalho Chehab <[email protected]>
Yeah, this is the way I'd like to have it fixed.
Waiting for Marcelo's Tested-by: before merging it.

Thanks for reviewing! Marcelo only saw it today. He is promising to test it this night.

There's one thing that still bothers me: the default keymapping for this remote is really weird. Worse than that, it is also different than the one used by hid-ps3remote.c.

While I think it would be better to add specific buttons for keys square, round, circle, cross, it doesn't make sense to have it different than the one defined on ps3remote HID.

The enclosed patch should fix it, adding the same mapping found at ps3remote (except for scancode 0x14 - that doesn't seem to exist on sixaxis).

Regards,
Mauro

-
From: Mauro Carvalho Chehab <[email protected]>

[PATCH] hid-sony: add a keymap for Sony 6-axis remote

The keymap there matches the one defined by hid-ps3remote. This way, similar keypad controllers will use similar keys.

Tested with an original PS3 6-axis remote and with a wireless clone (MadCatz Dualforce3).

Signed-off-by Mauro Carvalho Chehab <[email protected]>

drivers/hid/hid-sony.c +45 -1

index 16df4d8..7eb1870 100644
@@ -27,6 +27,26 @@
 #define SIXAXIS_CONTROLLER_USB  (1 << 1)
 #define SIXAXIS_CONTROLLER_BT   (1 << 2)
 
+static const unsigned int ps3remote_keymap_joypad_buttons[] = {
+	[0x01] = KEY_SELECT,
+	[0x02] = BTN_THUMBL,		/* L3 */
+	[0x03] = BTN_THUMBR,		/* R3 */
+	[0x04] = BTN_START,
+	[0x05] = KEY_UP,
+	[0x06] = KEY_RIGHT,
+	[0x07] = KEY_DOWN,
+	[0x08] = KEY_LEFT,
+	[0x09] = BTN_TL2,		/* L2 */
+	[0x0a] = BTN_TR2,		/* R2 */
+	[0x0b] = BTN_TL,		/* L1 */
+	[0x0c] = BTN_TR,		/* R1 */
+	[0x0d] = KEY_OPTION,		/* options/triangle */
+	[0x0e] = KEY_BACK,		/* back/circle */
+	[0x0f] = BTN_0,			/* cross */
+	[0x10] = KEY_SCREEN,		/* view/square */
+	[0x11] = KEY_HOMEPAGE,		/* PS button */
+};
+
 static const u8 sixaxis_rdesc_fixup[] = {
 	0x95, 0x13, 0x09, 0x01, 0x81, 0x02, 0x95, 0x0C,
 	0x81, 0x01, 0x75, 0x10, 0x95, 0x04, 0x26, 0xFF,

@@ -182,6 +202,29 @@ static int sixaxis_set_operational_bt(struct hid_device *hdev)
 	return hdev->hid_output_raw_report(hdev, buf, sizeof(buf), HID_FEATURE_REPORT);
 }
 
+static int sony_mapping(struct hid_device *hdev, struct hid_input *hi,
+			     struct hid_field *field, struct hid_usage *usage,
+			     unsigned long **bit, int *max)
+{
+	unsigned int key = usage->hid;
+
+	/* Remaps buttons only */
+	if ((key & ~0xff) != 0x90000)
+		return 0;
+
+	key &= 0xff;
+	if (key >= ARRAY_SIZE(ps3remote_keymap_joypad_buttons))
+		return -1;
+
+	key = ps3remote_keymap_joypad_buttons[key];
+	if (!key)
+		return -1;
+
+	hid_map_usage_clear(hi, usage, bit, max, EV_KEY, key);
+	return 1;
+}
+
+
 static int sony_probe(struct hid_device *hdev, const struct hid_device_id *id)
 {
 	int ret;

@@ -255,7 +298,8 @@ static struct hid_driver sony_driver = {
 	.probe = sony_probe,
 	.remove = sony_remove,
 	.report_fixup = sony_report_fixup,
-	.raw_event = sony_raw_event
+	.raw_event = sony_raw_event,
+	.input_mapping = sony_mapping,
 };
 
 static int __init sony_init(void)

Marcelo Ricardo Leitner

2012-12-18 12:34 UTC #3 lore raw

In reply to Jiri Kosina

Em 16-12-2012 18:37, Jiri Kosina escreveu:

Quoted 62 lines · Mauro Carvalho Chehab

Quoted 61 lines
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):

Quoted 8 lines

Quoted 4 lines
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 Marcelo Leitner <[email protected]>
Signed-off-by Mauro Carvalho Chehab <[email protected]>
Yeah, this is the way I'd like to have it fixed.
Waiting for Marcelo's Tested-by: before merging it.

Hey, this patch works very nice, in the sense that now all buttons generate KEY events although some with weird meanings.. but that is topic for the next patch.

So I'm happy with the results of this one. Any report I should present for confirmation or not needed?

My dmesg output:

Dec 18 10:30:43 localhost kernel: [ 2908.370116] usb 2-1.1: new full-speed USB device number 5 using ehci_hcd

Dec 18 10:30:43 localhost kernel: [ 2908.458218] usb 2-1.1: New USB device found, idVendor=054c, idProduct=0268

Dec 18 10:30:43 localhost kernel: [ 2908.458225] usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0

Dec 18 10:30:43 localhost kernel: [ 2908.458229] usb 2-1.1: Product: PC USB Controller

Dec 18 10:30:43 localhost kernel: [ 2908.458233] usb 2-1.1: Manufacturer: Gamepad

Dec 18 10:30:43 localhost kernel: [ 2908.460529] sony 0003:054C:0268.0004: Sony Sixaxis clone detected. Using original report descriptor (size: 184 clone; 148 new)
Dec 18 10:30:43 localhost kernel: [ 2908.461973] input: Gamepad PC USB Controller as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.0/input/input19
Dec 18 10:30:43 localhost kernel: [ 2908.462675] sony 0003:054C:0268.0004: input,hiddev0,hidraw1: USB HID v1.11 Joystick [Gamepad PC USB Controller] on usb-0000:00:1d.0-1.1/input0

Previously there was no Sixaxis quirk being loaded for this one.

And /sys/kernel/debug/hid/<ID>/rdesc now is identical to the original Sixaxis.

Thanks Mauro, great job in there!

Marcelo.

Marcelo Ricardo Leitner

Tested-by

2012-12-18 12:54 UTC #4 lore raw

Em 18-12-2012 10:33, Marcelo Ricardo Leitner escreveu:

Quoted 115 lines

Em 16-12-2012 18:37, Jiri Kosina escreveu:
Quoted 77 lines · Mauro Carvalho Chehab
Quoted 76 lines
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
Quoted 6 lines
Quoted 2 lines
Reported-by Marcelo Leitner <[email protected]>
Signed-off-by Mauro Carvalho Chehab <[email protected]>
Yeah, this is the way I'd like to have it fixed.
Waiting for Marcelo's Tested-by: before merging it.
Hey, this patch works very nice, in the sense that now all buttons generate KEY events although some with weird meanings.. but that is topic for the next patch.
So I'm happy with the results of this one. Any report I should present for confirmation or not needed?
My dmesg output:
Dec 18 10:30:43 localhost kernel: [ 2908.370116] usb 2-1.1: new
full-speed USB device number 5 using ehci_hcd
Dec 18 10:30:43 localhost kernel: [ 2908.458218] usb 2-1.1: New USB
device found, idVendor=054c, idProduct=0268
Dec 18 10:30:43 localhost kernel: [ 2908.458225] usb 2-1.1: New USB
device strings: Mfr=1, Product=2, SerialNumber=0
Dec 18 10:30:43 localhost kernel: [ 2908.458229] usb 2-1.1: Product: PC
USB Controller
Dec 18 10:30:43 localhost kernel: [ 2908.458233] usb 2-1.1:
Manufacturer: Gamepad
Dec 18 10:30:43 localhost kernel: [ 2908.460529] sony
0003:054C:0268.0004: Sony Sixaxis clone detected. Using original report
descriptor (size: 184 clone; 148 new)
Dec 18 10:30:43 localhost kernel: [ 2908.461973] input: Gamepad PC USB
Controller as
/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.1/2-1.1:1.0/input/input19
Dec 18 10:30:43 localhost kernel: [ 2908.462675] sony
0003:054C:0268.0004: input,hiddev0,hidraw1: USB HID v1.11 Joystick [Gamepad PC USB Controller] on usb-0000:00:1d.0-1.1/input0

Quoted 6 lines

Previously there was no Sixaxis quirk being loaded for this one.
And /sys/kernel/debug/hid/<ID>/rdesc now is identical to the original Sixaxis.
Thanks Mauro, great job in there!

Tested-by Marcelo Leitner <[email protected]>

Jiri Kosina

Applied

2013-01-03 09:49 UTC #5 lore raw

Quoted 1 line · Marcelo Ricardo Leitner

Em 18-12-2012 10:33, Marcelo Ricardo Leitner escreveu:

[ ... snip ... ]

Quoted 1 line

Tested-by Marcelo Leitner <[email protected]>

Applied, thanks guys.

Signature · 2 lines

Jiri Kosina
SUSE Labs