Forums

stenyak Wrote:First of all, i'm no expert in these issues, so correct me if i'm wrong.

Ok, I'll correct you

Quote:The FFB provided by linux kernel (the one i've used at least) works for all i-force (Immersion Techs) devices.

Actually the term I-Force is misleading. It is used for devices that speak different protocols.

The first driver I wrote was for I-Force devices (I have a wheel from AVB that uses this protocol). This driver is quite complete and supports many effects (springs, periodic force...).

The second driver I wrote was for Logitech devices. These devices are much dumber and support only constant force effects and springs. All other effects must be simulated by the application using periodical updates. This driver also supports two cordless rumble pads from Logitech.

There are also other drivers written by other people which I'm not familiar with.

Quote:I think Immersion has patent for all force feedback systems (isn't that why the ps3 default controllers don't come with ffb?), so i guess all devices with ffb support adhere to i-force api, making it a sort-of standard.

Judging by what the hacker who coded i-force support says, it looks like this api could be used as a standard (of course not an open standard); but i guess it's easier to directly use Immersion SDKs on windows (which we don't have in linux).

This document describes the protocol to communicate with the device. It's of no interest to application writers, only driver writers.

The force feedback API of linux is device-independent. You use ioctls and writes to /dev/input/eventXX to send and update your effects.

jdeneux: Thanks for the information. So you wrote the drivers for the force feedback module that's in the Linux kernel now?

If/when we do start force feedback support it will have to be through some kind of library, either something we write or another one from somewhere else. Otherwise it will be very difficult to keep Windows and OS X support. edit: I didn't quite finish that though before posting. I was going to ask, do you have any suggestions as to such a force-feedback library that is cross platform?

jdeneux Wrote:All other effects must be simulated by the application using periodical updates

what application ? on Windows, is it the driver which takes care of that ? DirectX ?

jdeneux Wrote:There are also other drivers written by other people which I'm not familiar with

... actually, what driver "works" for what wheel, and what wheel have no driver at all, do you know such a list ?

jdeneux Wrote:The force feedback API of linux is device-independent. You use ioctls and writes to /dev/input/eventXX to send and update your effects.

but you need FFB activated in your kernel and a working driver, right ?

thanks for your help

thelusiv Wrote:jdeneux: Thanks for the information. So you wrote the drivers for the force feedback module that's in the Linux kernel now?

I wrote two of them, but work by other people continued after that.

Quote:If/when we do start force feedback support it will have to be through some kind of library, either something we write or another one from somewhere else. Otherwise it will be very difficult to keep Windows and OS X support. edit: I didn't quite finish that though before posting. I was going to ask, do you have any suggestions as to such a force-feedback library that is cross platform?

I don't know of any such library, and I don't think there is any. It would be quite interesting to make one though.
I'm also working on a racing sim for Windows and Linux, and my plans are to write such a library. But I don't expect that to happen soon. I'm completely ignorant when it comes to DirectX programming.

To Nigo:
I know that you can send a complex effect to a dumb device on windows, and there is a layer of software somewhere that does the effect simulation. I don't know what layer does that, but I would expect something just above the driver, e.g. DirectX.

About the availability of drivers: That's unclear at the moment, but Anssi Hannula, another FFB driver developer will set up a wiki page on libff.sf.net, and things will hopefully get clearer.
Regarding wheels, it is my guess that recent Logitech wheels are all supported by usbhid.ko, although maybe not right out of the box (patching as indicated by stenyak may be needed). The older MOMO racing wheel should be supported by iforce.ko. Other smaller brands might also work.
I know of a few microsoft devices that use PID, an open protocol specification for FFB. Strangely, there is no working driver for them yet, but that should be resolved in the future (if only someone will offer to read the specs and implement them).

Seems like we need to bug the SDL people to put in FFB support... the linux part seems pretty easy (just writing to some device files, which they're already familiar with because they have the joystick support working w/ event devices anyway) and the windows part should be pretty easy if they're using directinput already for joystick device input in Windows (I'm not sure if they are, though).

We can always make the request, but I wouldn't count on SDL including force feedback any time soon. It seems like their response would probably be that someone else should write a SDL-compatible library and perhaps call it SDL_ff, seeing as force-feedback is pretty specialized (more so than image loading and manipulation, and networking, and things like that - which all have separate libraries outside SDL).

Seeing as we're probably one of the few open source projects heavily interested in force feedback, I think we need to do all we can to encourage development of a cross-platform force feedback lib, be it part of SDL or not.

I don't think making a request will change anything.
Asking for info on how to integrate it all with SDL, then submitting a patch, is what will yield results.
(FF was already discussed long time ago, and the conclussion was simply lack of interested & knowledgeable people)

Of course, there's no reason you have to code with SDL; you could create your own library if that makes it easier for you. Or choose to contribute to OIS, which seems to have already put some effort into it.

I'm willing to contribute all i can to it, since i finally have a wheel that is sort-of working under linux; but don't count too much on me to provide code (there's a reason why i post so much instead of coding Motorsport..).

I've been checking out OIS, and the Linux force-feedback section of OIS code is all stub functions. I've contacted the developer about it with some questions and we'll see what he says. It looks like OIS has working FF on Windows, but Mac support is also seemingly missing.

stenyak is correct about SDL having discussed force feedback before, search google for "SDL force feedback" and you'll see. Chatting with jdeneux a little more he told me about ff-utils, which looks interesting but doesn't work for me. If anyone has success with it let me know.

OIS might be the way to go, if the Linux force feedback support can be added. I'll keep playing with it...

FF-utils is what i used in order to check if my wheel worked. But first i had to patch the kernel with my device model ID. Other than that, i don't think i did many things. Check the kernel docs regarding wheels, how to create the /dev devices if they're not already there, etc...

BTW, sometime soon, a couple new device IDs will be included in the kernel, meaning more people won't need to patch in order to get FF working.

stenyak Wrote:BTW, sometime soon, a couple new device IDs will be included in the kernel, meaning more people won't need to patch in order to get FF working

can't we just install the drivers as modules ? :? that sucks
why is that, btw ?

stenyak, can you provide some details on how you did the kernel patch? I haven't started digging through the kernel code yet. I'm really thinking I shouldn't have to patch for my Logitech Momo steering wheel though.

I've been reading through this file, ff.txt, which is the kernel documentation on force-feedback devices. There are also two drawings, shape.fig and interactive.fig. Install your kernel doc to get those files, I am having trouble finding directly downloadable versions. They must be viewed with Xfig (I tried Inkscape, but no go).
http://www.mjmwired.net/kernel/Documenta...put/ff.txt

One problem I see is that I must have root-level access to write to the /dev/input/event* devices in the first place. This will be an issue for sure, since most games aren't run as root. In Ubuntu/Debian event devices corresponding with joysticks should belong to the plugdev group so that users can write to them too...

Here's an issue. How to even tell which event device corresponds to the joystick anyway? I have event0 through event5, and event1 is my gamepad, while event5 is my wheel. How are we supposed to tell which device to use from a programming standpoint? I guess each one can be tested using the ff interface, but I don't see that as very simple seeing as we may have access to some and maybe not others. We surely can't expect users to know which device is which.

The patch is very simple. It tells the FF drivers to try to interact with the wheel. If your wheel isn't already on the list, do this:
-Run usbview (for example), and get the model ID and maker ID of your wheel.
-Open drivers/usb/input/hid-ff.c, line 50 or so.
-Add a new line.

Recompile module (or kernel in my case, i use few modules), reload module (or restart linux in my case).

For example, this is how my current kernel code looks like:
This is what i mentioned is being included in some new kernel release soon.

As for the /dev/thingies and permissions, i don't know; i tested the wheel as root. I'm no linux guru so i can't help much with those issues.

Now I see what my problem is...in my /boot/config-2.6.17-11-generic file:
Time to recompile...

Oh, well, yeah, you need to enable all related pieces of code in kernel config. USB, joysticks, HID, ... whatever. I don't remember exactly which were necessary.

According to usbview (ugh, it uses GTK 1.2) my WIngMan RumblePad has the ID 0x46d, 0xc20a. I'll test it soon to see if it works or not. If anything it might do the same things as the cordless rumble pad. However the Momo force wheel is supported without patching, so it should work after I finish this compile and reboot...

edit: Another interesting thing: my Momo wheel is not the device ID in the kernel, but instead 0x46d, 0xca03. Strange. I wonder if there are more than one version.

edit 2: Finally got force-feedback working under Linux for my Logitech Momo Force wheel. The ffcfstress program from ff-utils works pretty well. I will start working on a VDrift patch to use it soon...


:mrgreen: :mrgreen: :twisted: :twisted: