-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
changing hidraw of controllers to 0600 to stop steam from hijacking #27
Conversation
I think the cleaner way to achieve this effect is to change This may be what you were referring to in the issue you opened. It will remove the hidraw device, and steam won't mess things up anymore. It's probably fine for it to be that way in the dkms module for now until a more permanent solution is discovered between hid-nintendo/steam. It's annoying because steam still won't recognize the evdev as an input, but that's the same when using firejail. For games not relying on steam's input system (like games using sdl2 directly), this should be fine. I've found though that if I run steam and hid-nintendo as-is (without any firejail or masking away HIDRAW), I can get things working with steam's input system after replugging the controller in a few times. It's flaky for it to start working though, so maybe just killing hidraw is preferable for now. |
hmm i do not know, i think joycond is more suited for the task to be honest as it already is root anyways and also touches evdev devices. there can be a configuration option to toggle it. it might be better to leave support for hidraw in the kernel module. |
Thinking about this more, it's probably even simpler to do this via an optional udev rules file. The current rules are already modifying permissions on the evdevs themselves. It should be simple for us to remove uaccess from the hidraw devs. Maybe it can be gated by a simple cmake variable to decide whether or not to install that rule. |
yeah that approach is basically the same thing with no C code. although there might be other rules udev overriding them? steam in arch installs /usr/lib/udev/rules.d/70-steam-input.rules:
naming them to 99-something.conf probably works but is a bit ugly imo |
Ever since the patch that reduced the number of rumble subcommands sent, I actually think hid-nintendo and steam have been coexisting acceptably (at least for me). The time issues crop up seem to be when hid-nintendo starts sending subcommands (rumble, led brightness setting, etc.). Since the rumble subcommands are now only sent when there's an ffeffect, I haven't had issues. Can anyone else confirm? |
sorry, no it completely borks it in my setup |
I think I have a hacky idea to make it actually work with steam. joycond can create a uinput device for the pro controller (similar to what it does for the joycons, but simpler since it's only one evdev). We can set the product id to that of the joycon charging grip. Then steam should actually use the evdev. |
yea, it is a good idea to generalize the code anyways - making all controllers to use a created uinput device. wont games be confused though ? |
joycond now blocks steam's hidraw access via udev and supports pairing the procon as a uinput dev |
i do not know C, this does indeed work. please check it over.