The version number is not needed at all for in-tree drivers. Upstream git is
used to track module versions.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Keep track of current drm and add new debugfs file which reads or writes the
current DRM.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

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: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add helper functions similar to the write-mem helpers but for reading wiimote
memory and eeprom.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Wiimote extension and sound support need access to several symbols so move them
into a new header.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Extension and sound support for the wiimote are quite complex and will be
implemented in separate source files. Hence rename the current driver to "-core"
suffix so multiple files can be linked into this module.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add entry to MAINTAINERS and also bump version level as the core driver is
feature complete now.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This registers a power_supply device for every remote to retrieve the current
battery charge level. Since this information is not sent by the wiimote
continously, we need to explicitely request it.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The wiimote does not send status reports continuously so this adds a helper
function to request a status report and parses the battery charge level.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Initialize the IR cam if the related input device is opened by userspace. Stop
IR cam again if userspace is no longer interested in its data events.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The wiimote IR cam needs a fairly complex initialization sequence. This adds a
helper function that performs IR initialization synchronously.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add helpers to synchronously write registers of the wiimote. This is heavily
used by initialization functions for wiimote peripherals.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

To initialize wiimote peripherals, the stream to the wiimote must be held
exclusively by the initializer, otherwise the initialization will fail. Many
initializations require multiple memory requests to be sent synchronously so we
need a way to lock the stream and release it when we are done.

This adds several helper functions which allow to lock the stream, then send
requests, wait for the answers and release the stream again.

When holding the lock, the function may sleep and interrupted by signals.
Also it returns after a short timeout so userspace shouldn't notice long
delays.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The wiimote allows direct access to its memory mapped registers and
internal eeprom. This adds support to access this memory and handle
memory events.

There are two macros which wrap up the memory access functions to avoid
accidentally overwriting sensitive eeprom data because a boolean value
was wrongly set.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

If an extension is connected the wiimote may report data though DRMs that
contain extension data. This adds handlers for these DRMs but discards extension
data since we do not support it, yet.
It prints a warning to kernel log if an unhandled report is catched. Since we
handle all requests now, this should never happen, though.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Parse IR data and report it to IR input-device. IR data is sent in 3 different
formats, but we only support the basic format as there is no way to send the
additional information to userspace.
All three formats are compatible with the basic IR data format so we need only
one parser.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The IR cam of the wiimote reports 4 trackable lights as absolute values. Since
we can turn the IR cam on and off, we register a separate input device so we can
react on open/close callbacks to save wiimote battery power when IR cam is not
needed.

The cam can be in four states: off, basic, extended and full
The DRM chooser automatically selects a proper DRM that includes all required IR
data so no information is lost.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add parser functions for accelerometer data reported by the wiimote. The data is
almost always reported in the same format, so we can use a single handler.
However, an own handler function is created for each DRM-mode because when IR
and extension support is added, each of them is parsed differently.

Also set the appropriate DRM including accelerometer data on DRM requests to
actually retrieve the accelerometer data.

Data is reported to userspace as ABS_RX/Y/Z values. The values are between -500
and 500 and 0 means no acceleration. See also userspace xwiimote library for
data parsing.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add new input device for every wiimote which is used to report accelerometer
data to userspace. Only if the input device is currently open, we make the
wiimote send accelerometer data. This saves a whole lot of energy on the wiimote
if an application is only interested in button input reports.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The wiimote has a single rumble motor. This adds force feedback support for
wiimote devices with FF_RUMBLE. The rumble motor is very simple and only
supports an on/off switch so no complex ff-effects are supported.

This also removes the event callback that was registered before but unused. The
ff-device overwrites this callback, anyway.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This adds support for the wiimote's rumble device. Every output report can
enable and disable the rumble motor. Hence, every output report must look up our
new RUMBLE flag and make sure that it does not unintentionally toggle the
rumble motor.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The wiimote resets the current drm when an extension is plugged in.
Fortunately, it also sends a status report in this situation so we just
reset the drm on every status report to keep the drm consistent.

Also handle return reports from the wiimote which indicate success and
failure of requests that we've sent.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The wiimote reports data in several data reporting modes (DRM). The DRM
request makes the wiimote send data in the requested drm.

The DRM mode can be set explicitely or can be chosen by the driver. To let
the driver choose the DRM mode, pass WIIPROTO_REQ_NULL placeholder to it. This
is no valid request and is replaced with an appropriate DRM.

Currently, the driver always sets the basic DRM_K mode, but this will be
extended when further peripherals like accelerometer and IR are supported.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

This registers 4 led devices to allow controlling the wiimote leds via standard
LED sysfs API. It removes the four sysfs attributes so we don't have two APIs
for one device.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Even though the bluetooth hid backend does not react on open/close callbacks, we
should call them to be consistent with other hid drivers.

Also the new input open/close handlers will be used in future to prepare the
wiimote device for IR/extension input.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The new locking scheme in HID core allows us to remove a bit of synchronization.
Since the HID layer acts synchronously we simply register input core last and
there are no synchonization issues anymore.
Also register sysfs files after that to simplify the code.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add sysfs files for each led of the wiimote. Writing 1 to the file
enables the led and 0 disables the led.

We do not need memory barriers when checking wdata->ready since we use
a spinlock directly after it.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Save the current state of the leds in the wiimote data structure. This
allows us to discard new led requests that wouldn't change anything.
Protect the whole state structure by a spinlock. Every wiiproto_*
function expects this spinlock to be held when called.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Add new request that sets the leds on the target device. Also, per
default, set led1 after initializing a device.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Parse input report 0x30 from the wiimote as button input. We need to
send events for all buttons on every input report because the wiimote
does not send events for single buttons but always for all buttons
to us. The input layer, however, filters redundant events.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Create array of all event handlers and call each handler when we
receive the related event.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The raw hid output function that is supported by bluetooth low-level
hid driver does not provide an output queue and also may sleep. The
wiimote driver, though, may need to send data in atomic context so
this patch adds a buffered output queue for the wiimote driver.

We use the shared workqueue to send our buffer to the hid device.
There is always only one active worker which flushes the whole output
queue to the device. If our queue is full, every further
output is discarded.

Special care is needed in the deinitialization routine. When
wiimote_hid_remove is called, HID input is already disabled, but HID
output may still be used from our worker and is then discarded by the
lower HID layers. Therefore, we can safely disable the input layer since it
is the only layer that still sends input events.
Future sysfs attributes must be freed before unregistering input to
avoid the sysfs handlers to send input events to a non-existing input
layer.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The wiimote driver needs to send raw output reports to the wiimote
device. Otherwise we could not manage the peripherals of the wiimote
or perform memory operations on the wiimote.
We cannot use hidinput_input_event of the lowlevel hid driver, since
this does not accept raw input. Therefore, we need to use the same
function that hidraw uses to send output. Side effect is, the raw
output function is not buffered and can sleep.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The wiimote first starts HID hardware and then registers the input
device. We need to synchronize the startup so no event handler will
start parsing events when the wiimote device is not ready, yet.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Register input device so the wiimote can report input events on
it. We do not use HIDINPUT because the wiimote does not provide any
descriptor table which might be used by HIDINPUT. So we avoid
having HIDINPUT parse the wiimote descriptor and create unrelated
or unknown event flags. Instead we register our own input device
that we have full control of.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Allocate wiimote device structure with all wiimote related data
when registering new wiimote devices.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The wiimote uses a fake HID protocol. Hence, we need to prevent
HIDINPUT and HIDDEV from parsing wiimote data and instead parse
raw hid events.
Add VID/PID to hid-core so the special driver is loaded on new
wiimotes.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>