summaryrefslogtreecommitdiffstats
path: root/drivers/hid/hid-wiimote.h
Commit message (Collapse)AuthorAgeFilesLines
* HID: wiimote: add support for Guitar-Hero devicesNicolas Adenis-Lamarre2018-06-251-0/+3
| | | | | | | | | | | | | | | | | | | | This adds the drums and guitar extensions for Wiimote devices. Devices are reported as "Nintendo Wii Remote Guitar/Drums". 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. This is a rebase of the original commits 8e22ecb603c8 and 73f8645db191. They were reverted several years ago, since they were dependent on the ABS_* rework of the input core. Sadly, this never worked out so these commits were never pushed into a release. This rebase now uses the ABS_HAT* event codes to report all pressure information. Signed-off-by: Nicolas.Adenis-Lamarre <nicolas.adenis.lamarre@gmail.com> (Original commits by Nicolas, adapted to v4.18 by David) Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: use to_hid_device()Geliang Tang2015-12-281-2/+1
| | | | | | | Use to_hid_device() instead of container_of(). Signed-off-by: Geliang Tang <geliangtang@163.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* power_supply: Change ownership from driver to coreKrzysztof Kozlowski2015-03-131-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change the ownership of power_supply structure from each driver implementing the class to the power supply core. The patch changes power_supply_register() function thus all drivers implementing power supply class are adjusted. Each driver provides the implementation of power supply. However it should not be the owner of power supply class instance because it is exposed by core to other subsystems with power_supply_get_by_name(). These other subsystems have no knowledge when the driver will unregister the power supply. This leads to several issues when driver is unbound - mostly because user of power supply accesses freed memory. Instead let the core own the instance of struct 'power_supply'. Other users of this power supply will still access valid memory because it will be freed when device reference count reaches 0. Currently this means "it will leak" but power_supply_put() call in next patches will solve it. This solves invalid memory references in following race condition scenario: Thread 1: charger manager Thread 2: power supply driver, used by charger manager THREAD 1 (charger manager) THREAD 2 (power supply driver) ========================== ============================== psy = power_supply_get_by_name() Driver unbind, .remove power_supply_unregister() Device fully removed psy->get_property() The 'get_property' call is executed in invalid context because the driver was unbound and struct 'power_supply' memory was freed. This could be observed easily with charger manager driver (here compiled with max17040 fuel gauge): $ cat /sys/devices/virtual/power_supply/cm-battery/capacity & $ echo "1-0036" > /sys/bus/i2c/drivers/max17040/unbind [ 55.725123] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 55.732584] pgd = d98d4000 [ 55.734060] [00000000] *pgd=5afa2831, *pte=00000000, *ppte=00000000 [ 55.740318] Internal error: Oops: 80000007 [#1] PREEMPT SMP ARM [ 55.746210] Modules linked in: [ 55.749259] CPU: 1 PID: 2936 Comm: cat Tainted: G W 3.19.0-rc1-next-20141226-00048-gf79f475f3c44-dirty #1496 [ 55.760190] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 55.766270] task: d9b76f00 ti: daf54000 task.ti: daf54000 [ 55.771647] PC is at 0x0 [ 55.774182] LR is at charger_get_property+0x2f4/0x36c [ 55.779201] pc : [<00000000>] lr : [<c034b0b4>] psr: 60000013 [ 55.779201] sp : daf55e90 ip : 00000003 fp : 00000000 [ 55.790657] r10: 00000000 r9 : c06e2878 r8 : d9b26c68 [ 55.795865] r7 : dad81610 r6 : daec7410 r5 : daf55ebc r4 : 00000000 [ 55.802367] r3 : 00000000 r2 : daf55ebc r1 : 0000002a r0 : d9b26c68 [ 55.808879] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 55.815994] Control: 10c5387d Table: 598d406a DAC: 00000015 [ 55.821723] Process cat (pid: 2936, stack limit = 0xdaf54210) [ 55.827451] Stack: (0xdaf55e90 to 0xdaf56000) [ 55.831795] 5e80: 60000013 c01459c4 0000002a c06f8ef8 [ 55.839956] 5ea0: db651000 c06f8ef8 daebac00 c04cb668 daebac08 c0346864 00000000 c01459c4 [ 55.848115] 5ec0: d99eaa80 c06f8ef8 00000fff 00001000 db651000 c027f25c c027f240 d99eaa80 [ 55.856274] 5ee0: d9a06c00 c0146218 daf55f18 00001000 d99eaa80 db4c18c0 00000001 00000001 [ 55.864468] 5f00: daf55f80 c0144c78 c0144c54 c0107f90 00015000 d99eaab0 00000000 00000000 [ 55.872603] 5f20: 000051c7 00000000 db4c18c0 c04a9370 00015000 00001000 daf55f80 00001000 [ 55.880763] 5f40: daf54000 00015000 00000000 c00e53dc db4c18c0 c00e548c 0000000d 00008124 [ 55.888937] 5f60: 00000001 00000000 00000000 db4c18c0 db4c18c0 00001000 00015000 c00e5550 [ 55.897099] 5f80: 00000000 00000000 00001000 00001000 00015000 00000003 00000003 c000f364 [ 55.905239] 5fa0: 00000000 c000f1a0 00001000 00015000 00000003 00015000 00001000 0001333c [ 55.913399] 5fc0: 00001000 00015000 00000003 00000003 00000002 00000000 00000000 00000000 [ 55.921560] 5fe0: 7fffe000 be999850 0000a225 b6f3c19c 60000010 00000003 00000000 00000000 [ 55.929744] [<c034b0b4>] (charger_get_property) from [<c0346864>] (power_supply_show_property+0x48/0x20c) [ 55.939286] [<c0346864>] (power_supply_show_property) from [<c027f25c>] (dev_attr_show+0x1c/0x48) [ 55.948130] [<c027f25c>] (dev_attr_show) from [<c0146218>] (sysfs_kf_seq_show+0x84/0x104) [ 55.956298] [<c0146218>] (sysfs_kf_seq_show) from [<c0144c78>] (kernfs_seq_show+0x24/0x28) [ 55.964536] [<c0144c78>] (kernfs_seq_show) from [<c0107f90>] (seq_read+0x1b0/0x484) [ 55.972172] [<c0107f90>] (seq_read) from [<c00e53dc>] (__vfs_read+0x18/0x4c) [ 55.979188] [<c00e53dc>] (__vfs_read) from [<c00e548c>] (vfs_read+0x7c/0x100) [ 55.986304] [<c00e548c>] (vfs_read) from [<c00e5550>] (SyS_read+0x40/0x8c) [ 55.993164] [<c00e5550>] (SyS_read) from [<c000f1a0>] (ret_fast_syscall+0x0/0x48) [ 56.000626] Code: bad PC value [ 56.011652] ---[ end trace 7b64343fbdae8ef1 ]--- Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> [for the nvec part] Reviewed-by: Marc Dietrich <marvin24@gmx.de> [for compal-laptop.c] Acked-by: Darren Hart <dvhart@linux.intel.com> [for the mfd part] Acked-by: Lee Jones <lee.jones@linaro.org> [for the hid part] Acked-by: Jiri Kosina <jkosina@suse.cz> [for the acpi part] Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
* Merge branch 'for-linus' of ↵Linus Torvalds2013-11-151-0/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid 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 ...
| * HID: wiimote: add pro-controller analog stick calibrationDavid Herrmann2013-10-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | tree-wide: use reinit_completion instead of INIT_COMPLETIONWolfram Sang2013-11-151-1/+1
|/ | | | | | | | | | | | 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: fix FF deadlockDavid Herrmann2013-10-071-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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"Linus Torvalds2013-09-071-3/+0
| | | | | | | | | | | | | | | | | | | | 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 guitarsNicolas Adenis-Lamarre2013-09-041-0/+1
| | | | | | | | | | | | | | | 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 drumsDavid Herrmann2013-09-041-0/+2
| | | | | | | | | | | | | | | | | 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 ControllerDavid Herrmann2013-06-271-0/+2
| | | | | | | | | | | | | | | | | | | | | | 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 quirksDavid Herrmann2013-06-031-0/+4
| | | | | | | | | | | | | | 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 supportDavid Herrmann2013-06-031-19/+0
| | | | | | | | 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>
* HID: wiimote: lock DRM mode during debugfs overwriteDavid Herrmann2013-06-031-0/+1
| | | | | | | | | | | | 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>
* HID: wiimote: add Motion Plus extension moduleDavid Herrmann2013-06-031-0/+1
| | | | | | | | | 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>
* HID: wiimote: add Classic Controller extensionDavid Herrmann2013-06-031-0/+1
| | | | | | | | | 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>
* HID: wiimote: add Nunchuk supportDavid Herrmann2013-06-031-0/+1
| | | | | | | | 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>
* HID: wiimote: add Balance Board supportDavid Herrmann2013-06-031-0/+9
| | | | | | | | | | | | | 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>
* HID: wiimote: add extension hotplug supportDavid Herrmann2013-06-031-0/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* HID: wiimote: convert IR to moduleDavid Herrmann2013-06-031-0/+3
| | | | | | | | | | | | 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>
* HID: wiimote: convert ACCEL to moduleDavid Herrmann2013-06-031-0/+2
| | | | | | | | | | | 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>
* HID: wiimote: convert LEDS to modulesDavid Herrmann2013-06-031-0/+5
| | | | | | | | | | | | 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>
* HID: wiimote: convert BATTERY to moduleDavid Herrmann2013-06-031-0/+2
| | | | | | | | | | | 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>
* HID: wiimote: convert KEYS and RUMBLE to modulesDavid Herrmann2013-06-031-0/+18
| | | | | | | | | | | | 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>
* HID: wiimote: add sub-device module infrastructureDavid Herrmann2013-06-031-0/+27
| | | | | | | | | | | | | | | | | | | 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>
* HID: wiimote: wake up if output queue failedDavid Herrmann2013-06-031-0/+19
| | | | | | | | | | | | | | | 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>
* HID: wiimote: add device detectionDavid Herrmann2013-06-031-1/+36
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* HID: wiimote: move queue handling into separate structDavid Herrmann2013-06-031-6/+9
| | | | | | | | | | | 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>
* HID: wiimote: extend driver descriptionDavid Herrmann2013-06-031-2/+2
| | | | | | | | | | | | | 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>
* HID: wiimote: Allow direct DRM debug accessDavid Herrmann2011-11-221-0/+2
| | | | | | | | Keep track of current drm and add new debugfs file which reads or writes the current DRM. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: wiimote: Allow direct eeprom accessDavid Herrmann2011-11-221-0/+7
| | | | | | | | | | | | | The wiimote provides direct access to parts of its eeprom. This implements read support for small chunks of the eeprom. This isn't very fast but prevents the reader from blocking the wiimote stream for too long. Write support is not yet supported as the wiimote breaks if we overwrite its memory. Use hidraw to reverse-engineer the eeprom before implementing write support here. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: wiimote: Add debugfs support stubsDavid Herrmann2011-11-221-0/+13
| | | | | | | | | Add initializer and deinitializer for debugfs support. This will later allow raw eeprom access and direct DRM modifications to debug wiimote behaviour and further protocol reverse-engineerings. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: wiimote: Add extension handler stubsDavid Herrmann2011-11-221-0/+2
| | | | | | | | | | | | | All supported extensions report data as 6 byte block. All DRMs with extension data provide at least 6 extension bytes. Hence a generic handler for all extension bytes is sufficient and can be called on all DRMs. The handler distinguishes the input and passes it to the right handler. Motion+ passes data interleaved so we can have Motion+ and a regular extension enabled simultaneously. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: wiimote: Add extension support stubDavid Herrmann2011-11-221-0/+17
| | | | | | | | | | | | | | | | | | | | | The wiimote supports several extensions. This adds a separate source file which handles all extensions and can be disabled at compile-time. The driver reacts on "plug"-events on the extension port and starts a worker which initializes or deinitializes the extensions. Currently, the initialization logic is not fully understood and we can only detect and enable all extensions when all extensions are deactivated. Therefore, we need to disable all extensions, then detect and activate them again to react on "plug"-events. However, deactivating extensions will generate a new "plug"-event and we will never leave that loop. Hence, we only support extensions if they are plugged before the wiimote is connected (or before the ext-input device is opened). In the future we may support full extension hotplug support, but reverse-engineering this may take a while. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: wiimote: Add read-mem helpersDavid Herrmann2011-11-221-0/+4
| | | | | | | | Add helper functions similar to the write-mem helpers but for reading wiimote memory and eeprom. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* HID: wiimote: Move common symbols into headerDavid Herrmann2011-11-221-0/+163
Wiimote extension and sound support need access to several symbols so move them into a new header. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-22 08:35:29 +0000