ds4drv
ds4drv copied to clipboard
chrippa
Original grabbed joystick device causing problems in hidraw mode
When using the hidraw mode, ds4drv grabs the original joystick device (provided by the kernel drivers) and creates a new device. The original device is still present for the rest of the system, but it is disabled. Seems like the original device is causing problems. -@Ape
As above. Running either minecraft 1.7.10 with liteloader installed or FEZ from steam with this running causes a hang in both, and both remain hung until ds4drv is killed. Immediatly after running systemctl stop ds4drv.service both resume function, while the latter, even if I kill all steam and such processes continues to run in D state, and will not even respond to SIGKILL, but once I disable it it kills off properly.
Are you using the hidraw mode with ds4drv? If you are, then I think that is the problem. The extra joystick device that is created is there, but unresponsive. I think it causes trouble with the way some games initialize game controllers. Try testing it in raw mode (having to put the DS4 into sync mode each time). This should work, though it's not as easy.
blarg. I'll try that, but I'll not be happy XD still, very annoying issue, would hope that it could be fixed at some point :)
hrm... well, how does this exactly work, then. I've held the PS+Share buttons, got the blink, but no results... ah nevermind. powered it on normally and all is well. But its still rather strange that hidraw would kill the functionality of these games :/
I would close this issue, but changing to non-hidraw mode is more of a workaround than an actual fix.
I don't think anyone has found a way to remove the other js devices (the ones that are not being used anymore when using hidraw mode). It must be possible, as xboxdrv removes them in a similar fashion I believe.
xboxdrv uses the EVIOCGRAB flag on the joystick device file handler in order to have exclusive access to a joystick device. That way, other programs will not use the joystick device so the controller is only seen once. Here is an example. https://github.com/Grumbel/xboxdrv/blob/master/src/controller/evdev_controller.cpp#L70
if (m_grab)
{ // grab the device, so it doesn't broadcast events into the wild
int ret = ioctl(m_fd, EVIOCGRAB, 1);
if ( ret == -1 )
{
close(m_fd);
throw std::runtime_error(strerror(errno));
}
}
I took a look at python-evdev, and it does have EVIOCGRAB support, simply called "grab". It also looks like ds4drv is already using it (you can see it in hidraw.py, in the HidrawDS4Device class).
This seems to make sense, since ds4drv DOES grab the device properly, it just leaves the non-responsive one behind. Maybe the bit of code that xboxdrv uses to "hide" the device is elsewhere, or maybe python-evdev doesn't implement those bits of EVIOCGRAB correctly...
One thing that might help with this problem is to try changing the permissions of the original joystick device file after grabbing it in the application. Based on some experimenting, removing read access for that joystick device will ensure that applications that are launched later will skip over those devices; it will not affect applications that have already opened the joystick device. That way, a game will only see 1 joystick device as opposed to 2.
@Ryochan7 How do I figure out how to do that? Pretty sure I'm having this issue. DS4 works for Steam Big Picture but not in any game. Makes sense that maybe it's being mapped to a player 2 or some such.
You can try to remove the original device (when ds4drv is already running). E.g. if the original device is /dev/input/js0 then just do this:
sudo rm /dev/input/js0
The original device should return when you reconnect the controller.
That should work as well. For my SteamOS box, I have it set up where the steam user is the owner of all joystick devices. It is easier to perform chmod 000 <device> in that case as opposed to having to use sudo to remove the original device file.