summaryrefslogtreecommitdiffstats
path: root/drivers/hid/hid-wiimote-modules.c
AgeCommit message (Collapse)Author
2013-10-30HID: wiimote: add pro-controller analog stick calibrationDavid Herrmann
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>
2013-10-30HID: wiimote: fix inverted pro-controller axesDavid Herrmann
The analog-stick vertical axes are inverted. Fix that! Otherwise, games and other gamepad applications need to carry their own fixups (which they thankfully haven't done, yet). Cc: <stable@vger.kernel.org> # 3.11+ 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>
2013-10-07HID: wiimote: fix FF deadlockDavid Herrmann
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>
2013-09-07Revert "Input: introduce BTN/ABS bits for drums and guitars"Linus Torvalds
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>
2013-09-04HID: wiimote: add support for Guitar-Hero guitarsNicolas Adenis-Lamarre
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>
2013-09-04HID: wiimote: add support for Guitar-Hero drumsDavid Herrmann
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>
2013-06-27HID: wiimote: support Nintendo Wii U Pro ControllerDavid Herrmann
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>
2013-06-18HID: wiimote: fix coccinelle warningsJiri Kosina
drivers/hid/hid-wiimote-modules.c:569:2-3: Unneeded semicolon Generated by: coccinelle/misc/semicolon.cocci Reported-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-06-03HID: wiimote: fix classic controller parsingDavid Herrmann
I finally got a "Classic Controller" and "Classic Controller Pro" in my hands and noticed that all analog data was incorrectly parsed. Fix this up so we report the data that we pretend we do. I really doubt that this breaks any backwards compatibility, but if we get any reports, we only need to revert this single patch. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-06-03HID: wiimote: add MP quirksDavid Herrmann
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>
2013-06-03HID: wiimote: add "bboard_calib" attributeDavid Herrmann
Balance-Boards provide 3 16bit calibration values for each of the 4 sensors. We provide these now as 192bit value via a new "bboard_calib" sysfs attribute. We also re-read the calibration data from the device whenever user-space attempts to read this file. On normal Nintendo boards, this always produces the same results, however, on some 3rd party devices these values change until the device is fully initialized. As I have currently no idea how long to wait until it's ready (sometimes takes up to 10s?) we provide a simple workaround for users by reading this file. If we, at some point, figure out how it works, we can implement it in the kernel and provide offline data via "bboard_calib". This won't break user-space then. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-06-03HID: wiimote: add Motion Plus extension moduleDavid Herrmann
Add parsers for motion plus data so we can hotplug motion plus extensions and make use of them. This is mostly the same as the old static motion plus parser. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-06-03HID: wiimote: add Classic Controller extensionDavid Herrmann
Add a new extension module for the classic controller so we get hotplug support for this device. It is mostly the same as the old static classic controller parser. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-06-03HID: wiimote: add Nunchuk supportDavid Herrmann
This moves the nunchuk parser over to an extension module. This allows to make use of hotplugged Nunchuks instead of the old static parser. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-06-03HID: wiimote: add Balance Board supportDavid Herrmann
This adds Nintendo Wii Balance Board support to the new HOTPLUG capable wiimote core. It is mostly copied from the old extension. This also adds Balance Board device detection. Whenever we find a device that supports the balance-board extension, we assume that it is a real balance board and disable unsupported hardward like accelerometer, IR, rumble and more. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-06-03HID: wiimote: add extension hotplug supportDavid Herrmann
The Wii Remote has several extension ports. The first port (EXT) provides hotplug events whenever an extension is plugged. The second port (MP) does not provide hotplug events by default. Instead, we have to map MP into EXT to get events for it. This patch introduces hotplug support for extensions. It is fairly complicated to get this right because the Wii Remote sends a lot of noise-hotplug events while activating extension ports. We need to filter the events and only handle the events that are real hotplug events. Mapping MP into EXT is easy. But if we want both, MP _and_ EXT at the same time, we need to map MP into EXT and enable a passthrough-mode. This will then send real EXT events through the mapped MP interleaved with real MP events. But once MP is mapped, we no longer have access to the real EXT registers so we need to perform setup _before_ mapping MP. Furthermore, we no longer can read EXT IDs so we cannot verify if EXT is still the same extension that we expect it to be. We deal with this by unmapping MP whenever we got into a situation where EXT might have changed. We then re-read EXT and MP and remap everything. The real Wii Console takes a fairly easy approach: It simply reconnects to the device on hotplug events that it didn't expect. So if a program wants MP events, but MP is disconnected, it fails and reconnects so it can wait for MP hotplug events again. This simplifies hotplugging a lot because we just react on PLUG events and ignore UNPLUG events. The more sophisticated Wii applications avoid reconnection (well, they still reconnect during many weird events, but at least not during UNPLUG) but they start polling the device. This allows them to disable the device, poll for the extension ports to settle and then initialize them again. Unfortunately, this approach fails whenever an extension is replugged while it is initialized. We would loose UNPLUG events and polling the device later will give unreliable results because the extension port might be in some weird state, even though it's actually unplugged. Our approach is a real HOTPLUG approch. We keep track of the EXT and mapped MP hotplug events whenever they occur. We then re-evaluate the device state and initialize any possible new extension or deinitialize any gone extension. Only during initialization, we set an extension port ACTIVE. However, during an unplug event we mark them as INACTIVE. This guarantess that a fast UNPLUG -> PLUG event sequence doesn't keep them marked as PLUGGED+ACTIVE but only PLUGGED. To deal with annoying noise-hotplug events during extension mapping, we simply rescan the device before performing any mapping. This allows us to ignore all the noise events as long as the device is in the correct state. Long story short: EXT and MP registers are sparsely known and we need to jump through hoops to get reliable HOTPLUG working. But while Nintendo needs *FOUR* Bluetooth reconnections for the shortest imaginable boot->menu->game->menu->shutdown sequence, we now need *ZERO*. As always, 3rd party devices tend to break whenever we behave differently than the original Wii. So there are also devices which _expect_ a disconnect after UNPLUG. Obviously, these devices won't benefit from this patch. But all official devices were tested extensively and work great during any hotplug sequence. Yay! Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-06-03HID: wiimote: convert IR to moduleDavid Herrmann
IR is the last piece that still is handled natively. This patch converts it into a sub-device module like all other sub-devices. It mainly moves code and doesn't change semantics. We also implicitly sync IR data on ir_to_input3 now so the explicit input_sync() calls are no longer needed. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-06-03HID: wiimote: convert ACCEL to moduleDavid Herrmann
Accelerometer data is very similar to KEYS handling. Therefore, convert all ACCEL related handling into a sub-device module similar to KEYS. This doesn't change any semantics but only moves code over to wiimote-modules. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-06-03HID: wiimote: convert LEDS to modulesDavid Herrmann
Each of the 4 LEDs may be supported individually by devices. Therefore, we need one module for each device. To avoid code-duplication, we simply pass the LED ID as "arg" argument to the module loading code. This just moves the code over to wiimote-module. The semantics stay the same as before. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-06-03HID: wiimote: convert BATTERY to moduleDavid Herrmann
This introduces a new sub-device module for the BATTERY handlers. It moves the whole power_supply battery handling over to wiimote-modules. This doesn't change any semantics or ABI but only converts the battery handling into a sub-device module. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-06-03HID: wiimote: convert KEYS and RUMBLE to modulesDavid Herrmann
This introduces the first sub-device modules by converting the KEYS and RUMBLE sub-devices into wiimote modules. Both must be converted at once because they depend on the built-in shared input device. This mostly moves code from wiimote-core to wiimote-modules and doesn't change any semantics or ABI. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-06-03HID: wiimote: add sub-device module infrastructureDavid Herrmann
To avoid loading all sub-device drivers for every Wii Remote, even though the required hardware might not be available, we introduce a module layer. The module layer specifies which sub-devices are available on each device-type. After device detection, we only load the modules for the detected device. If module loading fails, we unload everything and mark the device as WIIMOTE_DEV_UNKNOWN. As long as a device is marked as "unknown", no sub-devices will be used and the device is considered unsupported. All the different sub-devices, including KEYS, RUMBLE, BATTERY, LEDS, ACCELEROMETER, IR and more will be ported in follow-up patches to the new module layer. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>