summaryrefslogtreecommitdiff
path: root/drivers/hid
AgeCommit message (Collapse)Author
2013-08-02Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid Pull HID fixes from Jiri Kosina: - fix hid-sony PS3 sixaxxis breakage from Benjamin Tissories - fix hidraw race condition from Yonghua Zheng - fix/bandaid for rare device enumeration problems of Logitech Unifying receivers from Nestor Lopez Casado * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid: HID: hidraw: fix improper mutex release HID: sony: fix HID mapping for PS3 sixaxis controller HID: hid-logitech-dj: querying_devices was never set HID: Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue""
2013-07-31Merge branches 'for-3.11/upstream-fixes' and ↵Jiri Kosina
'for-3.11/logitech-enumeration-fix' into for-linus
2013-07-31HID: hidraw: fix improper mutex releaseYonghua Zheng
Mutex can not be released unless all hid_device members are properly initialized. Otherwise it would result in a race condition that can cause NULL pointer kernel panic issue in hidraw_open where it uses uninitialized 'list' member in list_add_tail(). Signed-off-by: Yonghua Zheng <younghua.zheng@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-07-24HID: sony: fix HID mapping for PS3 sixaxis controllerBenjamin Tissoires
Commit f04d51404f51 (HID: driver for PS2/3 Buzz controllers) introduced an input_mapping() callback, but set the return value to -1 to all devices except the Buzz controllers. The result of this is that the Sixaxis input device is not populated, making it useless. Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-07-22HID: hid-logitech-dj: querying_devices was never setNestor Lopez Casado
Set querying_devices flag to true when we start the enumeration process. This was missing from the original patch. It never produced undesirable effects as it is highly improbable to have a second enumeration triggered while a first one was still in progress. Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-07-22HID: Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue""Nestor Lopez Casado
This reverts commit 8af6c08830b1ae114d1a8b548b1f8b056e068887. This patch re-adds the workaround introduced by 596264082f10dd4 which was reverted by 8af6c08830b1ae114. The original patch 596264 was needed to overcome a situation where the hid-core would drop incoming reports while probe() was being executed. This issue was solved by c849a6143bec520af which added hid_device_io_start() and hid_device_io_stop() that enable a specific hid driver to opt-in for input reports while its probe() is being executed. Commit a9dd22b730857347 modified hid-logitech-dj so as to use the functionality added to hid-core. Having done that, workaround 596264 was no longer necessary and was reverted by 8af6c08. We now encounter a different problem that ends up 'again' thwarting the Unifying receiver enumeration. The problem is time and usb controller dependent. Ocasionally the reports sent to the usb receiver to start the paired devices enumeration fail with -EPIPE and the receiver never gets to enumerate the paired devices. With dcd9006b1b053c7b1c the problem was "hidden" as the call to the usb driver became asynchronous and none was catching the error from the failing URB. As the root cause for this failing SET_REPORT is not understood yet, -possibly a race on the usb controller drivers or a problem with the Unifying receiver- reintroducing this workaround solves the problem. Overall what this workaround does is: If an input report from an unknown device is received, then a (re)enumeration is performed. related bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1194649 Signed-off-by: Nestor Lopez Casado <nlopezcasad@logitech.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-07-04Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input Pull input updates from Dmitry Torokhov: "First round of updates for the input subsystem. You will get a new touchsreen driver for Cypress 4th generation devices, a driver for a special controller implementing PS/2 protocol in OLPC devices, and a driver for power key for SiRFprimaII PWRC. HID and bcm5497 now support for the 2013 MacBook Air. EVIOCGKEY and the rest of evdev ioctls now flush events of matching type from the client's event queue so that clients can be sure any events received after issuing EVIOCG* ioctl are new events. And a host of cleanups and improvements in other drivers" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: (87 commits) Input: cyttsp4 - kfree xfer_buf on error path in probe() Input: tps6507x-ts - select INPUT_POLLDEV Input: bcm5974 - add support for the 2013 MacBook Air HID: apple: Add support for the 2013 Macbook Air Input: cyttsp4 - leak on error path in probe() Input: cyttsp4 - silence NULL dereference warning Input: cyttsp4 - silence shift wrap warning Input: tps6507x-ts - convert to polled input device infrastructure ARM: davinci: da850-evm: remove vref from touchscreen platform data Input: cyttsp4 - SPI driver for Cypress TMA4XX touchscreen devices Input: cyttsp4 - I2C driver for Cypress TMA4XX touchscreen devices Input: cyttsp4 - add core driver for Cypress TMA4XX touchscreen devices Input: cyttsp - I2C driver split into two modules Input: add OLPC AP-SP driver Input: nspire-keypad - remove redundant dev_err call in nspire_keypad_probe() Input: tps6507x-ts - remove vref from platform data Input: tps6507x-ts - use bool for booleans Input: tps6507x-ts - remove bogus unreachable code Input: samsung-keypad - let device core setup the default pin configuration Input: wacom_i2c - implement hovering capability ...
2013-07-04Merge branches 'for-3.11/wacom-fixed' and 'for-3.11/wiimote' into for-linusJiri Kosina
2013-07-04HID: wacom: Intuos4 battery charging changesPrzemo Firszt
Intuos4 WL is separately reporting power supply and battery charging status - now hid-wacom is using that information. Previously hid-wacom was wrongly treating "battery charging" bit as "power supply connected". Now it should report battery charging, battery discharging, battery full and power supply status. Intuos4 WL sends reports when is in use (obvious) and when unplugging power supply. If means that if the device is being charged, but it's not being used it will never report "battery full". The same problem happens after the device has been connected, but it's not in use - the battery/ac status will be incorrect. Currently there is no mechanism to ask the device to send a report containing battery/ac status. Signed-off-by: Przemo Firszt <przemo@firszt.eu> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-07-04Merge branches 'for-3.11/multitouch', 'for-3.11/sony' and ↵Jiri Kosina
'for-3.11/upstream' into for-linus Conflicts: drivers/hid/hid-core.c
2013-07-04Merge branches 'for-3.11/battery', 'for-3.11/elo', 'for-3.11/holtek' and ↵Jiri Kosina
'for-3.11/i2c-hid-fixed' into for-linus
2013-07-04HID: i2c-hid: support sending HID output reports using the output registerAndrew Duggan
The current i2c hid driver does not support sending HID output reports using the output register for devices which support receiving reports through this method. This patch determines which method to use to send output reports based on the value of wMaxOutputLength in the device's HID descriptor. Signed-off-by: Andrew Duggan <aduggan@synaptics.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-07-03HID: kye: Add report fixup for Genius Gila Gaming mouseBenjamin Tissoires
Genius Gila Gaming Mouse presents an obviously wrong report descriptor. the Consumer control (report ID 3) is the following: 0x05, 0x0c, // Usage Page (Consumer Devices) 105 0x09, 0x01, // Usage (Consumer Control) 107 0xa1, 0x01, // Collection (Application) 109 0x85, 0x03, // Report ID (3) 111 0x19, 0x00, // Usage Minimum (0) 113 0x2a, 0xff, 0x7f, // Usage Maximum (32767) 115 0x15, 0x00, // Logical Minimum (0) 118 0x26, 0xff, 0x7f, // Logical Maximum (32767) 120 0x75, 0x10, // Report Size (16) 123 0x95, 0x03, // Report Count (3) 125 0x81, 0x00, // Input (Data,Arr,Abs) 127 0x75, 0x08, // Report Size (8) 129 0x95, 0x01, // Report Count (1) 131 0x81, 0x01, // Input (Cnst,Arr,Abs) 133 0xc0, // End Collection 135 So the first input whithin this report has a count of 3 but a usage range of 32768. So this value is obviously wrong as it should not be greater than the report count. Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=959721 Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-07-03HID: apple: Add support for the 2013 Macbook AirDmitry Torokhov
This patch adds keyboard support for MacbookAir6,2 as WELLSPRING8 (0x0291, 0x0292, 0x0293). The touchpad is handled in a separate bcm5974 patch, as usual. Cc: stable@vger.kernel.org Reported-and-tested-by: Brad Ford <plymouthffl@gmail.com> Signed-off-by: Henrik Rydberg <rydberg@euromail.se> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
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-19HID: explain out-of-range check betterJiri Kosina
Extend the comment explaining the condition for discarding out-of-range values to clarify the cases in which devices don't provide any logical min/max. Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-06-19HID: fix false positive out of range valuesBenjamin Tissoires
Commit 6da7066906e977d42104a859c490f5f9a300488c introduced in 3.3 "HID: ignore absolute values which don't fit between logical min and max" prevents some Posiflex touch screen to work because they do not provide logical min and max for their buttons. Thus, logical min and max are at 0, discarding the buttons events, and preventing the device to report appropriate X Y. Adding a check on "min < max" solves the problem. Reported-by: Jan Kandziora <jjj@gmx.de> Tested-by: Jan Kandziora <jjj@gmx.de> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> 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-18HID: roccat: check cdev_add return valueMichael Rissi
Return value of cdev_add in hid_roccat.c init was not checked. Signed-off-by: Michael Rissi <michael.rissi@dectris.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-06-13HID: fold ps3remote driver into generic Sony driverJiri Kosina
Let's follow the structure we are trying to keep for most of the specific HID drivers, and let the separation follow the producing vendor. Merge functionality provided by ps3remote driver into hid-sony. Tested-by: David Dillow <dave@thedillows.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-06-12HID: multitouch: prevent memleak with the allocated nameBenjamin Tissoires
mt_free_input_name() was never called during .remove(): hid_hw_stop() removes the hid_input items in hdev->inputs, and so the list is therefore empty after the call. In the end, we never free the special names that has been allocated during .probe(). Restore the original name before freeing it to avoid acessing already freed pointer. This fixes a regression introduced by 49a5a827a ("HID: multitouch: append " Pen" to the name of the stylus input") Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-06-03HID: hyperv: convert alloc+memcpy to memdupThomas Meyer
Signed-off-by: Thomas Meyer <thomas@m3y3r.de> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-06-03HID: core: fix reporting of raw eventsJiri Kosina
hdrw->raw event can return three different return value types: - ret < 0 indicates that the hdrv driver found an error while parsing - ret == 0 indicates no error has been encountered, and the driver has processed the report - ret > 0 indicates that there was no parsing error, and the driver hasn't processed the event. Calling hid_report_raw_event() has to be called appropriately so that it reflects what has been done by ->raw_event() callback, otherwise we might updates of the in-kernel structure are lost upon arrival of the report, which is wrong. Reported-and-tested-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Reported-and-tested-by: Daniel Leung <daniel.leung@linux.intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-06-03HID: wiimote: discard invalid EXT data reportsDavid Herrmann
If an extension device isn't initialized properly, or during hardware initialization, a device might send extension data which is all 0xff. This is ambigious because this is also a valid normal data report. But it is impossible, under normal conditions, to trigger valid reports with all 0xff. Hence, we can safely ignore them. Signed-off-by: David Herrmann <dh.herrmann@gmail.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: init EXT/MP during device detectionDavid Herrmann
We normally get EXT hotplug events or poll for MP hotplugging so we don't need to force extension port initialization during device setup. But for gen20 devices, we disable MP polling because MP is always present. However, this prevents MP initialization during device setup and users need to plug another extension to trigger EXT/MP detection. Therefore, we now trigger EXT/MP detection during device setup automatically. This also avoids slightly delayed extension detection and provides sysfs child-devices prior to the "changed"-uevent during device setup. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-06-03HID: wiimote: fix DRM debug-attr to correctly parse inputDavid Herrmann
We need to correctly zero-terminate the input to parse it. Otherwise, we always end up interpreting it as numbers. Furthermore, we actually want hexadecimal numbers instead of decimal. As it is a debugfs interface, we can change the API at any time. 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: remove old static extension supportDavid Herrmann
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>
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 sysfs extension/device-type attrsDavid Herrmann
Two new attributes, "extension" and "devtype" now allow user-space to read the extension type and device type. As device detection is asynchronous, we send a CHANGED event after it is done. This also allows user-space to wait for a device to settle before opening its input event devices. The "extension" device is compatible with the old "extension" sysfs field (which was registered by the static extension support code). Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-06-03HID: wiimote: lock DRM mode during debugfs overwriteDavid Herrmann
If we write a DRM mode via debugfs, we shouldn't allow normal operations to overwrite this DRM mode. This is important if we want to debug 3rd-party devices and we want to see what data is sent on each mode. If we write NULL/0 as DRM, the lock is removed again so the best matching DRM is chosen by wiimote core. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-06-03HID: wiimote: fix ctx pointer in debugfs DRM-writeDavid Herrmann
single_open() stores the seq_file pointer in file->private_data. It stores our ctx pointer in seq_file->private. 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>
2013-06-03HID: wiimote: wake up if output queue failedDavid Herrmann
Our output queue is asynchronous but synchronous reports may wait for a response to their request. Therefore, wake them up unconditionally if an output report couldn't be sent. But keep the report ID intact so we don't incorrectly assume our request succeeded. Note that the underlying connection is required to be reliable and does retransmission itself. So it is safe to assume that if the transmission fails, the device is in inconsistent state. Hence, we abort every request if any output report fails. No need to verify which report failed. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-06-03HID: wiimote: use cached battery values on I/O failureDavid Herrmann
Battery reports are sent along every status report of the Wii Remote. So chances are pretty high that we have an up-to-date battery cache at any time. Therefore, initialize the battery-cache to 100% and then return battery values from the cache if the query fails. This works around a power_supply limitation in that it requires us to be able to query the device during power_supply registration and removal. Otherwise, "add" or "remove" udev events are not sent. If we answer these requests from our cache instead, we avoid dropping these events and no longer cause warnings printed. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-06-03HID: wiimote: add device detectionDavid Herrmann
Nintendo produced many different devices that are internally based on the Wii Remote protocol but provide different peripherals. To support these devices, we need to schedule a device detection during initialization. Device detection includes requesting a status report, reading extension information and then evaluating which device we may be dealing with. We currently detect gen1 and gen2 Wii Remote devices. All other devices are marked as generic devices. More detections will be added later. In followup patches we will be using these device IDs to control which peripherals to initialize. For instance if a device is known to have no IR camera, there is no need to provide the IR input device nor trying to access IR registers. In fact, there are 3rd party devices that break if we try things like this (hurray!). The init_worker will be scheduled whenever we get hotplug events. This isn't implemented, yet and will be added later. However, we need to make sure that this worker can be called multiple times. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-06-03HID: wiimote: keep HID device openDavid Herrmann
We need constant I/O to keep the state up-to-date and not miss any packets. Hence, call hid_hw_open() during setup and hid_hw_close() during destruction. These are no-ops for Bluetooth HIDP, but lets be safe. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-06-03HID: wiimote: move queue handling into separate structDavid Herrmann
The output queue is independent of the other wiimote modules and can run on its own. Therefore, move its members into a separate struct so we don't run into name collisions with other modules. This is only a syntactic change that renames all queue members to queue.*. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-06-03HID: wiimote: extend driver descriptionDavid Herrmann
The hid-wiimote driver supports more than the Wii Remote. Nintendo produced many devices based on the Wii Remote, which have extension devices built-in. It is not clear to many users, that these devices have anything in common with the Wii Remote, so fix the driver description. This also updates the copyright information for the coming hotplugging rework. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>