infotagstimelinevideo games list
Video gamesGames groupsMediaCharactersPlatformsCompaniesEventsCross referencesReviews and magazinesForumUsers and editorsFAQs & Contacts
 

xwiimote driver

Software theme

These games use xwiimote, The 'official' way to interface with the wiimote driver within the Linux kernel.

This group exists even without any games for it. This is intentional.
While game controllers for USB and the joystick port (and a few more obscure game related devices) have been a part of the Linux kernel since ancient times, Bluetooth game controllers were not included until version 3.1. So using a wiimote (and related accessories) on GNU+Linux involved working around many GUN+Linux subsystems that were never designed to know about each other, let alone speak each other's code. cwiid and wiiuse are two such hacks. When running, they allowed a wiimote to be paired directly to their own software layer that would negotiate between bluetooth, the wiimote, Xorg, HID drivers, input events, uinput, Linux Input Subsystem userspace API (/dev/input/event*), Linux Joystick support (/dev/input/js*) (despite both being under '/dev/input/' they actually have very little in common), and the OS and make the wiimote appear to operate as some other type of real hardware (keyboard, mouse, gamepad, or some other HID device). cwiid and wiiuse came with control re-mapping tools by necessity. However, cwiid and wiiuse could also be integrated into a game or software as well. Players could run a game and within that game, pair with a wiimote and use it without the rest of the OS being aware of the details and the players would not need to be bothered by cwiid or wiiuse details.
Then came Linux Kernel 3.1 that included new Bluetooth HID devices like Wii, Xbox, and PlayStation# controllers. xwiimote was created as a layer on the kernel to use these controllers like any other hardware. And like any other hardware, the mapping is hard coded. The developers decided, who knows why, that the wiimote was not a gaming device. The wiimote was obviously a 11-key keyboard. Wiimotes instantly became useless. They later included other Wii controller types but still kept strange hard coded useless mappings. A default re-mapper was never supported. In fact, the developers of the kernel driver and xwiimote were done and apparently saw no need to do anything else at all. They pronounced the strange default mapping as unchangeable. It was up to each individual piece of software to implement a useful button mapping for the wiimote. But, the lead developer had alternate solutions to that; ignore wiimotes or talk to the xorg people.

Quoted from David Rheinsberg:
The default mappings for Wiimotes are really weird, I apologize for that. But we cannot really change them now. Furthermore, the Wiimote is no gamepad, neither is it a joystick. So there is no way to make it appear as a gamepad or joystick by default. Instead, the default action should be to ignore Wiimotes. This is what ./res/50-xorg-fix-xwiimote.conf does. Just copy it to /etc/X11/xorg.conf.d/ and Wiimotes will be ignored.

So, officially add Wimotes so they can officially be ignored. Hmm.
Xorg decided that a wiimote was a 11-key keyboard plus a pointing device.
xwiikeymap was included in xwiimote for a short while. It allowed a different mapping to be used when the system booted. It also treated each Wii accessory as an addition keyboard (Wiimote+Nunchuk=An 11-key keyboard and a 6-key keyboard, WM+Classic Controller=2 Keyboards again). xwiikeymap was removed, old versions of xwiimote with xwiikeymap were deleted. Old versions of xwimote with xwiikeymap have been removed from archive.org. The binary exits on Ubuntu Trusty CDs. The code might be gone. xwiiglue is an obscure re-mapper that was fairly useful, supported hot-plugging, and allowed Wii devices to be seen by the Linux as a game controller and multiple devices to be seen a single game controller (WM+NK, WM+CC, WM+BB, WM+WM). These ides would later prove useful. But xwiiglue depended on xwiikeymap. It also had the quirk of not differentiating between the Home, +, and - buttons across accessories. This is hard to do, cwiid and wiiuse where known for not being able to use these buttons as duplicates (each had to be re-mapped to the same function), so this must be hard coded into xwiimote.

Finally, everything came full circle and a re-mapper was created to bypass the wiimote kernel driver weirdness, MoltenGamepad. The solution was to let xwiimote do its thing and intercept all the events it tried to pervert. Everything gets redirected to one or more virtual gamepads. These virtual gamepads are persistent, they don't come unplugged unless the software tells them to do so. So the OS does not fiddled with them. When a Wiimote event occurs in the kernel, MoltenGamepad redirects it to the virtual gamepad according to a config file. There's a decent default file too; geared toward WM+NK, but doesn't leave out any accessory. Plug it in, MoltenGamepad remaps it all, the virtual gamepad does not change as far as the kernel and OS know. But MoltenGamepad can be told what to do. Switch from steering-wheel-wiimote, to Wiimote-Nunchuck, to Classic Controller, to Balance Board. The user can tell MoltenGamepad to change to a pre-set map, and/or let it happen according to config file rules when different accessories are hot-plugged. Despite xwiimote developer's best efforts, Wiimotes are gaming devices again.

If a game or software uses xwiimote (MoltenGamepad does), it requires the 3.1 or later Linux Kernel even if everything else will work on an older kernel and even if you are not using a Wiimote with the game.

Related, the Linux Kernel considers a PS4 Dualshock controller to be 3 devices.

Related group

Software
Linux Kernel 3.2.x