Add systemd unit and misc improvements

[terencode]

No description provided.

[terencode]

For some reason, the script doesn't detect the gamepad when started with the systemd unit. Investigating...

[terencode]

This is because the script fails silently when it's unable to load the json files. Right now I'm trying to make the program return an error code but I'm stuck with the handle_devices while loop...

[terencode]

The last commit is what I tried but it's not working well... Any idea? I'm stuck at exiting the program with a non 0 exit code.

[terencode]

I think I'm just going to check for the .json files at the start.
It makes more sense to exit without even trying to detect a controller if those files are missing.

[joaorb64]

First of all, it makes me so happy to have someone contribute to a repo of mine, so thank you so much for putting effort to this!

I suppose the edits you made to the code made it more python-like, so it's perfect for a merge to me.

About the systemd part... I'm not really sure on how to go with this to be honest.

Ideally, joycond-cemuhook should be an alternative to joycond, not a complement. Either if the server was implemented on joycond (but well, it's in C so we'd have to start from scratch) or if it could talk better with joycond, for example, to know which joycons are part of a L+R combined joycons device. Currently I ask the user to select the motion source. Won't work well as a Daemon service.

At the same time, from how things are progressing, joycond-cemuhook could become a general adapter for any input devices to the cemuhook protocol, since the way I implemented the json config files is very generic (you can even assign joystick directions to button pushes).

I was also thinking of building a gui for users to have an easier time assigning controllers to slots when using 4 controllers.

[terencode]

First of all, it makes me so happy to have someone contribute to a repo of mine, so thank you so much for putting effort to this!

That's the power of open-source my friend :)

Your thoughts are very interesting. Maybe right now we should work on the 'backend' part and prepare it to be optionally used with a GUI later (using DBUS?).

I think (at least for now) we should improve the communication with joycond and not try to include it.

What do you think?

Regarding this PR, I think it should be a good first step towards this concept of backend running in the background and communicating with a GUI although if you have a better idea I'm all ears :)

[joaorb64]

I agree with you. There's a lot to be implemented before messing up with a GUI.
I this PR ready for a merge?

[terencode]

I this PR ready for a merge?

Nope, I was waiting for your approval to know what direction we're headed in.
I will work on it now.

[joaorb64]

I just pushed e51f79c, you might wanna look into it. Not that many changes overall, but fixed some crucial issues :)

[terencode]

Cool, I just don't have multiple controllers to test it.

[joaorb64]

For now, for your code to work, we could have a script to copy the json config files to some directory like /home/user/.joycond-cemuhook (I'm not entirely sure of what's the best practice for directories) and add an argument to make it so merged joycons get motion from the motion device with their Mac address (left joycon), so it could work entirely as a Daemon... What do you think?

[DanielOgorchock]

I think going forward a good way for joycond-cemuhook to determine which motion inputs are associated with the virtual uinput device joycond creates would be using the input devices' uniq values.

hid-nintendo sets each controller's input device's uniq to the controller's MAC. This works fine already for the pro controller, since joycond doesn't have to create a separate virtual userspace input device for it. The normal input dev and the IMU input dev have the same uniq value, so they can be matched. It's not fully there yet for the combined joy-cons, since right now there's no way to set uniq using uinput. There's a patch on the mailing list from December that adds that functionality, so I'm hoping that eventually gets merged (https://patchwork.kernel.org/patch/11270107/).

joycond could set the virtual input's uniq value to both joy-cons' uniqs (maybe delimited by a comma between, like "MACLEFT,MACRIGHT"). That would allow automatic association between the combined input device and its two IMU input devices.

[joaorb64]

Cemuhook only supports one motion input per controller, but your solution should make controller+IMU association way easier. I think it's ideal.
I noticed combined joy-cons get left joycon's uniq. Could you use right joycon for now instead, in case it's just an arbitrary decision? I ask this thinking of having the right joycon as a wiimote for Dolphin by default.