Maybe the proper way for your setup, is to put a custom rule for your device. Can use "udevadm info" to get information about the device, then write the proper rule in /etc/udev/rules.d. See the wiki: http://wiki.archlinux.org/index.php/Udev

This isn't about my device, this is about force feedback devices in general. These days most gamepads you buy have force feedback and many are supported under linux. Until now there wasn't really a way to access them, but with SDL 1.3 coming into play apps will be able to make use of force feedback devices. Without having write permissions by the user to the devices, force feedback won't be available making the user assume it's not supported under linux. I don't think that having everyone with a gamepad with force feedback to have to write custom udev rules to work around this is a solution.

any decision about this? I guess this is a bit dificult to solve without some force feedback info for udev rules. (like idVendor and idProduct)

The approach I saw on Fedora core was to just give 660 access to all the joysticks in /dev/input/event*. I don't think this would pose a problem since on gamepads without force feedback they'll just ignore writes and one with will allow them. Might be worth filing a bug upstream to try to get udev rules for force feedback, but not sure that's entirely necessary.

Do you have the rule from fedora, we could add this eventually to arch rules file.

AFAIK it was a simple:

KERNEL=="event[0-9]*", ENV{ID_CLASS}=="joystick", MODE="0666"

However you might prefer to have it 0664 and be root:games or the likes.

I think that this is already managed by udev-acl rule @ 70-acl.rules (via consolekit). So login via console or X session manager, should be authorized, with an acl rule.

# joysticks
SUBSYSTEM=="input", ENV{ID_INPUT_JOYSTICK}=="?*", ENV{ACL_MANAGE}="1"

What do you mean by that? I'm not familiar with ACL. However checking permissions show that by default it's still 640 root:root. It seems like I don't have the 70-acl.rules in /etc/udev/rules.d either.

OK, some tips:

Doing a "ls -l /dev/input/eventN" will show a "+" like this: "crw-r-----+ 1 root root XX, YY mmm DD HH:MM /dev/input/eventN". Only if your device is matched by this udev rule, consolekit installed and any of these conditions are true:

1) Logged in via console and in "/etc/pam.d/login" there is a line like "session optional pam_ck_connector.so"
2) Launch X with "startx" and in your .xinitrc your desktop is started by "exec ck-launch-session <your-wm/dm>"
3) Logged in X via X session manager like GDM.


Note: Udev system rules are in /lib/udev/rules.d
What is the output of udevadm info -q property -n /dev/input/eventN ?

OK, wasn't doing any of those three, but now I see it as crw-rw---+ root:root.

udevadm info -q property -n /dev/input/event8 gives:

UDEV_LOG=0
DEVPATH=/devices/pci0000:00/0000:00:1e.0/0000:05:01.0/usb9/9-2/9-2:1.0/input/input9/event8
MAJOR=13
MINOR=72
DEVNAME=/dev/input/event8
SUBSYSTEM=input
ID_INPUT=1
ID_INPUT_JOYSTICK=1
ID_VENDOR=Logitech
ID_VENDOR_ENC=Logitech
ID_VENDOR_ID=046d
ID_MODEL=Logitech_RumblePad_2_USB
ID_MODEL_ENC=Logitech\x20RumblePad\x202\x20USB
ID_MODEL_ID=c218
ID_REVISION=0100
ID_SERIAL=Logitech_Logitech_RumblePad_2_USB
ID_TYPE=hid
ID_BUS=usb
ID_USB_INTERFACES=:030000:
ID_USB_INTERFACE_NUM=00
ID_USB_DRIVER=usbhid
ID_PATH=pci-0000:05:01.0-usb-0:2:1.0
ACL_MANAGE=1
DEVLINKS=/dev/char/13:72 /dev/input/by-id/usb-Logitech_Logitech_RumblePad_2_USB-event-joystick /dev/input/by-path/pci-0000:05:01.0-usb-0:2:1.0-event-joystick


EDIT: Confirmed to work now, would be nice if by default it would work, although I assume most people use [GKX]DM which you mentioned does this out of the box.

Good. I guess this can be considered fixed. ACL is the method provided by upstream, not only for joysticks, also for other devices that there are no specific rules based on groups. Addiding the group "joystick" requires modification in "filesystem" package.

Devs decided...

What about adding:

session optional pam_ck_connector.so

to /etc/pam.d/login by default? Thinking about users like me that don't use [GKX]DM, although we're probably minority...

That is another history, by default no (consolekit is in [extra], shadow is in [core]). Maybe commented as an optional feature. In this case should open another feature request. But maybe an entry in the wiki is sufficient ;)

OK, both would sound good (commented and in wiki). I'll open a feature request, this bug can be closed then.

As for that games group: membership isn't what it was designed for. The idea of the games group was to have setgid game executables to allow write access to hiscore files.