Reaching evdevhook2 from remote IP address

[F2FG]

Unfortunately I think evdevhook2 binds the server to localhost (127.0.0.1) and I don't see the possibility to set this parameter in the config file. This could be the reason why I can't reach the UDP server from a remote IP address.

I would love to use evdevhook2 connecting from a different gaming PC and currently I'm not able to. Similar software that works with DS4 controllers let me connect from a remote IP if I set 0.0.0.0 as the server address.

Do you think I can achieve this with some extra configuration?

Thank you very much for this software, it's awesome!

[v1993]

Interesting, I've never tested this personally, but would expect it to work. See https://github.com/v1993/gcemuhook/blob/acde07238a16c78e39f4aee241ab7ae53b46cde6/src/Server.vala#L119-L126 for socket creation and binding code - it binds to any interface, which should make it available on all interfaces.

[F2FG]

Thank you very much for the quickest feedback. I'll investigate from another system and let you know how it goes.

[F2FG]

The solution was uber easy, I just needed to run evdevhook2 with sudo! I can confirm that evdevhook2 works from remote PCs.

This is truly amazing specially for cloud computing.

[v1993]

I'm not sure what exactly you refer to by "cloud computing" here, but glad you got it sorted out 😅.

That said, I find it a little odd that sudo was needed, but oh well, might be a system-specific privilege limitation.

[F2FG]

Cloud gaming. I have a gaming machine (a powerful VM in a Proxmox server with a 3080) with a Sunshine server that I access via Moonlight. Thanks to your tool I can game remotely at 1080p-60fps from any client that can easily decode h264, for example something as little and old as an Intel Compute Stick running Lubuntu.

I can tell you that running it with sudo is needed in the latest Ubuntu 22.04 and Lubuntu 22.04. Do you want me to test something to make it run without sudo?

[v1993]

I see, glad to know you've found it to be so useful!

I'm not really sure what could be causing this and since running with sudo is a viable workaround I'll just leave it be. I've just tested this locally (using Manjaro) and definitely can reach the socket from my phone, so this may have something to do specifically with your remote gaming setup. Hard to guess.

[F2FG]

I don't think it's because of the remote gaming setup, if I don't use sudo evdevhook2 doesn't give any error but it doesn't list the Pro Controller as connected either, it just hangs:

On Ubuntu based systems I had a similar issue with similar software and I had to tinker with /etc/udev/rules.d/ rules, I guess this is the same situation. I use this client exclusively for game streaming, so needing sudo is not an issue.

[v1993]

It would have helped a lot if you mentioned this problem first, since it has nothing to do with remote access. Yes, it's just an issue with access rights to device nodes. Yes, it can be fixed with udev rules.

…

On Tue, Sep 12, 2023, 12:32 F2FG ***@***.***> wrote: I don't think it's because of the remote gaming setup, if I don't use sudo evdevhook2 doesn't give any error but it doesn't list the Pro Controller as connected either, it just hangs: [image: Screenshot from 2023-09-12 11-28-13] <https://user-images.githubusercontent.com/50996306/267282583-416d14cb-5e38-4b33-8133-b59e893f23a2.png> On Ubuntu based systems I had a similar issue with similar software and I had to tinker with /etc/udev/rules.d/ rules, I guess this is the same situation. I use this client exclusively for game streaming, so needing sudo is not an issue. — Reply to this email directly, view it on GitHub <#9 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AD4AXIWT56LZR7HXSC4A35DX2AT2TANCNFSM6AAAAAA4TZ3X7M> . You are receiving this because you commented.Message ID: ***@***.***>

[F2FG]

I'm sorry I didn't mention it, but I didn't know how it was supposed to work until I randomly tried to execute evdevhook2 with sudo. Maybe I would add something like this in the README.md file, just to point users in the right direction:

No configuration is required to get started - just run the resulting binary and it will list and expose all supported controllers. Example output:

Found device Nintendo Switch Pro Controller IMU (unique identifier 'AB:CD:11:22:33:EE') - connecting... done!

If the binary doesn't work as expected, try to run it with sudo. This workaround has been reported to work on Ubuntu based systems and it can be fixed with udev rules.

A nice surprise is that evdevhook2 already works with non original controllers like the Gulikit Kingkong Pro.

[v1993]

Good suggestion, I've opened #10 with proposal for what I think is an even better solution to the same problem. It was unviable initially, but now it's doable without significant false alerts thanks to information udev provides.

Regarding support for unofficial devices - you should thank kernel driver developers for that one! The entire idea behind evdevhook2 is to use existing kernel drivers instead of coding them in userspace via HIDRAW interface.

[F2FG]

Much better! Thank you very much for your time.

[F2FG]

Quick update about permissions on Ubuntu (I personally tested this on Ubuntu 22.04, 23.04 and 23.10).

I tried many options with udev rules but I couldn't execute evdevhook2 without sudo. The only solution that worked for me was to add my user to the input group:

sudo usermod -a -G input USER-YOU-WANT-TO-ADD

After doing that everything is working as expected. I understand that this can cause many security issues (a user in the input group has full control over all device nodes under /dev/input, that means they can read the events generated by any input devices, and they can also inject their own events), but the system in which I did this is a simple gaming box with no access to important or personal data.

[F2FG]

And just when I was ready to give up... I got it in the correct way! No need to add the user to the input group.

Here is the full tutorial:

udev rule for evdevhook2 and Nintendo Pro Controller

Run evdevhook2, if you don’t have the correct permissions to access the controller it will tell you that it can’t access /dev/input/event#, where # is a number.

Run this command and change /dev/input/event# with the correct number you just found:

udevadm info -a -p $(udevadm info -q path -n /dev/input/event#)

The command will display a long list of attributes. Identify the name of the input device, in my case it is:

ATTRS{name}=="Nintendo Switch Pro Controller IMU"

Now you can create the udev rule with this command:

sudo nano /etc/udev/rules.d/71-evdevhook2-nintendo-pro-controller.rules

Paste the content of the rule:

# Nintendo Switch Pro Controller for evdevhook2
SUBSYSTEM=="input", ATTRS{name}=="Nintendo Switch Pro Controller IMU", MODE="0660", TAG+="uaccess"

Edit the device name if needed, save, exit and reboot.

[v1993]

I'd suggest using VID/PID of device instead of its name. Also, I don't think you need to explicitly set the access mode, just TAG+="uaccess" should do.

Finally, use ``` for multiline code blocks. Here's the complete rule set for Nintendo controllers (save as /etc/udev/rules.d/70-nintendo-switch.rules, NOT as `99-something.rules`):

# Joy-Con L
SUBSYSTEM=="usb", ATTRS{idVendor}=="057e", ATTRS{idProduct}=="2006", TAG+="uaccess"

# Joy-Con R
SUBSYSTEM=="usb", ATTRS{idVendor}=="057e", ATTRS{idProduct}=="2007", TAG+="uaccess"

# Switch Pro Controller
SUBSYSTEM=="usb", ATTRS{idVendor}=="057e", ATTRS{idProduct}=="2009", TAG+="uaccess"

# SDK Debugger
# Needed for dumping over USB with nxdumptool rewrite
SUBSYSTEM=="usb", ATTRS{idVendor}=="057e", ATTRS{idProduct}=="3000", TAG+="uaccess"

[F2FG]

I would have preferred to use VID/PID too, but unfortunately on Ubuntu

SUBSYSTEM=="input", ATTRS{idVendor}=="057e", ATTRS{idProduct}=="2009", TAG+="uaccess"

does not work, instead

SUBSYSTEM=="input", ATTRS{name}=="Nintendo Switch Pro Controller IMU", TAG+="uaccess"

works perfectly. I removed the access mode setting and you are right, it's not necessary!

[F2FG]

To make it work with VID/PID the correct syntax - at least on Ubuntu - is:

SUBSYSTEM=="input", ATTRS{id/product}=="2009", ATTRS{id/vendor}=="057e", TAG+="uaccess"

I've never seen ATTRS{id/product} used before, I've always seen ATTRS{idProduct} but hey... You never finish to learn...

Thank you for all the hints

[v1993]

I'm fairly sure that's not how it's supposed to be - unless Canonical is doing its Canonical thing again. Please remember that udev rules are only applied upon device reconnection, not instantly. I have the rule for SDK Debugger set up locally and it works perfectly.

[F2FG]

I always reboot after I edit the udev rule because I could't believe it was not working.

Yes, Canonical is doing its Canonical thing again.

[F2FG]

I desperately decided to test this after I saw this:

See, the syntax on Ubuntu is the one I'm using :(

[v1993]

Okay, now that is interesting. I've tested this locally on Manjaro and can confirm that idProduct/idVendor are only set when using device over USB, but not over bluetooth (where they are set to those of bt adapter). id/ versions are always available. How odd.

[F2FG]

Fortunately when you'll have to deal with Bluetooth devices you won't have to waste as many hours as I did :)