…I got my Wii Guitar Hero guitar working on SteamOS with fully functioning tilt and access to the Wiimote buttons, in spite of the Linux kernel's intentions, only remaining catch is it's not automated
so, for whatever reason the Linux kernel splits up a Wiimote into multiple devices, for a standard Wiimote this means you'll see a "Nintendo Wii Remote", a "Nintendo Wii Remote Accelerometer" and a "Nintendo Wii Remote IR". If you've got a Wiimote with MotionPlus, it'll also have a "Nintendo Wii Remote Motion Plus" device, and finally, if you have an guitar plugged in, a "Nintendo Wii Remote Guitar"
most game input systems expect 1 controller == 1 device, which this breaks in a big way, and I can kinda get why they did this; if your stuff really cares about talking to the MotionPlus or the like I guess you'll write code to do that, but it does limit us somewhat; even Steam is very confused by this setup, and while it does only show two devices, it's still not able to differentiate them properly, and it's similarly poor when using emulators which use plain Linux devices or SDL like, for example, RPCS3
so I thought I was snookered… but it turns out, not quite! like I said, the devices are all there, and they'll all send you valid input events simultaneously, so surely, I thought to myself, surely it's possible to take those events, map them to something else, and output that as a virtual controller - after all, Steam Input is basically doing that just with a single device at a time
this led me down quite a rabbit hole, I learned far too much about Linux's event subsystem for one girl, and ultimately came to the conclusion that nah, I'd probably have to write some code for this. I found the Python evdev package and it looked promising, but I couldn't get it to build on SteamOS due to the lack of kernel headers and other such quirks
but then, having gone "fuck it, I'll write another thing in Rust" and starting to read up on the evdev Rust bindings, I stumbled upon evsieve
in which sometimes someone already got nerdsniped and built the niche solution you were considering
I got so lucky here, evsieve is a Rust tool which takes evdev events from one or more devices and, via a series of command-line arguments, optionally adjusts, filters, or remaps them, and outputs them to one or more virtual devices, it also has a handy print function so you can snoop on what it's processing at any point in the chain, pretty handy stuff
that being said, it was a bit of an adventure getting it to build, too, as I still needed working Linux header files, and sadly my previous workaround to this, Linuxbrew, doesn't ship with any copy of libevdev
sooo I finally took the plunge and installed Distrobox, a tool which, while somewhat enigmatic initially, lets you run other Linux distributions' tools within a container, but mapped (for normal intents and purposes) as if it were your actual system, this let me install a "full fat", writable copy of Arch Linux and build evsieve from there, producing a Rust binary which to my relief works just fine outside of the container, phew!
a partial solution
it took a bunch of experimentation and your mileage will likely vary, but having spent a little while futzing around with this and coming up with a satisfactory mapping, here's my current configuration:
evsieve \
--input /dev/input/event18 domain=wiimote grab persist=exit \
--map btn:south@wiimote btn:mode@wiitar \
--map btn:1@wiimote btn:thumbl@wiitar \
--map btn:2@wiimote btn:thumbr@wiitar \
--map btn:mode@wiimote btn:z@wiitar \
--map key:next@wiimote btn:start@wiitar \
--map key:previous@wiimote btn:select@wiitar \
--map key:left@wiimote btn:dpad_up@wiitar \
--map key:right@wiimote btn:dpad_down@wiitar \
--map key:up@wiimote btn:dpad_left@wiitar \
--map key:down@wiimote btn:dpad_right@wiitar \
--input /dev/input/event19 domain=guitar grab persist=exit \
--map btn:1@guitar btn:south@wiitar \
--map btn:2@guitar btn:east@wiitar \
--map btn:3@guitar btn:north@wiitar \
--map btn:4@guitar btn:west@wiitar \
--map btn:5@guitar btn:tl@wiitar \
--map btn:start@guitar btn:start@wiitar \
--map btn:select@guitar btn:select@wiitar \
--map btn:dpad_up@guitar btn:dpad_up@wiitar \
--map btn:dpad_down@guitar btn:dpad_down@wiitar \
--map abs:hat1x@guitar abs:rx:3x@wiitar \
--map abs:x@guitar abs:x@wiitar \
--map abs:y@guitar abs:y@wiitar \
--input /dev/input/event16 domain=accel grab persist=exit \
--block abs:rz@accel abs:rx@accel \
--map abs:ry:-59~..~-60@accel btn:select:1@wiitar \
--map abs:ry:~-60..-59~@accel btn:select:0@wiitar \
--output name="Wiitar" @wiitar
pretty gnarly, right? this requests exclusive access (to prevent duplicate inputs) and takes events from the three devices of interest (the Wiimote, the guitar and the accelerometer) and maps them all into one virtual "Wiitar" device which is shaped more or less like a regular gamepad for convenience, with a bunch of tweaks and tilting the guitar up more than about ⅔ of the way mapped to select for overdrive/star power
hahaha, and then what?
for what it's worth, I think I will probably mess with some more of evsieve's features here; the mapping tools seem really powerful. I am wondering if I can adapt my Guitar Hero guitar to have (more of) the Rock Band guitars' features like the effects options by making use of some of the currently not very useful Wiimote buttons like 1, 2, plus or minus
but thanks to evsieve this has been something I've tinkered with over the course of a few evenings and not months and months, and I can, more or less, just get back to playing the game with tilt
but next I want to figure out how to automate running this when the Wii Guitar connects, so it's mostly seamless, but hey, I'm pretty proud of getting this far, and grateful that evsieve saved me a whole lot of pain
