Linux force feedback wheel support

[jdeneux]

jdeneux, I haven't yet created a gain setting for the force-feedback. You could also try turning on stop-and-start to see if that gives you better results. What kind of joystick were you trying to use? Does it work in jstest, jscal, jscalibrator, etc.?

After further investigation, it turns out that it works sometimes with jstest and friends. There is something deeply wrong with the driver, it seems. I will try kernel 2.6.20, with some luck these problems are already fixed.

[thelusiv]

jdeneux, I've been wondering this, maybe you can help me figure it out. Is there a way I can use the joystick device or SDL to figure out which event device is a force feedback device belonging to which joystick device?

[jdeneux]

thelusiv, I looked into this a long time ago when I wanted to integrate FF into the SDL, or at least make my FF code collaborate with SDL.
SDL can use /dev/input/jsX or /dev/input/eventX depending on how it's compiled. If it uses the second method, then extending the SDL_Joystick (or whatever it's called) to support FF would be easy.

I don't know of any non-intrusive method to do what you are trying to do. I think maybe you could use the name of the device (you can retrieve that with SDL, see the joystick test app in SDL's source code).
Then I think maybe you can also retrieve the name of the joystick through /dev/input/eventX. Then it's just a matter of iterating over the files in /dev/input/eventX and looking for a name match.

That method is not perfect, I don't think one should assume event devices are named /dev/input/eventX. Another problem is that it does not work if you have two devices with the same name (e.g. two "anonymous" devices, or two identical devices).

[stenyak]

I suggest you subscribe to the SDL mailing list (maybe there's one for developers, dunno), and ask for some more info there

[Kada]

Hello,
it's good to hear, that someone is currently working on native FF support in Linux. Stenyak pointed me to this discussion from the Live for Speed forum, thank you for that.

First of all, I have a basic question, which version of ff-utils do you use for testing? Is somewhere newer version than this one?

My problem with Logitech wheels under linux was, that not all axes were recognized and that the kernel set huge deadzones for the axes. I wrote a little "hack" (I wouldn't call it patch :-)) for 2.6.20, in hid-lgff.c, that adds all axes and removes deadzones.

The problem is, that the logitech wheels, that I've tested (WFF GP, red momo) doesn't report usbhid (field->usage) in standard way, as a standard hid axis. There are 4 axis: wheel, combined gas-brake, gas axis and brake axis. But only 2 are correctly reported (wheel and combined, with deadzones) and thus recognized by the hid driver. Maybe this is the problem for non-working clutch in G25 wheel as Stenyak posted on the lfsforum. (non-axis hid "usage" field reported, for the clutch)

I added usb ids for Logitech WFF GP in hid-lgff.c and hid-ff.c, but I did't get any force by "fftest". That is why I'm asking, if there is not some other newer version of ff-utils.

[thelusiv]

Welcome, Kada

This is the version of ff-utils I'm using, which jdeneux pointed me to: http://sourceforge.net/project/showfiles...e_id=98791

As for your kernel patch, I recommend you communicate with the people on the linux-input mailing list (which jdeneux also pointed me to). The archive is here: http://www.mail-archive.com/linux-input@...f.cuni.cz/
You can subscribe by sending a mail with the text "subscribe linux-input" in the message body to majordomo ~at~ atrey.karlin.mff.cuni.cz

If you can get the GP working on Linux I think you'll make a lot of people happy. It might take a little reverse-engineering if the wheel isn't fully HID compliant. Is that what you're implying? Here's some interesting info on HID: http://www.usb.org/developers/hidpage/


jdeneux, I just signed up for the SDL mailing list and after I do a little more research on the topic, I'm going to post some questions, and try to get started.

[anrp]

Just wanted to poke my head in here. I contacted Logitech about potentially getting tech info on the FFB stuff in the G25 wheel; they said that they couldn't give it out, so that's not going to be any help. :?

I do have good news though; I own a G25, and I have no windows machines except inside VMs, so I have a vested interest in getting it working fully. (Yes, I bought it with the full knowledge that it wasn't going to completely work for me in the beginning. It mostly works, just not all of the features.)

There is one question I have, and this probably isn't so much the right place but I'll ask anyway: would there potentially be legal trouble with the same person reverse engineering and developing a driver for the linux kernel? I personally don't think so, since I'm not looking at any code, just the inputs and outputs of someone else's code. (I'm willing to work with someone else to do two-party RE if someone wants docs.)

[Kada]

If you can get the GP working on Linux I think you'll make a lot of people happy.

Just a quick info. Finally I got force feedback with WFF GP working, yes force feedback works in VDrift (latest svn version of vdrift, hacked 2.6.20 kernel). I'll post more later, I did not sleep whole night (5:50am here :-)).

[Kada]

First of all, I was stupid. I always tested force feedback by the "fftest" utility, which never worked for me. But, thanks to this thread, I tried the "ffcfstress" program, and it works. So, adding usbids for the wheel is enough to make WFF GP work (with FF). For separate axis (gas/brake) is a small patch needed. I'll post the details to the linux-input mailing list.

I don't have many experience with VDrift. Is somewhere discussion about FF feeling in VDrift? I searched this forum, but I didn't find anything about "users experience". Maybe it's "too new" feature, isn't it? I'm posting my comments on it here, if it's wrong thread, please move it.

The first problem with FF is, that the wheel is not centered, even if the car is stopped. It's turned about 30 degrees to the left. It feels like flat left front tyre . Maybe some additional calibration is needed. My wheel was _not_ calibrated in the kernel (through jscal utility), it was calibrated only in vdrift.

The FF effects are too sudden. I mean, when I drive straight, or only slightly turning, then there are no forces (except centering force described above). When the turn is harder and the car becomes drifting, then a new (strong) force appears. But it's like yes or no, only strong "drifting" force or nothing (except centering), no smaller contious forces between these two.

The other thing is, that the "drifting" force is "weird". Maybe the forces are in the opposite direction for my wheel (just guessing), like in gtr2, RACE, f1 challenge and must be reversed. Would be possible to add force feedback test to the gui, something like "now moving wheel left", "now moving right", "now ceneterig"?

I'm really glad, that there is opensource racing simulator like this, keep it going :-).

P.S. I spent most of the time compiling nvidia binary s**t for 2.6.20, you need to patch their "sources", the patch is on the nvida official forum. Maybe this save time for someone.

[thelusiv]

Kada, I'm glad you're making progress with your wheel. Thanks for the feedback (no pun intended) about force feedback.

You can add a ff_gain option to your VDrift.config under the [ joystick ] section that will make the forces you feel on the steering wheel stronger or weaker, depending on the number you use. I think maybe by default it's 2.0, so the forces are doubled, but you could set it back to 1.0 and it might feel better for you. 2.0 felt pretty good on my Logitech Momo Racing Force wheel (the black one). I'll add an option for the ff_gain setting to the Options -> Controls -> Joystick menu soon.

As for inverting the forces, again I just set it up so that it felt right on my wheel - when I turn right it pushes the wheel left, and so on. Is this really backwards on your wheel? Is that common for some wheels to take opposite values from others? If so, I can add another option "ff_invert" or something that can be on or off, and this will probably solve the problem.

[joevenzon]

What do you think about adding a FFB indicator to the input graph?

[stenyak]

Forces may feel wrong because, IIRC, the code reads torques applied to the wheels, and applies them to the steering wheel.
This is not what happens in real life. You would need to simulate the linkages from the steering rod attached to both front wheels, through the steering rack, to the steering wheel (ending up with a torque). But not having the suspension simulated properly, i guess that's as close as you can get.
I'm not sure how far from reality it is, maybe not too much, but keep that in mind in the future if you want to get more realistc FFB in vdrift.

[thelusiv]

Joe, that seems like a good idea. If you want to examine the FF output values look at the file ff_out.txt in the directory where you run VDrift (if you compiled it with force feedback support). This will be gone for the release, it's just for debugging.

stenyak, I think using the aligning moment from the tires is a fairly common way to get the force feedback value, isn't it? But I suppose you're right, it's not going to be perfect; either for the reason you mention, or because our Pacejka data is pretty far from perfect.

[stenyak]

The method i mention is the one used by all sims that happen to be acclaimed by the simracing community as being the most realistic, the ones that really allow to "connect" with the car, and that feel the more natural in all circumstances: netKar, netKarPro, Richard Burns Rally, Drivers Republic, LFS (I don't know if there are more sims that do it The Right Way ™).

[thelusiv]

Alright, we'll keep that in mind when updating the suspension code.

Looks like I'll start working on the force feedback library I've been talking about after the upcoming VDrift release is finished, in the next few days or so.