Re: [RFC PATCH] hid-sony: fix troubles with Sony remote clones

[Marcelo Ricardo Leitner <mleitner@redhat.com>]

Em 18-12-2012 10:33, Marcelo Ricardo Leitner escreveu:
> Em 16-12-2012 18:37, Jiri Kosina escreveu:
>> On Fri, 14 Dec 2012, Mauro Carvalho Chehab wrote:
>>
>>> 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 <mleitner@redhat.com>
>>> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
>>
>> 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!

Tested-by: Marcelo Leitner <mleitner@redhat.com>