Skip to content
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

Closed
wants to merge 3 commits into from

Conversation

nicman23
Copy link

@nicman23 nicman23 commented Aug 2, 2020

i do not know C, this does indeed work. please check it over.

@DanielOgorchock
Copy link
Owner

I think the cleaner way to achieve this effect is to change ret = hid_hw_start(hdev, HID_CONNECT_HIDRAW); in hid-nintendo to ret = hid_hw_start(hdev, 0);

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.

@nicman23
Copy link
Author

nicman23 commented Aug 4, 2020

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.

@DanielOgorchock
Copy link
Owner

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.

@nicman23
Copy link
Author

nicman23 commented Aug 5, 2020

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:

# Nintendo Switch Pro Controller over USB hidraw
KERNEL=="hidraw*", ATTRS{idVendor}=="057e", ATTRS{idProduct}=="2009", MODE="0660", TAG+="uaccess"
# Nintendo Switch Pro Controller over bluetooth hidraw
KERNEL=="hidraw*", KERNELS=="*057E:2009*", MODE="0660", TAG+="uaccess"

naming them to 99-something.conf probably works but is a bit ugly imo

@DanielOgorchock
Copy link
Owner

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?

@nicman23
Copy link
Author

sorry, no it completely borks it in my setup

@DanielOgorchock
Copy link
Owner

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.

@nicman23
Copy link
Author

nicman23 commented Sep 5, 2020

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 ?

@DanielOgorchock
Copy link
Owner

joycond now blocks steam's hidraw access via udev and supports pairing the procon as a uinput dev

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants