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: NMarcelo Leitner <mleitner@redhat.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>
Tested-by: NMarcelo Leitner <mleitner@redhat.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

We should not enter close function while someone else is in open.
This mutex prevents this race.

There is also no need to override the ret value with -EIO in case of
a failure of i2c_hid_set_power.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Those IDs aren't necessary anymore.

This reverts commit c8147d9e.
Signed-off-by: NAlexander Holler <holler@ahsoftware.de>
Acked-by: N"Pandruvada, Srinivas" <srinivas.pandruvada@intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

It should not be necessary to add IDs for HID sensor hubs to lists in
hid-core.c and hid-sensor-hub.c. So instead of a whitelist, autodetect such USB
HID sensor hubs, based on a collection of type physical inside a useage page of
type sensor. If some sensor hubs stil must be usable as raw devices, a
blacklist might be created.
Signed-off-by: NAlexander Holler <holler@ahsoftware.de>
Acked-by: N"Pandruvada, Srinivas" <srinivas.pandruvada@intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This patch against kernel 3.7.0-rc8 fixes a kernel oops when turning on the
bluetooth mouse with id 0458:0058 [1].

The mouse in question supports both input and hid sessions, however it is
blacklisted in drivers/hid/hid-core.c so the input session is one that should
be used. Long ago (around kernel 3.0.0) some changes in the bluetooth
subsystem made the kernel do not fallback to input session when hid session is
not supported or blacklisted. This patch restore that behaviour by making the
kernel try the input session if hid_add_device returns ENODEV.

The patch exports hid_ignore() from hid-core.c so that it can be used in the
bluetooth subsystem.

[1] https://bugzilla.kernel.org/show_bug.cgi?id=39882Signed-off-by: NLamarque V. Souza <lamarque@gmail.com>
Acked-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

ret_count has to be at least 3, as we have to count the 2 bytes that are used
for the size of the reply. Without this, memcpy() might be called with zero or
negative count.
Reported-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The previous memcpy implementation relied on the size advertized by the
device. There were no guarantees that buf was big enough.

Some gymnastic is also required with the +2/-2 to take into account
the first 2 bytes of the returned buffer where the total returned
length is supplied by the device.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

There is no point in keeping the irq in i2c_hid as it's already
there in client.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Simplifies i2c_hid_alloc_buffers tests, and makes this function
responsible of the assignment of ihid->bufsize.
The condition for the reallocation in i2c_hid_start is then simpler.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

HID descriptors contains 4 bytes of reserved field.
The previous implementation was overriding the next fields in struct i2c_hid.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The pointless WARN_ON() has been removed from i2c_hid_remove(),
so we don't need bug.h any more.
Reported-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

ihid can not be null, so there are no reasons to test it.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

If i2c_hid_get_report fails, exit i2c_hid_init_report.
The printk log is already called by i2c_hid_get_report, so no need
to add some more printks.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

In the case where the hid driver in charge of handling the hid part
of the device (hid-generic for instance) fails at probe, neither
i2c_hid_start nor i2c_hid_stop are called.
Thus, the buffers allocated in i2c_hid_probe are never freed.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Forwards appropriate return values.
As noone use the error returned by i2c_hid_get_input, let's make it
returning void.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

These definitions are not used here, but are defined by the specification.
Keeping some of them for documentation purposes.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This avoids the problematic case:

if (condition)
	i2c_hid_dbg(ihid, "Blah blah %d\n", i);
else
	do_something_very_important();

Which looks correct, however with the previous macro definition,
this expands to the unexpected:

if (condition) {
	if (debug)	\
		dev_printk(KERN_DEBUG, &ihid->client->dev,
				"Blah blah %d\n", i);
	else
		do_something_very_important();
}
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

We should not initialize to 0 static declarations.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The "comment" part can never be displayed, so we can remove it.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

no I2C driver has "i2c" in its name. It makes more sense to call this
i2c driver "hid".
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NJean Delvare <khali@linux-fr.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Commit 0a97e1e9 ('HID: apple: Add Apple wireless keyboard 2011 ANSI PID')
did not update the special driver list in hid-core.c, so hid-generic may
still bind to this device.
Reported-by: NAri Pollak <ari@scvngr.com>
References: http://bugs.debian.org/694546Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Cc: <stable@vger.kernel.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This just refactors the allocation of hid_input.
No semantic changes.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NHenrik Rydberg <rydberg@euromail.se>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This patch fixes sending SIGIO from hidraw_report_event by creating a fasync
handler which adds the fasync entry.
Signed-off-by: NAndrew Duggan <aduggan@synaptics.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

When the file has been open in non-blocking mode, EIO or ERESTARTSYS
would never be returned even if they should (for example when device
has been unplugged, you want EIO and not EAGAIN to be returned).

Move the O_NONBLOCK check after other checks have been performed.

Base on similar patch done to hidraw by
Founder Fang <founder.fang@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Support battery capacity on another Apple wireless keyboard.
Signed-off-by: NOrtwin Glück <odi@odi.ch>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The USB recovery mode present in i.MX23 ROM emulates USB HID.  It needs this
quirk to behave properly.

Even if the official branding of the chip is Freescale i.MX23, I named it
Sigmatel STMP3780 since that's what the chip really is and it even reports
itself as STMP3780.
Signed-off-by: NMarek Vasut <marex@denx.de>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

When nonblock read the condition check (file->f_flags & O_NONBLOCK) always be
true, signal_pending and device exist checking never get a chance to run, so
the user mode code always get EAGAIN even if device removed. move nonblock mode
checking to the last can fix this problem.
Signed-off-by: NFounder Fang <founder.fang@gmail.com>
Reviewed-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This patch adds support to Novatec wireless mouse (device ID 0603:1602).
Fixes bug https://bugzilla.kernel.org/show_bug.cgi?id=47031Signed-off-by: NMarco Biscaro <marcobiscaro2112@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

In case we are returning from i2c_hid_probe() through the 'err' or
'err_mem_free' labels, there is noone freeing the buffers allocated by
i2c_hid_alloc_buffers().
Reviewed-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

report cannot be NULL, fortunately as we use it before we check !
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Microsoft published the protocol specification of HID over i2c:
http://msdn.microsoft.com/en-us/library/windows/hardware/hh852380.aspx

This patch introduces an implementation of this protocol.

This implementation does not includes the ACPI part of the specification.
This will come when ACPI 5.0 devices enumeration will be available.

Once the ACPI part is done, OEM will not have to declare HID over I2C
devices in their platform specific driver.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

More thorough testing revealed a typo in last koneplus cleanups.
Signed-off-by: NStefan Achatz <erazor_de@users.sourceforge.net>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

No need to check whether unsigned variable is less than 0.

CC: Jiri Kosina <jkosina@suse.cz>
CC: linux-usb@vger.kernel.org
CC: linux-input@vger.kernel.org
Signed-off-by: NTushar Behera <tushar.behera@linaro.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Without this, the device is blocked in dmesg at:
hid-multitouch 0003:25AA:8883.000X: usb_submit_urb(ctrl) failed: -1
hid-multitouch 0003:25AA:8883.000X: timeout initializing reports
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The Win 8 protocol specify the fact that each valid touch must be reported
within a frame until it is released.
We can therefore use the always_valid quirk and dismiss reports when we see
duplicate contacts ID.

We recognize Win8 certified devices from their vendor feature 0xff0000c5
where Microsoft put a signed blob in the report to check if the device
passed the certification.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NHenrik Rydberg <rydberg@euromail.se>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Win8 devices supporting hovering must provides InRange HID field.
The information that the finger is here but is not touching the surface
is sent to the user space through ABS_MT_DISTANCE as required by the
multitouch protocol.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NHenrik Rydberg <rydberg@euromail.se>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This quirk allows a device to reuse a contact id when sending garbage
inactive contacts at the end of a report.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NHenrik Rydberg <rydberg@euromail.se>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Win 8 device specification changed the requirements for the hid usages
of the multitouch devices. Now InRange is optional and must be only
used when the device supports hovering.

This ensures that the quirk ALWAYS_VALID is taken into account and
also ensures its precedence over the other VALID* quirks.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NHenrik Rydberg <rydberg@euromail.se>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Win8 input specification clarifies the X and Y sent by devices.
It distincts the position where the user wants to Touch (T) from
the center of the ellipsoide (C). This patch enable supports for this
distinction in hid-multitouch.
Signed-off-by: NBenjamin Tissoires <benjamin.tissoires@gmail.com>
Reviewed-by: NHenrik Rydberg <rydberg@euromail.se>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>