kernel-fxtec-pro1x/drivers/hid/hid-sony.c

275 lines
8.2 KiB
C
Raw Normal View History

/*
* HID driver for some sony "special" devices
*
* Copyright (c) 1999 Andreas Gal
* Copyright (c) 2000-2005 Vojtech Pavlik <vojtech@suse.cz>
* Copyright (c) 2005 Michael Haboustak <mike-@cinci.rr.com> for Concept2, Inc
* Copyright (c) 2008 Jiri Slaby
* Copyright (c) 2006-2008 Jiri Kosina
*/
/*
* This program is free software; you can redistribute it and/or modify it
* under the terms of the GNU General Public License as published by the Free
* Software Foundation; either version 2 of the License, or (at your option)
* any later version.
*/
#include <linux/device.h>
#include <linux/hid.h>
#include <linux/module.h>
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 02:04:11 -06:00
#include <linux/slab.h>
#include <linux/usb.h>
#include "hid-ids.h"
#define VAIO_RDESC_CONSTANT (1 << 0)
#define SIXAXIS_CONTROLLER_USB (1 << 1)
#define SIXAXIS_CONTROLLER_BT (1 << 2)
static const u8 sixaxis_rdesc_fixup[] = {
0x95, 0x13, 0x09, 0x01, 0x81, 0x02, 0x95, 0x0C,
0x81, 0x01, 0x75, 0x10, 0x95, 0x04, 0x26, 0xFF,
0x03, 0x46, 0xFF, 0x03, 0x09, 0x01, 0x81, 0x02
};
HID: 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 <mleitner@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org> Tested-by: Marcelo Leitner <mleitner@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2012-12-14 15:57:34 -07:00
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;
};
/* Sony Vaio VGX has wrongly mouse pointer declared as constant */
static __u8 *sony_report_fixup(struct hid_device *hdev, __u8 *rdesc,
unsigned int *rsize)
{
struct sony_sc *sc = hid_get_drvdata(hdev);
/*
* Some Sony RF receivers wrongly declare the mouse pointer as a
* a constant non-data variable.
*/
if ((sc->quirks & VAIO_RDESC_CONSTANT) && *rsize >= 56 &&
/* usage page: generic desktop controls */
/* rdesc[0] == 0x05 && rdesc[1] == 0x01 && */
/* usage: mouse */
rdesc[2] == 0x09 && rdesc[3] == 0x02 &&
/* input (usage page for x,y axes): constant, variable, relative */
rdesc[54] == 0x81 && rdesc[55] == 0x07) {
HID: add support for Sony RF receiver with USB product id 0x0374 Some Vaio desktop computers, among them the VGC-LN51JGB multimedia PC, have a RF receiver, multi-interface USB device 054c:0374, that is used to connect a wireless keyboard and a wireless mouse. The keyboard works flawlessly, but the mouse (VGP-WMS3 in my case) does not seem to be generating any pointer events. The problem is that the mouse pointer is wrongly declared as a constant non-data variable in the report descriptor (see lsusb and usbhid-dump output below), with the consequence that it is ignored by the HID code. Add this device to the have-special-driver list and fix up the report descriptor in the Sony-specific driver which happens to already have a fixup for a similar firmware bug. # lsusb -vd 054C:0374 Bus 003 Device 002: ID 054c:0374 Sony Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x054c Sony Corp. idProduct 0x0374 iSerial 0 [...] Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 2 Mouse iInterface 2 RF Receiver [...] Report Descriptor: (length is 100) [...] Item(Global): Usage Page, data= [ 0x01 ] 1 Generic Desktop Controls Item(Local ): Usage, data= [ 0x30 ] 48 Direction-X Item(Local ): Usage, data= [ 0x31 ] 49 Direction-Y Item(Global): Report Count, data= [ 0x02 ] 2 Item(Global): Report Size, data= [ 0x08 ] 8 Item(Global): Logical Minimum, data= [ 0x81 ] 129 Item(Global): Logical Maximum, data= [ 0x7f ] 127 Item(Main ): Input, data= [ 0x07 ] 7 Constant Variable Relative No_Wrap Linear Preferred_State No_Null_Position Non_Volatile Bitfield # usbhid-dump 003:002:001:DESCRIPTOR 1357910009.758544 05 01 09 02 A1 01 05 01 09 02 A1 02 85 01 09 01 A1 00 05 09 19 01 29 05 95 05 75 01 15 00 25 01 81 02 75 03 95 01 81 01 05 01 09 30 09 31 95 02 75 08 15 81 25 7F 81 07 A1 02 85 01 09 38 35 00 45 00 15 81 25 7F 95 01 75 08 81 06 C0 A1 02 85 01 05 0C 15 81 25 7F 95 01 75 08 0A 38 02 81 06 C0 C0 C0 C0 Cc: linux-input@vger.kernel.org Cc: linux-usb@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-01-15 03:40:48 -07:00
hid_info(hdev, "Fixing up Sony RF Receiver report descriptor\n");
/* input: data, variable, relative */
rdesc[55] = 0x06;
}
/* 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)) &&
rdesc[83] == 0x75) {
hid_info(hdev, "Fixing up Sony Sixaxis report descriptor\n");
memcpy((void *)&rdesc[83], (void *)&sixaxis_rdesc_fixup,
sizeof(sixaxis_rdesc_fixup));
HID: 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 <mleitner@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org> Tested-by: Marcelo Leitner <mleitner@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2012-12-14 15:57:34 -07:00
} 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;
}
static int sony_raw_event(struct hid_device *hdev, struct hid_report *report,
__u8 *rd, int size)
{
struct sony_sc *sc = hid_get_drvdata(hdev);
/* Sixaxis HID report has acclerometers/gyro with MSByte first, this
* has to be BYTE_SWAPPED before passing up to joystick interface
*/
if ((sc->quirks & (SIXAXIS_CONTROLLER_USB | SIXAXIS_CONTROLLER_BT)) &&
rd[0] == 0x01 && size == 49) {
swap(rd[41], rd[42]);
swap(rd[43], rd[44]);
swap(rd[45], rd[46]);
swap(rd[47], rd[48]);
}
return 0;
}
/*
* The Sony Sixaxis does not handle HID Output Reports on the Interrupt EP
* like it should according to usbhid/hid-core.c::usbhid_output_raw_report()
* so we need to override that forcing HID Output Reports on the Control EP.
*
* There is also another issue about HID Output Reports via USB, the Sixaxis
* does not want the report_id as part of the data packet, so we have to
* discard buf[0] when sending the actual control message, even for numbered
* reports, humpf!
*/
static int sixaxis_usb_output_raw_report(struct hid_device *hid, __u8 *buf,
size_t count, unsigned char report_type)
{
struct usb_interface *intf = to_usb_interface(hid->dev.parent);
struct usb_device *dev = interface_to_usbdev(intf);
struct usb_host_interface *interface = intf->cur_altsetting;
int report_id = buf[0];
int ret;
if (report_type == HID_OUTPUT_REPORT) {
/* Don't send the Report ID */
buf++;
count--;
}
ret = usb_control_msg(dev, usb_sndctrlpipe(dev, 0),
HID_REQ_SET_REPORT,
USB_DIR_OUT | USB_TYPE_CLASS | USB_RECIP_INTERFACE,
((report_type + 1) << 8) | report_id,
interface->desc.bInterfaceNumber, buf, count,
USB_CTRL_SET_TIMEOUT);
/* Count also the Report ID, in case of an Output report. */
if (ret > 0 && report_type == HID_OUTPUT_REPORT)
ret++;
return ret;
}
/*
* Sending HID_REQ_GET_REPORT changes the operation mode of the ps3 controller
* to "operational". Without this, the ps3 controller will not report any
* events.
*/
static int sixaxis_set_operational_usb(struct hid_device *hdev)
{
struct usb_interface *intf = to_usb_interface(hdev->dev.parent);
struct usb_device *dev = interface_to_usbdev(intf);
__u16 ifnum = intf->cur_altsetting->desc.bInterfaceNumber;
int ret;
char *buf = kmalloc(18, GFP_KERNEL);
if (!buf)
return -ENOMEM;
ret = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
HID_REQ_GET_REPORT,
USB_DIR_IN | USB_TYPE_CLASS |
USB_RECIP_INTERFACE,
(3 << 8) | 0xf2, ifnum, buf, 17,
USB_CTRL_GET_TIMEOUT);
if (ret < 0)
hid_err(hdev, "can't set operational mode\n");
kfree(buf);
return ret;
}
static int sixaxis_set_operational_bt(struct hid_device *hdev)
{
unsigned char buf[] = { 0xf4, 0x42, 0x03, 0x00, 0x00 };
return hdev->hid_output_raw_report(hdev, buf, sizeof(buf), HID_FEATURE_REPORT);
}
static int sony_probe(struct hid_device *hdev, const struct hid_device_id *id)
{
int ret;
unsigned long quirks = id->driver_data;
struct sony_sc *sc;
sc = kzalloc(sizeof(*sc), GFP_KERNEL);
if (sc == NULL) {
hid_err(hdev, "can't alloc sony descriptor\n");
return -ENOMEM;
}
sc->quirks = quirks;
hid_set_drvdata(hdev, sc);
ret = hid_parse(hdev);
if (ret) {
hid_err(hdev, "parse failed\n");
goto err_free;
}
ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT |
HID_CONNECT_HIDDEV_FORCE);
if (ret) {
hid_err(hdev, "hw start failed\n");
goto err_free;
}
if (sc->quirks & SIXAXIS_CONTROLLER_USB) {
hdev->hid_output_raw_report = sixaxis_usb_output_raw_report;
ret = sixaxis_set_operational_usb(hdev);
}
else if (sc->quirks & SIXAXIS_CONTROLLER_BT)
ret = sixaxis_set_operational_bt(hdev);
else
ret = 0;
if (ret < 0)
goto err_stop;
return 0;
err_stop:
hid_hw_stop(hdev);
err_free:
kfree(sc);
return ret;
}
static void sony_remove(struct hid_device *hdev)
{
hid_hw_stop(hdev);
kfree(hid_get_drvdata(hdev));
}
static const struct hid_device_id sony_devices[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS3_CONTROLLER),
.driver_data = SIXAXIS_CONTROLLER_USB },
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_NAVIGATION_CONTROLLER),
.driver_data = SIXAXIS_CONTROLLER_USB },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS3_CONTROLLER),
.driver_data = SIXAXIS_CONTROLLER_BT },
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_VAIO_VGX_MOUSE),
.driver_data = VAIO_RDESC_CONSTANT },
HID: add support for Sony RF receiver with USB product id 0x0374 Some Vaio desktop computers, among them the VGC-LN51JGB multimedia PC, have a RF receiver, multi-interface USB device 054c:0374, that is used to connect a wireless keyboard and a wireless mouse. The keyboard works flawlessly, but the mouse (VGP-WMS3 in my case) does not seem to be generating any pointer events. The problem is that the mouse pointer is wrongly declared as a constant non-data variable in the report descriptor (see lsusb and usbhid-dump output below), with the consequence that it is ignored by the HID code. Add this device to the have-special-driver list and fix up the report descriptor in the Sony-specific driver which happens to already have a fixup for a similar firmware bug. # lsusb -vd 054C:0374 Bus 003 Device 002: ID 054c:0374 Sony Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 8 idVendor 0x054c Sony Corp. idProduct 0x0374 iSerial 0 [...] Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 3 Human Interface Device bInterfaceSubClass 1 Boot Interface Subclass bInterfaceProtocol 2 Mouse iInterface 2 RF Receiver [...] Report Descriptor: (length is 100) [...] Item(Global): Usage Page, data= [ 0x01 ] 1 Generic Desktop Controls Item(Local ): Usage, data= [ 0x30 ] 48 Direction-X Item(Local ): Usage, data= [ 0x31 ] 49 Direction-Y Item(Global): Report Count, data= [ 0x02 ] 2 Item(Global): Report Size, data= [ 0x08 ] 8 Item(Global): Logical Minimum, data= [ 0x81 ] 129 Item(Global): Logical Maximum, data= [ 0x7f ] 127 Item(Main ): Input, data= [ 0x07 ] 7 Constant Variable Relative No_Wrap Linear Preferred_State No_Null_Position Non_Volatile Bitfield # usbhid-dump 003:002:001:DESCRIPTOR 1357910009.758544 05 01 09 02 A1 01 05 01 09 02 A1 02 85 01 09 01 A1 00 05 09 19 01 29 05 95 05 75 01 15 00 25 01 81 02 75 03 95 01 81 01 05 01 09 30 09 31 95 02 75 08 15 81 25 7F 81 07 A1 02 85 01 09 38 35 00 45 00 15 81 25 7F 95 01 75 08 81 06 C0 A1 02 85 01 05 0C 15 81 25 7F 95 01 75 08 0A 38 02 81 06 C0 C0 C0 C0 Cc: linux-input@vger.kernel.org Cc: linux-usb@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-01-15 03:40:48 -07:00
{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_VAIO_VGP_MOUSE),
.driver_data = VAIO_RDESC_CONSTANT },
{ }
};
MODULE_DEVICE_TABLE(hid, sony_devices);
static struct hid_driver sony_driver = {
.name = "sony",
.id_table = sony_devices,
.probe = sony_probe,
.remove = sony_remove,
.report_fixup = sony_report_fixup,
.raw_event = sony_raw_event
};
module_hid_driver(sony_driver);
MODULE_LICENSE("GPL");