udev rules not changing permissions for /dev/uinput

[ignacio-vc]

Hello, I'd just like to report a small oddity I found when trying out version 0.5.1 (I'm not sure if it happened before, as it's my first time using ds4drv)

See #94 for the following part. I split this to a separate issue. -@Ape /etc/ds4drv.conf doesn't exist in my system after installation (by default). Despite me having my own config file at ~/.config/ds4drv.conf , it isn't immediately picked up by the program when it is ran. I'm not sure if this happens because it looks first for the /etc/ one and when it doesn't find it it stops looking, or if it's something wrong on my end.

The simple fix is that I have to run sudo ds4drv --hidraw --config ~/.config/ds4drv.conf and then it works. (I spent about an hour figuring out what was wrong with my config and why it wasn't picking up my toggles, turns out it was just a matter of directing the program to the supposed-to-be-default .conf file, haha)

Also, that's another minor thing: despite me following the guide on Permissions in the ReadMe, I still have to apply sudo to the command , otherwise I get the "Failed to create input device: "/dev/uinput" cannot be opened for writing" message. I don't know if this is normal or if, again, it's something on my end.

I tried version 0.5.1 because the stable release wasn't working on Debian Testing (probably due to the python-evdev thing)

Cheers, and thanks for the driver guys it's really cool work you're doing

[Ape]

It should definitely look for ~/.config/ds4drv.conf first, and only after see if /etc/ds4drv.conf exists. Can you debug this further by seeing how the program actually runs step by step.

Please provide the output for these commands:

$ lsmod | grep uinput
$ ls /dev/uinput

[ignacio-vc]

Sure thing

ignacio@IgnacioPC:~$ lsmod | grep uinput
uinput                 20480  1
ignacio@IgnacioPC:~$ ls /dev/uinput 
/dev/uinput

[Ape]

What about this:

ls -al /dev/uinput

[ignacio-vc]

ignacio@IgnacioPC:~$ ls -al /dev/uinput 
crw------- 1 root root 10, 223 Jul 15 11:46 /dev/uinput

[Ape]

Seems like the udev rule doesn't kick in at all. I don't really know why that happens. Recheck that you followed the "Permissions" in the README.

[ignacio-vc]

I can confirm I copied the udev rules file to /etc/udev/rules.d and reloaded my udev rules, like it says in the README.

If it helps, here are its permissions

ignacio@IgnacioPC:~$ ls -al /etc/udev/rules.d/
total 16
drwxr-xr-x 2 root root 4096 Jul 14 20:35 .
drwxr-xr-x 4 root root 4096 Jul 13 22:40 ..
-rw-r--r-- 1 root root  216 Jul 14 20:35 50-ds4drv.rules
-rw-r--r-- 1 root root  634 Apr  7 18:59 70-persistent-net.rules

and the content of 50-ds4drv.rules is

KERNEL=="uinput", MODE="0666"
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="054c", ATTRS{idProduct}=="05c4", MODE="0666"
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", KERNELS=="0005:054C:05C4.*", MODE="0666"

[Ape]

Hmm.. That should change the permissions. You can try to run sudo chmod 0666 /dev/uinput manually, but I guess that is not really a solution.

[Ape]

I split this issue into two parts, see #94. I left the udev part here since it's discussed more.

[parkerlreed]

Same issue on Arch Linux for me. I have the udev file in the correct place but the uinput permissions never change.

EDIT: I also tried this line and it didn't work either https://github.com/tuomasjjrasanen/python-uinput/blob/master/udev-rules/40-uinput.rules

SUBSYSTEM=="misc", KERNEL=="uinput", MODE="0660", GROUP="uinput"

EDIT2: WEIRRRD I think I figured it out. Somehow on boot there is a /dev/uinput that is created BUT uinput kernel module isn't loaded. Modprobing uinput then gives it the correct permissions.

Creating /etc/modules-load.d/uinput.conf with the contents of

uinput

makes it work correctly on a fresh boot.