search

v1993 / evdevhook2

Cemuhook UDP server for devices with modern Linux drivers
GNU General Public License v3.0
25 stars 6 forks source link

Troubleshoot Cemu configuration #2

Closed git-developer closed 1 year ago

git-developer commented 1 year ago

I'm maintaining batocera-extra to improve motion support in batocera. Your other project linuxmotehook2 is already integrated, as well as joycond-cemuhook (Nintendo) and dsdrv-cemuhook (Sony). Now that you released v1.0.0 of evdevhook2 I thought I give it a try, too. The integration is available in branch feature/evdevhook2.

Tests with Citra have been successful - motion works, tested with a Switch Pro and a DS5 controller on a custom port. So evdevhook2 works - great!

Unfortunately, I didn't get it to work with Cemu. I tried the version bundled with batocera as well as an AppImage binary. Behavior is the same: I can pick a controller for API DSUController, but I can't map any buttons, and motion also doesn't work. I tried to add the same controller via SDLController API, but button mapping doesn't work either. This problem does not occur using joycond-cemuhook or dsdrv-cemuhook.

Do you have an idea what could be wrong here?

v1993 commented 1 year ago

Regarding buttons: evdevhook2 does not try to expose them by design. Modern controller drivers, which are the only ones this project supports anyways, expose their buttons in a way that SDL is able to pick up - and you can mix low-latency buttons from such source with DSU motion in any decent emulator. IIRC Cemu elected to use SDL's GameController API for their controller input instead of its Joystick API, which is IMO not a great idea since it requires to have a button mapping available for controller to use it - check out GamepadTool for creating such mappings. But ultimately, this is something to troubleshoot without regards to evdevhook2 - button inputs will come from SDLController source in either case.

Regarding motion - there already have been some difficulties with motion (namely messed up directions) on Cemu specifically in my other project, linuxmotehook2, which uses the same gcemuhook library (also by me) as its base. I don't really have any suitable Wii U games to test this well enough and the issue makes little sense to me overall, since data packets sent to all emulators are structured identically.

Finally, it might be a good idea to run cemu with environment variable SDL_HINT_JOYSTICK_HIDAPI=0 set to see if anything changes.

v1993 commented 1 year ago

As a side note, after looking at your script: would you prefer if it was possible to set port using --port XXXXX as an alternative to using a full-fledged config file?

git-developer commented 1 year ago

Thanks for your quick response. I will investigate the cemu issue later and will report back if I find out something.

Yes, a command line argument would be nice, but it's no real problem without it.

Since this is not an issue of evdevhook2, I will close it (while the discussion may continue, of course).

git-developer commented 1 year ago

I managed to make it work in Cemu, too. It's not really clear to me what happened because in my second try it "just worked".

Thanks to your hints I could simplify the generation of the cemu configuration file. Before, I created one single controller being either SDL or DSU, with both buttons mapping and motion config. This does not work for evdevhook2 because buttons are SDL and motion is DSU. Now there is one controller for the buttons using SDL, and a second one for motion using DSU. This simplifies my generator because I don't need to manage a DSU button mapping anymore.

Using this configuration, both buttons and motion work, tested with a Switch Pro Controller (USB) and a DS5 controller (Bluetooth). It makes no difference if either of SDL_HINT_JOYSTICK_HIDAPI or SDL_JOYSTICK_HIDAPI is set to 0 or 1.

evdevhook2 is now used as default motion provider in batocera-extra, because it is easier to handle than two separate providers joycond-cemuhook and dsdrv-cemuhook. Thanks for maintaining!

v1993 commented 1 year ago

That's nice to hear! I'd like to note, though, that as of now evdevhook2 does not support exposing touchpad of DS controllers. It most definitely can be implemented, although I myself do not own any such controllers to have a comfortable development setup.

git-developer commented 1 year ago

I think there's no requirement for touchpad support in evdevhook2, because the touchpad is already available. I don't know why, it could be that the touchpad is registered as an input device, like a USB mouse. I tested with a DS4 and a DS5 controller, both are working out-of-the-box.