LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 05-13-2014, 08:25 PM   #1
ethoms
Member
 
Registered: Nov 2011
Posts: 113

Rep: Reputation: Disabled
No force feedback in wine game from a Logitech Driving Force GT


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?

Last edited by ethoms; 05-13-2014 at 08:28 PM.
 
Old 05-14-2014, 12:51 PM   #2
cwizardone
Senior Member
 
Registered: Feb 2007
Distribution: Slackware64-current with "True Multilib" & Xfce.
Posts: 4,908
Blog Entries: 1

Rep: Reputation: 2316Reputation: 2316Reputation: 2316Reputation: 2316Reputation: 2316Reputation: 2316Reputation: 2316Reputation: 2316Reputation: 2316Reputation: 2316Reputation: 2316
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/
 
Old 05-15-2014, 02:13 AM   #3
ethoms
Member
 
Registered: Nov 2011
Posts: 113

Original Poster
Rep: Reputation: Disabled
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.
 
Old 05-15-2014, 06:28 AM   #4
jtsn
Member
 
Registered: Sep 2011
Posts: 922

Rep: Reputation: 477Reputation: 477Reputation: 477Reputation: 477Reputation: 477
Interesting. Since when does WINE support force feedback via DirectInput? http://wiki.winehq.org/DInput states otherwise.
 
2 members found this post helpful.
Old 05-16-2014, 01:24 AM   #5
ethoms
Member
 
Registered: Nov 2011
Posts: 113

Original Poster
Rep: Reputation: Disabled
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.

Last edited by ethoms; 05-16-2014 at 01:26 AM.
 
Old 05-16-2014, 09:15 AM   #6
jtsn
Member
 
Registered: Sep 2011
Posts: 922

Rep: Reputation: 477Reputation: 477Reputation: 477Reputation: 477Reputation: 477
Quote:
Originally Posted by ethoms View Post
Whereas on Debian, RBR game detects FF, so it definetely works.
So Debian has a WINE fork that supports FFB?
 
Old 05-17-2014, 02:23 AM   #7
ethoms
Member
 
Registered: Nov 2011
Posts: 113

Original Poster
Rep: Reputation: Disabled
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.
 
Old 05-17-2014, 03:36 AM   #8
ethoms
Member
 
Registered: Nov 2011
Posts: 113

Original Poster
Rep: Reputation: Disabled
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.

Last edited by ethoms; 05-17-2014 at 03:38 AM.
 
Old 05-17-2014, 05:18 AM   #9
schmatzler
Member
 
Registered: Jan 2011
Location: Germany
Distribution: Slackware64 -current + Multilib
Posts: 405

Rep: Reputation: 178Reputation: 178
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
 
Old 05-17-2014, 05:22 AM   #10
jtsn
Member
 
Registered: Sep 2011
Posts: 922

Rep: Reputation: 477Reputation: 477Reputation: 477Reputation: 477Reputation: 477
Quote:
Originally Posted by schmatzler View Post
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...
 
Old 05-17-2014, 07:41 AM   #11
ethoms
Member
 
Registered: Nov 2011
Posts: 113

Original Poster
Rep: Reputation: Disabled
Smile

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.
 
Old 05-17-2014, 09:23 AM   #12
jtsn
Member
 
Registered: Sep 2011
Posts: 922

Rep: Reputation: 477Reputation: 477Reputation: 477Reputation: 477Reputation: 477
Quote:
Originally Posted by ethoms View Post
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.

Last edited by jtsn; 05-17-2014 at 09:28 AM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Logitech MOMO force feedback bartvaes Linux - Newbie 0 09-08-2012 05:18 AM
[SOLVED] Logitech Driving Force GT (DFGT) calibration with LTWheelConf TheIndependentAquarius Programming 1 01-05-2012 05:47 AM
[SOLVED] Linux drivers for Logitech Driving Force GT TheIndependentAquarius Linux - Software 7 11-25-2011 05:09 AM
Help get G25 + Driving Force Pro support into Linux Rich43 Programming 0 03-19-2008 04:14 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 09:30 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration