linux-toradex.git/drivers/hid/hid-wiimote.h, branch v3.17 Linux kernel for Apalis and Colibri modules Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid 2013-11-16T00:48:22+00:00 Linus Torvalds torvalds@linux-foundation.org 2013-11-16T00:48:22+00:00 e0da5c9a49b927d9e5f62b21a7abc283e99022e2 Pull HID updates from Jiri Kosina: - i2c-hid is not querying init reports any more, as it's not mandated by the spec, and annoys quite a few devices during enumeration, by Bibek Basu - a lot of fixes for Logitech devices, by Simon Wood - hid-apple now has an option to switch between Option and Command mode, by Nanno Langstraat - Some more workarounds for severely broken ELO devices, by Oliver Neukum - more devm conversions, by Benjamin Tissoires - wiimote correctness fixes, by David Herrmann - a lot of added support for various new device IDs and random small fixes here and there" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid: (34 commits) HID: enable Mayflash USB Gamecube Adapter HID: sony: Add force feedback support for Dualshock3 USB Input: usbtouchscreen: ignore eGalax/D-Wav/EETI HIDs HID: don't ignore eGalax/D-Wav/EETI HIDs HID: roccat: add missing special driver declarations HID:hid-lg4ff: Correct Auto-center strength for wheels other than MOMO and MOMO2 HID:hid-lg4ff: Initialize device properties before we touch autocentering. HID:hid-lg4ff: ensure ConstantForce is disabled when set to 0 HID:hid-lg4ff: Switch autocentering off when strength is set to zero. HID:hid-lg4ff: Scale autocentering force properly on Logitech wheel HID: roccat: fix Coverity CID 141438 HID: multitouch: add manufacturer to Kconfig help text HID: logitech-dj: small cleanup in rdcat() HID: remove self-assignment from hid_input_report HID: hid-sensor-hub: fix report size HID: i2c-hid: Stop querying for init reports HID: roccat: add support for Ryos MK keyboards HID: roccat: generalize some common code HID: roccat: add new device return value HID: wiimote: add pro-controller analog stick calibration ... 
Pull HID updates from Jiri Kosina:
 - i2c-hid is not querying init reports any more, as it's not mandated
   by the spec, and annoys quite a few devices during enumeration, by
   Bibek Basu
 - a lot of fixes for Logitech devices, by Simon Wood
 - hid-apple now has an option to switch between Option and Command
   mode, by Nanno Langstraat
 - Some more workarounds for severely broken ELO devices, by Oliver
   Neukum
 - more devm conversions, by Benjamin Tissoires
 - wiimote correctness fixes, by David Herrmann
 - a lot of added support for various new device IDs and random small
   fixes here and there"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid: (34 commits)
  HID: enable Mayflash USB Gamecube Adapter
  HID: sony: Add force feedback support for Dualshock3 USB
  Input: usbtouchscreen: ignore eGalax/D-Wav/EETI HIDs
  HID: don't ignore eGalax/D-Wav/EETI HIDs
  HID: roccat: add missing special driver declarations
  HID:hid-lg4ff: Correct Auto-center strength for wheels other than MOMO and MOMO2
  HID:hid-lg4ff: Initialize device properties before we touch autocentering.
  HID:hid-lg4ff: ensure ConstantForce is disabled when set to 0
  HID:hid-lg4ff: Switch autocentering off when strength is set to zero.
  HID:hid-lg4ff: Scale autocentering force properly on Logitech wheel
  HID: roccat: fix Coverity CID 141438
  HID: multitouch: add manufacturer to Kconfig help text
  HID: logitech-dj: small cleanup in rdcat()
  HID: remove self-assignment from hid_input_report
  HID: hid-sensor-hub: fix report size
  HID: i2c-hid: Stop querying for init reports
  HID: roccat: add support for Ryos MK keyboards
  HID: roccat: generalize some common code
  HID: roccat: add new device return value
  HID: wiimote: add pro-controller analog stick calibration
  ...
tree-wide: use reinit_completion instead of INIT_COMPLETION 2013-11-15T00:32:21+00:00 Wolfram Sang wsa@the-dreams.de 2013-11-14T22:32:02+00:00 16735d022f72b20ddbb2274b8e109f69575e9b2b Use this new function to make code more comprehensible, since we are reinitialzing the completion, not initializing. [akpm@linux-foundation.org: linux-next resyncs] Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Acked-by: Linus Walleij <linus.walleij@linaro.org> (personally at LCE13) Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
Use this new function to make code more comprehensible, since we are
reinitialzing the completion, not initializing.

[akpm@linux-foundation.org: linux-next resyncs]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Acked-by: Linus Walleij <linus.walleij@linaro.org> (personally at LCE13)
Cc: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
HID: wiimote: add pro-controller analog stick calibration 2013-10-30T13:13:29+00:00 David Herrmann dh.herrmann@gmail.com 2013-10-28T16:49:20+00:00 08072dde333c2f09114a01b0bd32be52ecce195b The analog sticks of the pro-controller might report slightly off values. To guarantee a uniform setup, we now calibrate analog-stick values during pro-controller setup. Unfortunately, the pro-controller fails during normal EEPROM reads and I couldn't figure out whether there are any calibration values stored on the device. Therefore, we now use the first values reported by the device (iff they are not _way_ off, which would indicate movement) to initialize the calibration values. To allow users to change this calibration data, we provide a pro_calib sysfs attribute. We also change the "flat" values so user-space correctly smoothes our data. It makes slightly off zero-positions less visible while still guaranteeing highly precise movement reports. Note that the pro controller reports zero-positions in a quite huge range (at least: -100 to +100). Reported-by: Rafael Brune <mail@rbrune.de> Tested-by: Rafael Brune <mail@rbrune.de> Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> 
The analog sticks of the pro-controller might report slightly off values.
To guarantee a uniform setup, we now calibrate analog-stick values during
pro-controller setup.

Unfortunately, the pro-controller fails during normal EEPROM reads and I
couldn't figure out whether there are any calibration values stored on the
device. Therefore, we now use the first values reported by the device (iff
they are not _way_ off, which would indicate movement) to initialize the
calibration values. To allow users to change this calibration data, we
provide a pro_calib sysfs attribute.

We also change the "flat" values so user-space correctly smoothes our
data. It makes slightly off zero-positions less visible while still
guaranteeing highly precise movement reports. Note that the pro controller
reports zero-positions in a quite huge range (at least: -100 to +100).

Reported-by: Rafael Brune <mail@rbrune.de>
Tested-by: Rafael Brune <mail@rbrune.de>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
HID: wiimote: fix FF deadlock 2013-10-07T15:08:26+00:00 David Herrmann dh.herrmann@gmail.com 2013-10-02T11:47:28+00:00 f50f9aabf32db7414551ffdfdccc71be5f3d6e7d The input core has an internal spinlock that is acquired during event injection via input_event() and friends but also held during FF callbacks. That means, there is no way to share a lock between event-injection and FF handling. Unfortunately, this is what is required for wiimote state tracking and what we do with state.lock and input->lock. This deadlock can be triggered when using continuous data reporting and FF on a wiimote device at the same time. I takes me at least 30m of stress-testing to trigger it but users reported considerably shorter times (http://bpaste.net/show/132504/) when using some gaming-console emulators. The real problem is that we have two copies of internal state, one in the wiimote objects and the other in the input device. As the input-lock is not supposed to be accessed from outside of input-core, we have no other chance than offloading FF handling into a worker. This actually works pretty nice and also allows to implictly merge fast rumble changes into a single request. Due to the 3-layered workers (rumble+queue+l2cap) this might reduce FF responsiveness. Initial tests were fine so lets fix the race first and if it turns out to be too slow we can always handle FF out-of-band and skip the queue-worker. Cc: <stable@vger.kernel.org> # 3.11+ Reported-by: Thomas Schneider Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> 
The input core has an internal spinlock that is acquired during event
injection via input_event() and friends but also held during FF callbacks.
That means, there is no way to share a lock between event-injection and FF
handling. Unfortunately, this is what is required for wiimote state
tracking and what we do with state.lock and input->lock.

This deadlock can be triggered when using continuous data reporting and FF
on a wiimote device at the same time. I takes me at least 30m of
stress-testing to trigger it but users reported considerably shorter
times (http://bpaste.net/show/132504/) when using some gaming-console
emulators.

The real problem is that we have two copies of internal state, one in the
wiimote objects and the other in the input device. As the input-lock is
not supposed to be accessed from outside of input-core, we have no other
chance than offloading FF handling into a worker. This actually works
pretty nice and also allows to implictly merge fast rumble changes into a
single request.

Due to the 3-layered workers (rumble+queue+l2cap) this might reduce FF
responsiveness. Initial tests were fine so lets fix the race first and if
it turns out to be too slow we can always handle FF out-of-band and skip
the queue-worker.

Cc: <stable@vger.kernel.org> # 3.11+
Reported-by: Thomas Schneider
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Revert "Input: introduce BTN/ABS bits for drums and guitars" 2013-09-07T16:48:41+00:00 Linus Torvalds torvalds@linux-foundation.org 2013-09-07T16:48:41+00:00 b04c99e3b845892d754ee8052d6324c39c4040de This reverts commits 61e00655e9cb, 73f8645db191 and 8e22ecb603c8: "Input: introduce BTN/ABS bits for drums and guitars" "HID: wiimote: add support for Guitar-Hero drums" "HID: wiimote: add support for Guitar-Hero guitars" The extra new ABS_xx values resulted in ABS_MAX no longer being a power-of-two, which broke the comparison logic. It also caused the ioctl numbers to overflow into the next byte, causing problems for that. We'll try again for 3.13. Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de> Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Acked-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Benjamin Tissoires <benjamin.tissoires@gmail.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> 
This reverts commits 61e00655e9cb, 73f8645db191 and 8e22ecb603c8:
  "Input: introduce BTN/ABS bits for drums and guitars"
  "HID: wiimote: add support for Guitar-Hero drums"
  "HID: wiimote: add support for Guitar-Hero guitars"

The extra new ABS_xx values resulted in ABS_MAX no longer being a
power-of-two, which broke the comparison logic.  It also caused the
ioctl numbers to overflow into the next byte, causing problems for that.

We'll try again for 3.13.

Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: David Herrmann <dh.herrmann@gmail.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
HID: wiimote: add support for Guitar-Hero guitars 2013-09-04T08:44:17+00:00 Nicolas Adenis-Lamarre nicolas.adenis.lamarre@gmail.com 2013-08-26T17:14:48+00:00 8e22ecb603c88b7397ab2e80b7b0811b8a1318f5 Apart from drums, Guitar-Hero also ships with guitars. Use the recently introduced input ABS/BTN-bits to report this to user-space. Devices are reported as "Nintendo Wii Remote Guitar". If I ever get my hands on "RockBand" guitars, I will try to report them via the same interface so user-space does not have to bother which device it deals with. Signed-off-by: Nicolas.Adenis-Lamarre <nicolas.adenis.lamarre@gmail.com> (add commit-msg and adjust to new BTN_* IDs) Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> 
Apart from drums, Guitar-Hero also ships with guitars. Use the recently
introduced input ABS/BTN-bits to report this to user-space.

Devices are reported as "Nintendo Wii Remote Guitar". If I ever get my
hands on "RockBand" guitars, I will try to report them via the same
interface so user-space does not have to bother which device it deals
with.

Signed-off-by: Nicolas.Adenis-Lamarre <nicolas.adenis.lamarre@gmail.com>
(add commit-msg and adjust to new BTN_* IDs)
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
HID: wiimote: add support for Guitar-Hero drums 2013-09-04T08:44:17+00:00 David Herrmann dh.herrmann@gmail.com 2013-08-26T17:14:47+00:00 73f8645db1913ab2475ec3c1cee8d5f748963aa7 Guitar-Hero comes with a drums extension. Use the newly introduced input drums-bits to report this back to user-space. This is a usual extension like any other device. Nothing special to take care of. We report this to user-space as "Nintendo Wii Remote Drums". There are other drums (like "RockBand" drums) which we currently do not support and maybe will at some point. However, it is quite likely that we can report these via the same interface. This allows user-space to work with them without knowing the exact branding. I couldn't find anyone who owns a "RockBand" device, though. Initial-work-by: Nicolas Adenis-Lamarre <nicolas.adenis.lamarre@gmail.com> Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> 
Guitar-Hero comes with a drums extension. Use the newly introduced input
drums-bits to report this back to user-space. This is a usual extension
like any other device. Nothing special to take care of.

We report this to user-space as "Nintendo Wii Remote Drums". There are
other drums (like "RockBand" drums) which we currently do not support and
maybe will at some point. However, it is quite likely that we can report
these via the same interface. This allows user-space to work with them
without knowing the exact branding.
I couldn't find anyone who owns a "RockBand" device, though.

Initial-work-by: Nicolas Adenis-Lamarre <nicolas.adenis.lamarre@gmail.com>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
HID: wiimote: support Nintendo Wii U Pro Controller 2013-06-27T09:57:49+00:00 David Herrmann dh.herrmann@gmail.com 2013-06-15T13:32:45+00:00 b8e0fe31a7c8623741f91bc27f925220341fdf81 The Wii U Pro Controller is a new Nintendo remote device that looks very similar to the XBox controller. It has nearly the same features and uses the same protocol as the Wii Remote. We add a new wiimote extension device so the Pro Controller is properly detected and supported. The device reports MP support, which is odd and I couldn't get it working, yet. Hence, we disable MP registers for now. Further investigation is needed to see what extra capabilities are provided. There are some other unknown bits in the extension reports that I couldn't figure out what they do. You can use hidraw to access these if you're interested. We might want to hook up the "charging" and "USB" bits to the battery device so user-space can query whether it is currently charged via USB. Signed-off-by: Jiri Kosina <jkosina@suse.cz> 
The Wii U Pro Controller is a new Nintendo remote device that looks very
similar to the XBox controller. It has nearly the same features and uses
the same protocol as the Wii Remote.

We add a new wiimote extension device so the Pro Controller is properly
detected and supported.

The device reports MP support, which is odd and I couldn't get it working,
yet. Hence, we disable MP registers for now. Further investigation is
needed to see what extra capabilities are provided.

There are some other unknown bits in the extension reports that I couldn't
figure out what they do. You can use hidraw to access these if you're
interested.

We might want to hook up the "charging" and "USB" bits to the battery
device so user-space can query whether it is currently charged via USB.

Signed-off-by: Jiri Kosina <jkosina@suse.cz>
HID: wiimote: add MP quirks 2013-06-03T09:07:06+00:00 David Herrmann dh.herrmann@gmail.com 2013-05-05T21:13:07+00:00 9f329741a6d7253f044677af00a999b47e85721e Devices which have built-in motion plus ports don't need MP detection logic. The new WIIMOD_BUILTIN_MP modules sets the WIIPROTO_FLAG_BUILTIN_MP flag which disables polling for MP. Some other devices erroneously report that they support motion-plus. For these devices and all devices without extension ports, we load WIIMOD_NO_MP which sets WIIPROTO_FLAG_NO_MP. This effectively disables all MP detection logic. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> 
Devices which have built-in motion plus ports don't need MP detection
logic. The new WIIMOD_BUILTIN_MP modules sets the WIIPROTO_FLAG_BUILTIN_MP
flag which disables polling for MP.

Some other devices erroneously report that they support motion-plus. For
these devices and all devices without extension ports, we load
WIIMOD_NO_MP which sets WIIPROTO_FLAG_NO_MP. This effectively disables all
MP detection logic.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
HID: wiimote: remove old static extension support 2013-06-03T09:07:05+00:00 David Herrmann dh.herrmann@gmail.com 2013-05-05T21:13:06+00:00 45ec9fff8629dda47d0c7645174220bcf5d9b6ba We now have dynamic hotplug support so the old static extensions are no longer needed nor used. Remove it along CONFIG_HID_WIIMOTE_EXT. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> 
We now have dynamic hotplug support so the old static extensions are no
longer needed nor used. Remove it along CONFIG_HID_WIIMOTE_EXT.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>