Merge joystick input with another gamepad about xrlinuxdriver

[wheaney]

In searching for a nice way to detect all gamepads, I came across RPCS3's implementation for finding all joystick devices; they have similar implementations of this for all kinds of devices. We'll probably want to take a similar approach for finding relevant gamepads and then use just the first one initially.

[wheaney]

I have this working at this point for a PS4 controller, but my goal has been to use this with the Steam Deck and there's something odd about how the Steam Deck's built-in controller hardware is represented, as I'm not seeing its /dev/input device produce any events. I've been troubleshooting and debugging this Steam Deck issue for a good week and still haven't solved it.

[wheaney]

It seems like Steam Deck disables their controller output when not in a game or gaming mode, so that took a while to figure out. I've got the most recent implementation of this pushed to the device_mirroring branch. There's one TODO in there, and I think it's important to have a way for users to disable controller mirroring before pushing this to main.

[wheaney]

One other important note is that our virtual controller changes depending on what device it's mirroring (or if there's no device mirroring), but Steam stores controller configurations under the assumption that setup is one-and-done. So we'll either need to make our device look like a different device every time it mirrors a different device (or none), or have it reach out and remove steam controller configs whenever it's run.

[wheaney]

I've made a ton of progress on this issue and I have it working for Steam Deck sometimes as it seems like Steam Deck does a lot of "grab"bing and manipulating the /dev/input fds as you switch between desktop, gaming mode, actual games, and reordering controllers. I could continue to dial it in, but the PS4 mirroring behavior has actually taken a dive as I've improved the code to behave as a better mirror... as it looks to the Deck like two controllers are providing navigation input to the Gaming Mode UI at the same time. In order words, each attempt to move around the UI produces two movements in the same direction.

In the process of banging my head against this I've come across JoyShockMapper which doesn't necessarily solve all my problems but could simplify my implementation by: 1) not requiring that I create a virtual controller as it maps to keyboard/mouse and 2) not needing to work so closely to the libevdev library and reinvent the wheel. It would also allow me to use the glasses movement as actual IMU input, like gyro, rather than emulating joystick movement, so it would solve that problem for me as I was going to have to figure out a way to trick Steam into believing my virtual controller is a supported device type that has gyro, which so far has eluded me.

[wheaney]

After a lot of thought, I'm actually closing this in favor of moving away from a virtual gamepad and just switching to a virtual mouse. This allows for automatic combination of headset movement with game controllers without the need for my hacky device mirroring attempts. It'll also have more universal support, so Steam Deck will just work and be able to combine input with a controller much more easily.

These changes have already been made in this pull request.