- 03 6月, 2013 15 次提交
-
-
由 David 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: NDavid Herrmann <dh.herrmann@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 David 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: NDavid Herrmann <dh.herrmann@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 David 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: NDavid Herrmann <dh.herrmann@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 David 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: NDavid Herrmann <dh.herrmann@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 David 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: NDavid Herrmann <dh.herrmann@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 David 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: NDavid Herrmann <dh.herrmann@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 David 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: NDavid Herrmann <dh.herrmann@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 David 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: NDavid Herrmann <dh.herrmann@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 David 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: NDavid Herrmann <dh.herrmann@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 David 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: NDavid Herrmann <dh.herrmann@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 David 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: NDavid Herrmann <dh.herrmann@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 David 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: NDavid Herrmann <dh.herrmann@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 David 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: NDavid Herrmann <dh.herrmann@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 David 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: NDavid Herrmann <dh.herrmann@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
由 David 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: NDavid Herrmann <dh.herrmann@gmail.com> Signed-off-by: NJiri Kosina <jkosina@suse.cz>
-
- 23 11月, 2011 7 次提交
-
-
由 David Herrmann 提交于
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>
-
由 David Herrmann 提交于
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>
-
由 David Herrmann 提交于
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>
-
由 David Herrmann 提交于
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>
-
由 David Herrmann 提交于
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>
-
由 David Herrmann 提交于
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>
-
由 David Herrmann 提交于
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>
-