[SOLVED] No force feedback in wine game from a Logitech Driving Force GT

ethoms · 05-13-2014, 08:25 PM

Hi, almost finished moving my main desktop machine at home to Slackware64 (14.1). The last thing I need to get working is my Logitech Driving Force GT (steering wheel game controller).

I only need it for one game, Richard Burns Rally, which runs well under wine. I am moving it from Kwheezy (Debian Stable) where the force feedback works OK. In Debian, the RBR force feedback settings is enable, acknowledging that it is detected. However, when I move the wine prefix to Slackware, the game works perfectly except the force feedback settings are disabled and the steering wheel is very loose. I don't need the force feedback effects to play the game, but the wheel needs to have some resistance, otherwise it's unplayable. I have also installed RBR again in a fresh wine prefix on Slackware, no difference.

The wine version on Debian is 1.4.1, whilst on Slackware64 it is 1.6.1. I wonder if this could be the difference in behaviour. I have tried to test it in Linux itself, this is the first logical step. However the fftest I downloaded from here: https://github.com/flosse/linuxconso...utils/fftest.c does not work in either Slackware or Debian.

Using Slackware huge kernel, the config files suggests CONFIG_LOGITECH_FF=y.

How can I test Force Feedback under Linux? Is there an additional driver/libraries needing installed for it to work?

cwizardone · 05-14-2014, 12:51 PM

I don't know if it will help, but have you tried a newer version of WINE?

http://taper.alienbase.nl/mirrors/pe...ne/pkg64/14.1/

ethoms · 05-15-2014, 02:13 AM

Thanks cwizardone, I will try that tonight maybe. The thing is that it works in wine version 1.4.1 on Debian. No harm in trying 1.7.x though. I was really hoping there was a way to test it in Linux natively, in case that is the problem.

Will post back with results of wine 1.7.x test.

jtsn · 05-15-2014, 06:28 AM

Interesting. Since when does WINE support force feedback via DirectInput? http://wiki.winehq.org/DInput states otherwise.

ethoms · 05-16-2014, 01:24 AM

Since WINE 1.5.9, there is a control panel for joysticks. In terminal type "wine control" and there is an icon for joysticks. On Slackware with WINE 1.6.1 the Driving Force GT shows up as a contoller but there's nothing in the Force Feedback section. Whereas on Debian, RBR game detects FF, so it definetely works. But there is no control panel for joysticks in WINE 1.4.1.

jtsn · 05-16-2014, 09:15 AM

Quote:

Originally Posted by ethoms

Whereas on Debian, RBR game detects FF, so it definetely works.

So Debian has a WINE fork that supports FFB?

ethoms · 05-17-2014, 02:23 AM

Just tried WINE 1.7.14 from alien bob's package, as suggested by cwizardone. No joy, still no FF in RBR or "wine control".

Quote:

So Debian has a WINE fork that supports FFB?

I'm not sure if Debian does that. I don't expect they care too much about wine. But I suppose it's possible. It's just as likely that the support is there at the linux level. Perhaps Slackware is missing some support for FF. That's why I would like to be able to test it within Linux natively.

ethoms · 05-17-2014, 03:36 AM

OK, big progress!

Basically it is not wine it is Slackwares' handling of input devices permissions.

Debian, which FF works looks like this:

Code:

# cat /proc/bus/input/devices

...
...

I: Bus=0003 Vendor=046d Product=c294 Version=0100
N: Name="Driving Force GT"
P: Phys=usb-0000:00:1a.0-1.2/input0
S: Sysfs=/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/input/input19
U: Uniq=
H: Handlers=event17 js0 
B: PROP=0
B: EV=20001b
B: KEY=fff00000000 0 0 0 0
B: ABS=30003
B: MSC=10
B: FF=300040000 0

# ls -l /dev/input
total 0
drwxr-xr-x  2 root root    260 May 17 15:50 by-id
drwxr-xr-x  2 root root    240 May 17 15:50 by-path
crw-------  1 root root 13, 64 May 17 15:50 event0
crw-------  1 root root 13, 65 May 17 15:50 event1
crw-------  1 root root 13, 74 May 17 15:49 event10
crw-------  1 root root 13, 75 May 17 15:49 event11
crw-------  1 root root 13, 76 May 17 15:49 event12
crw-------  1 root root 13, 77 May 17 15:49 event13
crw-------  1 root root 13, 78 May 17 15:49 event14
crw-------  1 root root 13, 79 May 17 15:49 event15
crw-------  1 root root 13, 80 May 17 15:49 event16
crw-rw----+ 1 root root 13, 81 May 17 15:50 event17
crw-------  1 root root 13, 66 May 17 15:49 event2
crw-------  1 root root 13, 67 May 17 15:49 event3
crw-------  1 root root 13, 68 May 17 15:49 event4
crw-------  1 root root 13, 69 May 17 15:49 event5
crw-------  1 root root 13, 70 May 17 15:49 event6
crw-------  1 root root 13, 71 May 17 15:49 event7
crw-------  1 root root 13, 72 May 17 15:49 event8
crw-------  1 root root 13, 73 May 17 15:49 event9
crw-rw-r-T+ 1 root root 13,  0 May 17 15:50 js0
crw-------  1 root root 13, 63 May 17 15:49 mice
crw-------  1 root root 13, 32 May 17 15:49 mouse0

Whereas Slackware, by default, looks like this:

Code:

# cat /proc/bus/input/devices

...
...

I: Bus=0003 Vendor=046d Product=c29a Version=0111
N: Name="Driving Force GT"
P: Phys=usb-0000:00:1a.0-1.2/input0
S: Sysfs=/devices/pci0000:00/0000:00:1a.0/usb5/5-1/5-1.2/5-1.2:1.0/input/input22
U: Uniq=
H: Handlers=event21 js0 
B: PROP=0
B: EV=20001b
B: KEY=1f 0 0 0 0 0 0 ffff00000000 0 0 0 0
B: ABS=30007
B: MSC=10
B: FF=300040000 0

# ls -l /dev/input/
total 0
drwxr-xr-x 2 root root    260 May 17 16:01 by-id/
drwxr-xr-x 2 root root    220 May 17 16:01 by-path/
crw-r----- 1 root root 13, 64 May 17 15:59 event0
crw-r----- 1 root root 13, 65 May 17 15:59 event1
crw-r----- 1 root root 13, 74 May 17 15:59 event10
crw-r----- 1 root root 13, 75 May 17 15:59 event11
crw-r----- 1 root root 13, 76 May 17 15:59 event12
crw-r----- 1 root root 13, 77 May 17 15:59 event13
crw-r----- 1 root root 13, 78 May 17 15:59 event14
crw-r----- 1 root root 13, 79 May 17 15:59 event15
crw-r----- 1 root root 13, 80 May 17 15:59 event16
crw-r----- 1 root root 13, 81 May 17 15:59 event17
crw-r----- 1 root root 13, 82 May 17 15:59 event18
crw-r----- 1 root root 13, 83 May 17 15:59 event19
crw-r----- 1 root root 13, 66 May 17 15:59 event2
crw-r----- 1 root root 13, 84 May 17 15:59 event20
crw-r----- 1 root root 13, 85 May 17 16:01 event21
crw-r----- 1 root root 13, 67 May 17 15:59 event3
crw-r----- 1 root root 13, 68 May 17 15:59 event4
crw-r----- 1 root root 13, 69 May 17 15:59 event5
crw-r----- 1 root root 13, 70 May 17 15:59 event6
crw-r----- 1 root root 13, 71 May 17 15:59 event7
crw-r----- 1 root root 13, 72 May 17 15:59 event8
crw-r----- 1 root root 13, 73 May 17 15:59 event9
crw-r--r-- 1 root root 13,  0 May 17 16:01 js0
crw-r----- 1 root root 13, 63 May 17 15:59 mice
crw-r----- 1 root root 13, 32 May 17 15:59 mouse0

As you can see, in Debian the FF handler is /dev/input/event17 and has permissions crw-rw----+. In Slackware the FF handler is /dev/input/event21 and has permissions crw-r-----.

So if I totally relax permissions on /dev/input/js0 and /dev/input/event21 as follows:

Code:

chmod a+rw /dev/input/js0
chmod a+rw /dev/input/event21

Then it works well! :-)

I got fftest working in doth distros by using "fftest /dev/input/eventXX" where XX is the event mentioned in /proc/bus/input/devices for my wheel. Interesting to note that only one effect was reported available in fftest, even on Debian. Also, slackware worked better on that test with a much stronger force feedback.

After the permissions change, RBR now detects and uses the FF for my wheel. I haven't played it yet, but it looks liek the FF is stronger, which would be great.

So, the question now is; what do I need to do to make the default perms for input devices using FF? What does Debian do to get the access rights correct for use by relevant software. The "+" sign indicates that ACLs are used, perhaps integrated into policykit or something similar.

Of course I could probably hack something so that the perms are right for gaming. But I think all Slackware users should be able to get their FF and other game controllers working out-the-box.

schmatzler · 05-17-2014, 05:18 AM

Bigger distributions like Ubuntu use a udev rule to set the permissions right. This also affects users of "Steam", see the issue and solution at the bottom of it here:

https://github.com/ValveSoftware/ste...ux/issues/2092

jtsn · 05-17-2014, 05:22 AM

Quote:

Originally Posted by schmatzler

Bigger distributions like Ubuntu use a udev rule to set the permissions right.

So the thread can be marked as solved with the conclusion that udev sucks as usual. Well, nothing surprising...

ethoms · 05-17-2014, 07:41 AM

SOLVED!

Thanks to schmatzler, I have been able to create a udev rules that works well for me. I just don't know if it is 100% correct. I guess it may not be the best security-wise. But it seems to be more or less what debian is doing.

The solution was to make a udev rules in the following file:

Code:

/etc/udev/rules.d/80-joystick-perm.rules

with the following content:

Code:

KERNEL=="event*", ENV{ID_INPUT_JOYSTICK}=="1", MODE:="0644", RUN+="/usr/bin/setfacl -m 'g:plugdev:rw' $env{DEVNAME}"

I'm asuming plugdev is an appropriate group to give write access to /dev/input/eventXX. Otherwise, one could create a new group called say "joystick" and add their users to that group, then change the udev accordingly.

Quote:

So the thread can be marked as solved with the conclusion that udev sucks as usual. Well, nothing surprising...

Maybe, I don't know enough about udev, though I've heard others say similar things about it. What I do know is that Debian made it work, and I don't see a udev rule for it in /etc/udev/rules.d. Perhaps they patched udev, that's the kind of thing they do.

Perhaps Slackware just needs to add a similar udev rule, so that others don't have to find my solution on linuxquestions. Maybe a slackbuilds package, called something like "joystick-force-feedback-udev" or "js-ff-udev", or put it in extra on the DVD.

jtsn · 05-17-2014, 09:23 AM

Quote:

Originally Posted by ethoms

Perhaps Slackware just needs to add a similar udev rule, so that others don't have to find my solution on linuxquestions. Maybe a slackbuilds package, called something like "joystick-force-feedback-udev" or "js-ff-udev", or put it in extra on the DVD.

I think it's actually the task of ConsoleKit to get this right, because making raw event input devices accessible to any logged in user without further consideration may open a security holes, which can be used for keyboard hijacking / keyloggers etc.