View previous topic :: View next topic |
Author |
Message |
wdsci Tux's lil' helper
Joined: 02 Oct 2007 Posts: 148 Location: US
|
Posted: Thu Jul 27, 2017 9:59 pm Post subject: Steam controller not recognized by Rocket League |
|
|
I'm trying to use a Steam controller in Rocket League, but the game doesn't seem to recognize the controller as a controller; it only recognizes it as a keyboard/mouse emulator. For example, when I push RT on the controller it triggers the game action I have bound to the left mouse button, and LT on the controller triggers the game action I have bound to the right mouse button, and I checked in xev to see that those buttons do produce the corresponding X events. All this happens only when I have the Steam overlay disabled for the game. If I have it enabled, the controller does nothing at all in RL.
The Steam launcher, though, does seem to recognize the controller as a controller. I push buttons and they do what the program says they do, and pushing the corresponding keyboard keys or mouse buttons doesn't. So whatever's going on, it doesn't seem to be caused by a hardware problem or lack of drivers. It definitely looks like something to do with Rocket League itself.
I've followed the instructions on the wiki. in particular I have Steam installed using anyc's overlay, I'm using ConsoleKit but not systemd and I do have the acl use flag set. I've verified that the udev rules for the Steam controller exist in /lib/udev/rules.d. I've also tried the manual configuration instructions, adding myself to the input group and logging out and back in (actually I restarted entirely) - this didn't change anything, of course, but I figured it couldn't hurt.
Any ideas about how I can fix this? I'm asking here rather than in Kernel & Hardware because, as I mentioned, it seems to be an issue with a particular game, not with detecting the controller at all. |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6051 Location: Removed by Neddy
|
Posted: Fri Jul 28, 2017 12:53 pm Post subject: |
|
|
I have just updated the wiki as the kernel info was wrong (it missed one level to find uinput)
what is the output of: grep $(stat -c "%G" /dev/uinput ) <(groups)
basically your user needs write permission to uinput and usually this is via the input group _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
wdsci Tux's lil' helper
Joined: 02 Oct 2007 Posts: 148 Location: US
|
Posted: Fri Jul 28, 2017 7:07 pm Post subject: |
|
|
Hm, maybe you're on to something. /dev/uinput is root:root and mode 0600. (The command you listed gives no output and returns with exit status 1.) Also getfacl shows no special access control rules when applied to /dev/uinput.
Do you have a suggested fix? I can definitely try changing permissions on /dev/uinput to see if it will work (later though), but in the long term I hope to make udev take care of this automatically. |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6051 Location: Removed by Neddy
|
Posted: Fri Jul 28, 2017 10:27 pm Post subject: |
|
|
Well add yourself to the input group and also copy the udev rule from the wiki link.
you should be fine then _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
wdsci Tux's lil' helper
Joined: 02 Oct 2007 Posts: 148 Location: US
|
Posted: Sat Jul 29, 2017 10:40 pm Post subject: |
|
|
The thing is, as I mentioned, I already have the udev rule installed. If it's supposed to be making /dev/uinput readable or writable for me, it's not doing that.
In any case, I manually changed permissions on /dev/uinput to 0666 and that does allow me to use the controller when I have the Steam overlay active. So I guess I just have to figure out why the udev rule isn't working as it should. |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6051 Location: Removed by Neddy
|
Posted: Sun Jul 30, 2017 12:10 am Post subject: |
|
|
could you paste the rule here. _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
wdsci Tux's lil' helper
Joined: 02 Oct 2007 Posts: 148 Location: US
|
Posted: Sun Jul 30, 2017 2:09 am Post subject: |
|
|
Sure, this is the contents of /lib/udev/rules.d/99-steam-controller-perms.rules:
Code: | # Valve USB devices
SUBSYSTEM=="usb", ATTRS{idVendor}=="28de", MODE="0666"
# Steam Controller udev write access
KERNEL=="uinput", SUBSYSTEM=="misc", TAG+="uaccess", TAG+="udev-acl"
# Valve HID devices over USB hidraw
KERNEL=="hidraw*", ATTRS{idVendor}=="28de", MODE="0666"
# Valve HID devices over bluetooth hidraw
KERNEL=="hidraw*", KERNELS=="*28DE:*", MODE="0666"
# DualShock 4 over USB hidraw
KERNEL=="hidraw*", ATTRS{idVendor}=="054c", ATTRS{idProduct}=="05c4", MODE="0666"
# DualShock 4 wireless adapter over USB hidraw
KERNEL=="hidraw*", ATTRS{idVendor}=="054c", ATTRS{idProduct}=="0ba0", MODE="0666"
# DualShock 4 Slim over USB hidraw
KERNEL=="hidraw*", ATTRS{idVendor}=="054c", ATTRS{idProduct}=="09cc", MODE="0666"
# DualShock 4 over bluetooth hidraw
KERNEL=="hidraw*", KERNELS=="*054C:05C4*", MODE="0666"
# DualShock 4 Slim over bluetooth hidraw
KERNEL=="hidraw*", KERNELS=="*054C:09CC*", MODE="0666" |
|
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6051 Location: Removed by Neddy
|
Posted: Sun Jul 30, 2017 2:13 am Post subject: |
|
|
Are you a systems user? _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
wdsci Tux's lil' helper
Joined: 02 Oct 2007 Posts: 148 Location: US
|
Posted: Sun Jul 30, 2017 2:23 am Post subject: |
|
|
If you meant systemd, no I am not, as I mentioned in the original post. |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6051 Location: Removed by Neddy
|
Posted: Sun Jul 30, 2017 8:50 am Post subject: |
|
|
Ahh sport missed that. The reason I ask is that rule file is for systemd so that is why the permissions are not being set.
Goto the wiki and copy-paste the non udev rule to /etc/udev/rules.d/... _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
BT Guru
Joined: 13 Jun 2004 Posts: 318
|
Posted: Sun Jul 30, 2017 2:03 pm Post subject: |
|
|
Naib wrote: | The reason I ask is that rule file is for systemd so that is why the permissions are not being set. |
The uinput rule posted by wdsci is used by systemd and ConsoleKit to automatically set an ACL entry for the logged-in user. systemd uses TAG+="uaccess" and ConsoleKit uses TAG+="udev-acl".
wdsci,
Can you post the output of:
Code: | $ getfacl /dev/uinput |
|
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6051 Location: Removed by Neddy
|
Posted: Sun Jul 30, 2017 2:23 pm Post subject: |
|
|
BT wrote: | Naib wrote: | The reason I ask is that rule file is for systemd so that is why the permissions are not being set. |
The uinput rule posted by wdsci is used by systemd and ConsoleKit to automatically set an ACL entry for the logged-in user. systemd uses TAG+="uaccess" and ConsoleKit uses TAG+="udev-acl".
wdsci,
Can you post the output of:
Code: | $ getfacl /dev/uinput |
|
he already checked that: Also getfacl shows no special access control rules when applied to /dev/uinput.
In theory consolekit should work with those rules but evidently it is not. falling back to classic acl will at least permit things to work. I suspect aspects of consolekit are not functioning or disabling creating the needed acl to this node _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
BT Guru
Joined: 13 Jun 2004 Posts: 318
|
Posted: Sun Jul 30, 2017 2:34 pm Post subject: |
|
|
Naib wrote: | he already checked that: Also getfacl shows no special access control rules when applied to /dev/uinput. |
Sorry I missed that.
The only other thing I can suggest is to ensure that ACL support is enabled in the kernel. |
|
Back to top |
|
|
wdsci Tux's lil' helper
Joined: 02 Oct 2007 Posts: 148 Location: US
|
Posted: Mon Jul 31, 2017 4:32 am Post subject: |
|
|
Thanks all - no proper solution yet unfortunately.
When I went looking in /etc/udev/rules.d, I found an old udev rules file with a rule for /dev/uinput that I must have added a long time ago to handle my Roccat mouse. But removing that rule has no effect. The permissions on /dev/uinput are still set to 0600 with root:root ownership and no ACL modifications.
I verified that ACL support is enabled in the kernel for all filesystems I use (and a bunch that I don't) - though /dev is not one of these, of course, and I'm not sure if there's a separate setting to enable/disable ACLs on /dev
Code: | $ grep ACL /usr/src/linux/.config
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_REISERFS_FS_POSIX_ACL=y
CONFIG_JFS_POSIX_ACL=y
CONFIG_XFS_POSIX_ACL=y
CONFIG_BTRFS_FS_POSIX_ACL=y
CONFIG_FS_POSIX_ACL=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_HFSPLUS_FS_POSIX_ACL=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_ACL_SUPPORT=m
CONFIG_CIFS_ACL=y |
and that consolekit is compiled with the acl USE flag:
Code: | $ emerge -pv consolekit
[ebuild R ] sys-auth/consolekit-1.1.2 USE="acl pam (policykit) udev -cgroups -debug -doc -evdev -pm-utils (-selinux) {-test}" |
I also ran a test to ensure that I can manually set an ACL entry on /dev/uinput
Code: | # setfacl -m u:diazona:rw /dev/uinput
acetylene09 linux # getfacl /dev/uinput
getfacl: Removing leading '/' from absolute path names
# file: dev/uinput
# owner: root
# group: root
user::rw-
user:diazona:rw-
group::---
mask::rw-
other::--- |
(diazona is my local username) Although I did notice that something is altering the ACL: right after running the above I tried launching Rocket League again, the controller still didn't work, so I immediately exited the game and found that the output had changed to this:
Code: | # getfacl /dev/uinput
getfacl: Removing leading '/' from absolute path names
# file: dev/uinput
# owner: root
# group: root
user::rw-
user:diazona:rw- #effective:---
group::---
mask::---
other::--- |
FWIW I set the mask again using setfacl and the second time, it stuck - I was able to start up Rocket League and use the controller.
I'll continue to investigate this. |
|
Back to top |
|
|
slim1 n00b
Joined: 02 Aug 2017 Posts: 2
|
Posted: Wed Aug 02, 2017 2:16 pm Post subject: |
|
|
Same. Decided to get a Steam controller after hearing some off-handed rantings about it's glory. Looking for anyone with any insight as to best setup for RL.
[url]https://android.googlesource.com/platform/system/core/+/4b29fe6%5E!/[/url] |
|
Back to top |
|
|
wdsci Tux's lil' helper
Joined: 02 Oct 2007 Posts: 148 Location: US
|
Posted: Wed Aug 02, 2017 5:43 pm Post subject: |
|
|
slim1 wrote: | Same. Decided to get a Steam controller after hearing some off-handed rantings about it's glory. Looking for anyone with any insight as to best setup for RL.
[url]https://android.googlesource.com/platform/system/core/+/4b29fe6%5E!/[/url] |
You might want to start a new topic for that, as that's not related to the technical problem being discussed here. (And actually, that would be better placed at the Steam community or the RL forums, since it's not related to Gentoo.)
As far as the problem I've been having, I've continued to use the command
Code: | setfacl -m u:diazona:rw /dev/uinput |
and it seems to be working - I can use the controller while having the Steam overlay active in-game without any trouble. It will probably be a while before I get to figure out how to make this process automatic with udev, though. |
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6051 Location: Removed by Neddy
|
Posted: Wed Aug 02, 2017 6:48 pm Post subject: |
|
|
wdsci wrote: | slim1 wrote: | Same. Decided to get a Steam controller after hearing some off-handed rantings about it's glory. Looking for anyone with any insight as to best setup for RL.
[url]https://android.googlesource.com/platform/system/core/+/4b29fe6%5E!/[/url] |
You might want to start a new topic for that, as that's not related to the technical problem being discussed here. (And actually, that would be better placed at the Steam community or the RL forums, since it's not related to Gentoo.)
As far as the problem I've been having, I've continued to use the command
Code: | setfacl -m u:diazona:rw /dev/uinput |
and it seems to be working - I can use the controller while having the Steam overlay active in-game without any trouble. It will probably be a while before I get to figure out how to make this process automatic with udev, though. | what is the output of /etc/init.d/consolekit status _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
wdsci Tux's lil' helper
Joined: 02 Oct 2007 Posts: 148 Location: US
|
Posted: Thu Aug 03, 2017 3:08 am Post subject: |
|
|
Code: | $ /etc/init.d/consolekit status
* status: started |
|
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6051 Location: Removed by Neddy
|
Posted: Sat Aug 05, 2017 2:06 pm Post subject: |
|
|
do you have any evidence that consolekit is working? ie other files/nodes given acl permissions via consolekit?
What is know
1) uinput is being created
2) uinput has default permissions
3) to make use of uinput as a non-root user, appropriate access is needed
4) consolekit is running
5) appropriate udev rule exists
HOWEVER... /dev/uinput acl is not being modified
so ... either user session of consolekit isn't active (and thus when you login it isn't doing what it needs to) or consolekit is broken
first of all... could you, as stated... try the non-consolekit udev rule to ensure everything is functioning
then have you checked the consolekit wiki: https://wiki.gentoo.org/wiki/ConsoleKit
Have you also confirmed consolekit is functioning, say ... create dummy rule
Finally ... do you need consolekit? it is a multiseat acl modifier _________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
BT Guru
Joined: 13 Jun 2004 Posts: 318
|
Posted: Mon Aug 07, 2017 5:21 am Post subject: |
|
|
wdsci,
Can you also post the output of:
|
|
Back to top |
|
|
wdsci Tux's lil' helper
Joined: 02 Oct 2007 Posts: 148 Location: US
|
Posted: Mon Aug 07, 2017 10:21 pm Post subject: |
|
|
OK, I have put the non-ConsoleKit udev rule in /etc/udev/rules.d and rebooted, and it's not making any difference; /dev/uinput still has 0600 permissions and no extra ACL entries.
I checked the wiki page for ConsoleKit and the only thing of interest I find is that the kernel option "Enable system-call auditing support", which the wiki page says is required, doesn't appear in my kernel config (version 4.11.7). I'm not sure if that's relevant or if the option just dates back to an earlier kernel.
I don't know how to create a dummy rule in CK, and I can't seem to find any documentation for it. (Or did you mean a udev rule? Still, I don't know the syntax, but that one I could look up.)
And... do I need ConsoleKit? Not directly, but it is pulled in by some KDE packages.
Code: | $ equery depends consolekit
* These packages depend on consolekit:
kde-plasma/powerdevil-5.10.3 (consolekit ? >=sys-auth/consolekit-1.0.1)
net-misc/networkmanager-1.8.0 (consolekit ? >=sys-auth/consolekit-1.0.0)
sys-apps/accountsservice-0.6.43-r1 (!elogind ? sys-auth/consolekit)
sys-auth/pambase-20150213-r1 (consolekit ? sys-auth/consolekit[pam])
sys-auth/polkit-0.113-r3 (!elogind ? sys-auth/consolekit[policykit])
x11-misc/sddm-0.14.0-r3 (consolekit ? >=sys-auth/consolekit-0.9.4) |
I could try re-emerging with USE="-consolekit elogind" and see if everything still works.
This is the output of ck-list-sessions:
Code: | $ ck-list-sessions
Session1:
unix-user = '1000'
realname = '<my name>'
seat = 'Seat1'
session-type = 'unspecified'
session-class = 'user'
session-state = 'active'
active = TRUE
x11-display = ':0'
x11-display-device = '/dev/tty7'
display-device = ''
remote-host-name = ''
is-local = TRUE
on-since = '2017-08-07T22:00:57.595062Z'
login-session-id = '3'
XDG_RUNTIME_DIR = '/var/run/user/1000'
VTNr = '7' |
|
|
Back to top |
|
|
Naib Watchman
Joined: 21 May 2004 Posts: 6051 Location: Removed by Neddy
|
Posted: Mon Aug 07, 2017 10:37 pm Post subject: |
|
|
Quote: | OK, I have put the non-ConsoleKit udev rule in /etc/udev/rules.d and rebooted, and it's not making any difference; /dev/uinput still has 0600 permissions and no extra ACL entries. |
that is pointing towards an issue with udev.
once you "reboot" such that uinput is 0600 could you execute udevadm control --reload-rules and then check the /dev node.
just to confirm. This is my non-consolekit rule
Code: |
cat /etc/udev/rules.d/99-steam-controller-perms.rules
# Valve USB devices
SUBSYSTEM=="usb", ATTRS{idVendor}=="28de", MODE="0666"
# Steam Controller udev write access
KERNEL=="uinput", SUBSYSTEM=="misc", MODE="0660", GROUP="input"
# Valve HID devices over USB hidraw
KERNEL=="hidraw*", ATTRS{idVendor}=="28de", MODE="0666"
# Valve HID devices over bluetooth hidraw
KERNEL=="hidraw*", KERNELS=="*28DE:*", MODE="0666"
|
equally
Code: |
stat /dev/uinput
File: /dev/uinput
Size: 0 Blocks: 0 IO Block: 4096 character special file
Device: 6h/6d Inode: 3098 Links: 1 Device type: a,df
Access: (0660/crw-rw----) Uid: ( 0/ root) Gid: ( 97/ input)
Access: 2017-08-07 18:22:27.968406272 +0100
Modify: 2017-08-07 18:22:27.968406272 +0100
Change: 2017-08-07 18:22:27.968406272 +0100
Birth: -
|
_________________
Quote: | Removed by Chiitoo |
|
|
Back to top |
|
|
wdsci Tux's lil' helper
Joined: 02 Oct 2007 Posts: 148 Location: US
|
Posted: Mon Aug 07, 2017 10:45 pm Post subject: |
|
|
Sure, after that recent reboot I've executed udevadm control --reload-rules, but there is no change in the status of /dev/uinput.
Code: | $ stat /dev/uinput
File: /dev/uinput
Size: 0 Blocks: 0 IO Block: 4096 character special file
Device: 6h/6d Inode: 3289 Links: 1 Device type: a,df
Access: (0600/crw-------) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2017-08-07 14:00:41.894053918 -0400
Modify: 2017-08-07 14:00:41.894053918 -0400
Change: 2017-08-07 14:00:41.895053951 -0400
Birth: - |
No change in the output of getfacl /dev/uinput either.
Here is what I have in /etc/udev/rules.d/99-manual-steam-controller.rules:
Code: | $ cat /etc/udev/rules.d/99-manual-steam-controller.rules
# ConsoleKit rules
# Valve USB devices
#SUBSYSTEM=="usb", ATTRS{idVendor}=="28de", MODE="0666"
# Steam Controller udev write access
#KERNEL=="uinput", SUBSYSTEM=="misc", TAG+="uaccess", TAG+="udev-acl"
# Valve HID devices over USB hidraw
#KERNEL=="hidraw*", ATTRS{idVendor}=="28de", MODE="0666"
# Valve HID devices over bluetooth hidraw
#KERNEL=="hidraw*", KERNELS=="*28DE:*", MODE="0666"
# Non-ConsoleKit rules
# Valve USB devices
SUBSYSTEM=="usb", ATTRS{idVendor}=="28de", MODE="0666"
# Steam Controller udev write access
KERNEL=="uinput", SUBSYSTEM=="misc", MODE="0660", GROUP="input"
# Valve HID devices over USB hidraw
KERNEL=="hidraw*", ATTRS{idVendor}=="28de", MODE="0666"
# Valve HID devices over bluetooth hidraw
KERNEL=="hidraw*", KERNELS=="*28DE:*", MODE="0666" |
The ConsoleKit rules at the top are commented out. The uncommented lines seem to match yours exactly. |
|
Back to top |
|
|
BT Guru
Joined: 13 Jun 2004 Posts: 318
|
Posted: Tue Aug 08, 2017 1:21 am Post subject: |
|
|
Can you post the output of:
Code: | # udevadm test -a add /devices/virtual/misc/uinput |
I get the following with the non-ConsoleKit rule:
Code: | ...
Reading rules file: /etc/udev/rules.d/99-steam-controller-perms.rules
rules contain 196608 bytes tokens (16384 * 12 bytes), 20292 bytes strings
8761 strings (75344 bytes), 6984 de-duplicated (56830 bytes), 1778 trie nodes used
GROUP 249 /etc/udev/rules.d/99-steam-controller-perms.rules:5
MODE 0660 /etc/udev/rules.d/99-steam-controller-perms.rules:5
handling device node '/dev/uinput', devnum=c10:223, mode=0660, uid=0, gid=249
preserve permissions /dev/uinput, 020660, uid=0, gid=249
preserve already existing symlink '/dev/char/10:223' to '../uinput'
created empty file '/run/udev/data/c10:223' for '/devices/virtual/misc/uinput'
ACTION=add
DEVNAME=/dev/uinput
DEVPATH=/devices/virtual/misc/uinput
MAJOR=10
MINOR=223
SUBSYSTEM=misc
|
This shows that the uinput gid is set to 249 (input), and the mode is set to 0660. |
|
Back to top |
|
|
wdsci Tux's lil' helper
Joined: 02 Oct 2007 Posts: 148 Location: US
|
Posted: Tue Aug 08, 2017 3:09 am Post subject: |
|
|
Interesting. I get something quite different:
Code: | # udevadm test -a add /devices/virtual/misc/uinput
Password:
calling: test
version 233
This program is for debugging only, it does not run any program
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.
=== trie on-disk ===
tool version: 233
file size: 7336753 bytes
header size 80 bytes
strings 1879121 bytes
nodes 5457552 bytes
Load module index
Found container virtualization none.
timestamp of '/etc/systemd/network' changed
timestamp of '/lib/systemd/network' changed
Parsed configuration file /lib64/systemd/network/99-default.link
Created link configuration context.
timestamp of '/etc/udev/rules.d' changed
timestamp of '/run/udev/rules.d' changed
timestamp of '/lib/udev/rules.d' changed
Reading rules file: /lib64/udev/rules.d/10-virtualbox.rules
Reading rules file: /lib64/udev/rules.d/40-gentoo.rules
Reading rules file: /lib64/udev/rules.d/40-usb-media-players.rules
Reading rules file: /lib64/udev/rules.d/41-libsane.rules
Reading rules file: /lib64/udev/rules.d/50-udev-default.rules
Reading rules file: /lib64/udev/rules.d/60-HTC-Vive-perms.rules
Reading rules file: /lib64/udev/rules.d/60-block.rules
Reading rules file: /lib64/udev/rules.d/60-cdrom_id.rules
Reading rules file: /lib64/udev/rules.d/60-drm.rules
Reading rules file: /lib64/udev/rules.d/60-evdev.rules
Reading rules file: /lib64/udev/rules.d/60-persistent-alsa.rules
Reading rules file: /lib64/udev/rules.d/60-persistent-input.rules
Reading rules file: /lib64/udev/rules.d/60-persistent-storage-tape.rules
Reading rules file: /lib64/udev/rules.d/60-persistent-storage.rules
Reading rules file: /lib64/udev/rules.d/60-persistent-v4l.rules
Reading rules file: /lib64/udev/rules.d/60-sensor.rules
Reading rules file: /lib64/udev/rules.d/60-serial.rules
Reading rules file: /run/udev/rules.d/61-dev-root-link.rules
Reading rules file: /lib64/udev/rules.d/61-kde-bluetooth-rfkill.rules
Reading rules file: /lib64/udev/rules.d/62-nut-usbups.rules
Reading rules file: /lib64/udev/rules.d/64-btrfs.rules
Reading rules file: /lib64/udev/rules.d/70-mouse.rules
Reading rules file: /lib64/udev/rules.d/70-touchpad.rules
Reading rules file: /lib64/udev/rules.d/70-udev-acl.rules
Reading rules file: /lib64/udev/rules.d/71-udev-seat.rules
Reading rules file: /lib64/udev/rules.d/75-net-description.rules
Reading rules file: /lib64/udev/rules.d/75-probe_mtd.rules
Reading rules file: /lib64/udev/rules.d/78-sound-card.rules
Reading rules file: /lib64/udev/rules.d/80-drivers.rules
Reading rules file: /lib64/udev/rules.d/80-libinput-device-groups.rules
Reading rules file: /lib64/udev/rules.d/80-net-setup-link.rules
Reading rules file: /lib64/udev/rules.d/80-udisks2.rules
Reading rules file: /lib64/udev/rules.d/84-nm-drivers.rules
Reading rules file: /lib64/udev/rules.d/85-nm-unmanaged.rules
Reading rules file: /lib64/udev/rules.d/90-alsa-restore.rules
Reading rules file: /lib64/udev/rules.d/90-libinput-model-quirks.rules
Reading rules file: /lib64/udev/rules.d/90-network.rules
Reading rules file: /lib64/udev/rules.d/90-pulseaudio.rules
Reading rules file: /lib64/udev/rules.d/95-upower-csr.rules
Reading rules file: /lib64/udev/rules.d/95-upower-hid.rules
Reading rules file: /lib64/udev/rules.d/95-upower-wup.rules
Reading rules file: /lib64/udev/rules.d/99-fuse.rules
Reading rules file: /etc/udev/rules.d/99-manual-steam-controller.rules
Reading rules file: /lib64/udev/rules.d/99-ntfs3g.rules
Reading rules file: /lib64/udev/rules.d/99-steam-controller-perms.rules
rules contain 196608 bytes tokens (16384 * 12 bytes), 19537 bytes strings
9212 strings (78217 bytes), 7425 de-duplicated (60468 bytes), 1788 trie nodes used
unable to open device '/sys/devices/virtual/misc/uinput'
Unload module index
Unloaded link configuration context. |
Some searching led me to https://bbs.archlinux.org/viewtopic.php?id=104348 which mentions loading the uinput module, and indeed when I checked the output of lsmod, uinput was not among the loaded modules (even though it is a separate module, not compiled into my kernel). I can run modprobe uinput, which does successfully load the uinput module, and once I do that, it seems that the permissions are taking effect:
Code: | # modprobe uinput
# ls -l /dev/uinput
crw-rw---- 1 root input 10, 223 Aug 7 23:03 /dev/uinput
# udevadm test -a add /devices/virtual/misc/uinput
...
Reading rules file: /etc/udev/rules.d/99-manual-steam-controller.rules
Reading rules file: /lib64/udev/rules.d/99-ntfs3g.rules
Reading rules file: /lib64/udev/rules.d/99-steam-controller-perms.rules
rules contain 196608 bytes tokens (16384 * 12 bytes), 19537 bytes strings
9212 strings (78217 bytes), 7425 de-duplicated (60468 bytes), 1788 trie nodes used
GROUP 249 /etc/udev/rules.d/99-manual-steam-controller.rules:21
MODE 0660 /etc/udev/rules.d/99-manual-steam-controller.rules:21
handling device node '/dev/uinput', devnum=c10:223, mode=0660, uid=0, gid=249
preserve permissions /dev/uinput, 020660, uid=0, gid=249
preserve already existing symlink '/dev/char/10:223' to '../uinput'
created db file '/run/udev/data/c10:223' for '/devices/virtual/misc/uinput'
ACTION=add
DEVNAME=/dev/uinput
DEVPATH=/devices/virtual/misc/uinput
MAJOR=10
MINOR=223
SUBSYSTEM=misc
TAGS=:uaccess:udev-acl:
USEC_INITIALIZED=18142626665
Unload module index
Unloaded link configuration context. |
So maybe the solution is as simple as loading the kernel module. (But then what was creating /dev/uinput before? If it's udev, why doesn't udev seem to handle the permissions?) I'll have to test this a bit more to see if it really works. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|