Commit Graph

1593 Commits

Author SHA1 Message Date
Jiri Kosina
8e5654ce69 Revert "HID: hid-logitech-dj: querying_devices was never set"
This reverts commit 407a2c2a4d.

Explanation provided by Benjamin Tissoires:

Commit "HID: hid-logitech-dj, querying_devices was never set" activate
a flag which guarantees that we do not ask the receiver for too many
enumeration. When the flag is set, each following enumeration call is
discarded (the usb request is not forwarded to the receiver). The flag
is then released when the driver receive a pairing information event,
which normally follows the enumeration request.
However, the USB3 bug makes the driver think the enumeration request
has been forwarded to the receiver. However, it is actually not the
case because the USB stack returns -EPIPE. So, when a new unknown
device appears, the workaround consisting in asking for a new
enumeration is not working anymore: this new enumeration is discarded
because of the flag, which is never reset.

A solution could be to trigger a timeout before releasing it, but for
now, let's just revert the patch.

Reported-by: Benjamin Tissoires <benjamin.tissoires@gmail.com>
Tested-by: Sune Mølgaard <sune@molgaard.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-08-09 11:34:19 +02:00
Linus Torvalds
f9ed432c92 Merge branch 'for-linus' of 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-08-02 14:22:15 -07:00
Jiri Kosina
e6dfb04360 Merge branches 'for-3.11/upstream-fixes' and 'for-3.11/logitech-enumeration-fix' into for-linus 2013-08-01 00:48:52 +02:00
Yonghua Zheng
8e552e5359 HID: hidraw: fix improper mutex release
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-31 19:48:55 +02:00
Benjamin Tissoires
6f49801827 HID: sony: fix HID mapping for PS3 sixaxis controller
Commit f04d51404f (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-24 16:57:09 +02:00
Nestor Lopez Casado
407a2c2a4d HID: hid-logitech-dj: querying_devices was never set
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-22 16:32:24 +02:00
Nestor Lopez Casado
c63e0e3700 HID: Revert "Revert "HID: Fix logitech-dj: missing Unifying device issue""
This reverts commit 8af6c08830.

This patch re-adds the workaround introduced by 596264082f
which was reverted by 8af6c08830.

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 c849a6143b 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 a9dd22b730 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 dcd9006b1b 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-22 16:32:24 +02:00
Linus Torvalds
f5b63ac0f7 Merge branch 'for-linus' of 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-04 15:35:08 -07:00
Jiri Kosina
21796b39c9 Merge branches 'for-3.11/wacom-fixed' and 'for-3.11/wiimote' into for-linus 2013-07-04 15:05:02 +02:00
Przemo Firszt
9d15762403 HID: wacom: Intuos4 battery charging changes
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-04 15:04:47 +02:00
Jiri Kosina
08ec2dcc35 Merge branches 'for-3.11/multitouch', 'for-3.11/sony' and 'for-3.11/upstream' into for-linus
Conflicts:
	drivers/hid/hid-core.c
2013-07-04 15:02:26 +02:00
Jiri Kosina
db58316892 Merge branches 'for-3.11/battery', 'for-3.11/elo', 'for-3.11/holtek' and 'for-3.11/i2c-hid-fixed' into for-linus 2013-07-04 15:01:01 +02:00
Andrew Duggan
811adb9622 HID: i2c-hid: support sending HID output reports using the output register
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-04 15:00:11 +02:00
Benjamin Tissoires
3685c18e17 HID: kye: Add report fixup for Genius Gila Gaming mouse
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-03 18:14:33 +02:00
Dmitry Torokhov
9d9a04ee75 HID: apple: Add support for the 2013 Macbook Air
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-07-02 20:39:29 -07:00
David Herrmann
b8e0fe31a7 HID: wiimote: support Nintendo Wii U Pro Controller
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-27 11:57:49 +02:00
Jiri Kosina
a688393bd3 HID: explain out-of-range check better
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-19 23:54:10 +02:00
Benjamin Tissoires
6f1891d019 HID: fix false positive out of range values
Commit 6da7066906 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-19 23:53:52 +02:00
Jiri Kosina
5b22b91ab6 HID: wiimote: fix coccinelle warnings
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-18 16:05:34 +02:00
Michael Rissi
a0be10c2e0 HID: roccat: check cdev_add return value
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-18 11:00:36 +02:00
Jiri Kosina
078328da5d HID: fold ps3remote driver into generic Sony driver
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-13 12:03:49 +02:00
Benjamin Tissoires
5939212df8 HID: multitouch: prevent memleak with the allocated name
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-12 11:13:38 +02:00
Thomas Meyer
a4a23f6d68 HID: hyperv: convert alloc+memcpy to memdup
Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-06-03 13:32:22 +02:00
Jiri Kosina
b1a1442a23 HID: core: fix reporting of raw events
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-03 11:27:48 +02:00
David Herrmann
876727eabf HID: wiimote: discard invalid EXT data reports
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-03 11:07:07 +02:00
David Herrmann
ee286c2e80 HID: wiimote: fix classic controller parsing
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-03 11:07:06 +02:00
David Herrmann
77a7480992 HID: wiimote: init EXT/MP during device detection
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-03 11:07:06 +02:00
David Herrmann
0d57eb8758 HID: wiimote: fix DRM debug-attr to correctly parse input
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-03 11:07:06 +02:00
David Herrmann
9f329741a6 HID: wiimote: add MP quirks
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-03 11:07:06 +02:00
David Herrmann
45ec9fff86 HID: wiimote: remove old static extension support
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-03 11:07:05 +02:00
David Herrmann
8b1fded7a3 HID: wiimote: add "bboard_calib" attribute
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-03 11:07:05 +02:00
David Herrmann
c7da08677d HID: wiimote: add sysfs extension/device-type attrs
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-03 11:07:05 +02:00
David Herrmann
d76f89e13a HID: wiimote: lock DRM mode during debugfs overwrite
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-03 11:07:04 +02:00
David Herrmann
51103c70bf HID: wiimote: fix ctx pointer in debugfs DRM-write
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-03 11:07:04 +02:00
David Herrmann
34472d370f HID: wiimote: add Motion Plus extension module
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-03 11:07:04 +02:00
David Herrmann
9d6f9ecb0c HID: wiimote: add Classic Controller extension
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-03 11:07:03 +02:00
David Herrmann
b6ee67b37c HID: wiimote: add Nunchuk support
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-03 11:07:03 +02:00
David Herrmann
f1d4bed45b HID: wiimote: add Balance Board support
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-03 11:07:03 +02:00
David Herrmann
4148b6bf8a HID: wiimote: add extension hotplug support
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-03 11:07:02 +02:00
David Herrmann
3b5f03c4e3 HID: wiimote: convert IR to module
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-03 11:07:02 +02:00
David Herrmann
0ea1675723 HID: wiimote: convert ACCEL to module
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-03 11:07:02 +02:00
David Herrmann
6c5ae01805 HID: wiimote: convert LEDS to modules
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-03 11:07:01 +02:00
David Herrmann
dcf3923138 HID: wiimote: convert BATTERY to module
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-03 11:07:01 +02:00
David Herrmann
20cef813b4 HID: wiimote: convert KEYS and RUMBLE to modules
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-03 11:07:01 +02:00
David Herrmann
27f0694214 HID: wiimote: add sub-device module infrastructure
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-03 11:07:00 +02:00
David Herrmann
d758b1f0c5 HID: wiimote: wake up if output queue failed
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-03 11:07:00 +02:00
David Herrmann
6b80bb94dc HID: wiimote: use cached battery values on I/O failure
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-03 11:07:00 +02:00
David Herrmann
c57ff761be HID: wiimote: add device detection
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-03 11:06:59 +02:00
David Herrmann
5682b1a869 HID: wiimote: keep HID device open
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-03 11:06:59 +02:00
David Herrmann
1393853832 HID: wiimote: move queue handling into separate struct
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-03 11:06:58 +02:00