aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/hid/hid-wiimote-ext.c (follow)
AgeCommit message (Collapse)AuthorFilesLines
2013-02-18HID: wiimote: fix nunchuck button parserDavid Herrmann1-4/+4
The buttons of the Wii Remote Nunchuck extension are actually active low. Fix the parser to forward the inverted values. The comment in the function always said "0 == pressed" but the implementation was wrong from the beginning. Cc: stable@vger.kernel.org Reported-by: Victor Quicksilver <victor.quicksilver@gmail.com> Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2012-10-02Merge branch 'for-3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wqLinus Torvalds1-1/+1
Pull workqueue changes from Tejun Heo: "This is workqueue updates for v3.7-rc1. A lot of activities this round including considerable API and behavior cleanups. * delayed_work combines a timer and a work item. The handling of the timer part has always been a bit clunky leading to confusing cancelation API with weird corner-case behaviors. delayed_work is updated to use new IRQ safe timer and cancelation now works as expected. * Another deficiency of delayed_work was lack of the counterpart of mod_timer() which led to cancel+queue combinations or open-coded timer+work usages. mod_delayed_work[_on]() are added. These two delayed_work changes make delayed_work provide interface and behave like timer which is executed with process context. * A work item could be executed concurrently on multiple CPUs, which is rather unintuitive and made flush_work() behavior confusing and half-broken under certain circumstances. This problem doesn't exist for non-reentrant workqueues. While non-reentrancy check isn't free, the overhead is incurred only when a work item bounces across different CPUs and even in simulated pathological scenario the overhead isn't too high. All workqueues are made non-reentrant. This removes the distinction between flush_[delayed_]work() and flush_[delayed_]_work_sync(). The former is now as strong as the latter and the specified work item is guaranteed to have finished execution of any previous queueing on return. * In addition to the various bug fixes, Lai redid and simplified CPU hotplug handling significantly. * Joonsoo introduced system_highpri_wq and used it during CPU hotplug. There are two merge commits - one to pull in IRQ safe timer from tip/timers/core and the other to pull in CPU hotplug fixes from wq/for-3.6-fixes as Lai's hotplug restructuring depended on them." Fixed a number of trivial conflicts, but the more interesting conflicts were silent ones where the deprecated interfaces had been used by new code in the merge window, and thus didn't cause any real data conflicts. Tejun pointed out a few of them, I fixed a couple more. * 'for-3.7' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq: (46 commits) workqueue: remove spurious WARN_ON_ONCE(in_irq()) from try_to_grab_pending() workqueue: use cwq_set_max_active() helper for workqueue_set_max_active() workqueue: introduce cwq_set_max_active() helper for thaw_workqueues() workqueue: remove @delayed from cwq_dec_nr_in_flight() workqueue: fix possible stall on try_to_grab_pending() of a delayed work item workqueue: use hotcpu_notifier() for workqueue_cpu_down_callback() workqueue: use __cpuinit instead of __devinit for cpu callbacks workqueue: rename manager_mutex to assoc_mutex workqueue: WORKER_REBIND is no longer necessary for idle rebinding workqueue: WORKER_REBIND is no longer necessary for busy rebinding workqueue: reimplement idle worker rebinding workqueue: deprecate __cancel_delayed_work() workqueue: reimplement cancel_delayed_work() using try_to_grab_pending() workqueue: use mod_delayed_work() instead of __cancel + queue workqueue: use irqsafe timer for delayed_work workqueue: clean up delayed_work initializers and add missing one workqueue: make deferrable delayed_work initializer names consistent workqueue: cosmetic whitespace updates for macro definitions workqueue: deprecate system_nrt[_freezable]_wq workqueue: deprecate flush[_delayed]_work_sync() ...
2012-09-18HID: wiimote: fix weight conversion error for values > 17kgFlorian Echtler1-1/+2
Signed-off-by: Florian Echtler <floe@butterbrot.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2012-09-17HID: wiimote: Parse calibration data of balance boardsFlorian Echtler1-1/+38
The raw pressure-data that is reported by balance-boards is pretty useless unless calibration data is applied. Therefore, we read the full calibration data on extension initialization and apply it to every reported data. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Florian Echtler <floe@butterbrot.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2012-09-17HID: wiimote: Add Nintendo Balance-Board supportDavid Herrmann1-0/+59
The Nintendo Balance-Board is a controller which behaves exactly like the Wii Remote but reports all its data through a special extension device. Hence, we can simply add the Balance-Board as extension device and we get full support for it. Tested-by: Florian Echtler <floe@butterbrot.org> Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2012-08-20workqueue: deprecate system_nrt[_freezable]_wqTejun Heo1-1/+1
system_nrt[_freezable]_wq are now spurious. Mark them deprecated and convert all users to system[_freezable]_wq. If you're cc'd and wondering what's going on: Now all workqueues are non-reentrant, so there's no reason to use system_nrt[_freezable]_wq. Please use system[_freezable]_wq instead. This patch doesn't make any functional difference. Signed-off-by: Tejun Heo <tj@kernel.org> Acked-By: Lai Jiangshan <laijs@cn.fujitsu.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: David Airlie <airlied@linux.ie> Cc: Jiri Kosina <jkosina@suse.cz> Cc: "David S. Miller" <davem@davemloft.net> Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Cc: David Howells <dhowells@redhat.com>
2012-06-05HID: wiimote-ext: comment spelling fixGiuseppe Bilotta1-1/+1
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-22HID: wiimote: Parse classic controller dataDavid Herrmann1-0/+156
Nintendo Classic Controller extension reports lots of keys, two analog sticks and two analog buttons. We report all data through extension input device to userspace. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-22HID: wiimote: Parse nunchuck dataDavid Herrmann1-1/+104
The Nintendo Nunchuck extension reports accelerometer values, one analog stick and two buttons. See inline comments for data layout. We report all data to userspace through extension input device. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-22HID: wiimote: Parse motion+ dataDavid Herrmann1-0/+70
Motion+ reports rotation gyro data which we report to userspace as ABS_RX/Y/Z values. The device reports them either in fast or slow mode. We adjust the values to get a linear scale so userspace does not need to know about slow and fast mode. The motion+ also reports whether an extension is connected to it. We keep track of this value and reinitialize the extensions if an extension is plugged or unplugged. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-22HID: wiimote: Add extension handler stubsDavid Herrmann1-0/+29
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>
2011-11-22HID: wiimote: Register input devices for extensionsDavid Herrmann1-3/+106
Motion+ and regular extensions are physical adapters for the wiimote so create one input device for each of them. This also allows to enable only opened extensions and turn unused extenions off to save battery power. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-22HID: wiimote: Add extension sysfs attributeDavid Herrmann1-0/+46
Add new sysfs attribute "extension" which returns the currently connected and initialized extensions. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-22HID: wiimote: Add extension initializersDavid Herrmann1-2/+79
The wiimote extension registers are not fully understood, so we always disable all extensions on extension-port events. Then we reinitialize and reidentify them and activate all requested extensions. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-22HID: wiimote: Add extension initializer stubsDavid Herrmann1-0/+38
Add stub functions to read and identify extensions and then initialize all connected extensions. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-22HID: wiimote: Add extension support stubDavid Herrmann1-0/+130
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>