02-16-2007, 05:03 PM,
|
|
jdeneux
Junior Member
|
Posts: 10
Threads: 0
Joined: Oct 2005
|
|
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.
|
|
02-17-2007, 05:24 AM,
|
|
Nigo
Member
|
Posts: 118
Threads: 9
Joined: Jun 2006
|
|
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
|
|
02-17-2007, 02:53 PM,
|
|
jdeneux
Junior Member
|
Posts: 10
Threads: 0
Joined: Oct 2005
|
|
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).
|
|
02-19-2007, 02:18 PM,
|
|
stenyak
Junior Member
|
Posts: 44
Threads: 1
Joined: Dec 2006
|
|
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..).
|
|
02-20-2007, 04:36 AM,
|
|
thelusiv
Administrator
|
Posts: 2,346
Threads: 223
Joined: Jun 2005
|
|
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...
|
|
02-20-2007, 06:28 AM,
|
|
stenyak
Junior Member
|
Posts: 44
Threads: 1
Joined: Dec 2006
|
|
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.
|
|
02-20-2007, 12:48 PM,
|
|
Nigo
Member
|
Posts: 118
Threads: 9
Joined: Jun 2006
|
|
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 ?
|
|
02-20-2007, 05:34 PM,
|
|
thelusiv
Administrator
|
Posts: 2,346
Threads: 223
Joined: Jun 2005
|
|
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.
|
|
02-20-2007, 05:52 PM,
|
|
stenyak
Junior Member
|
Posts: 44
Threads: 1
Joined: Dec 2006
|
|
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:
Code: #ifdef CONFIG_LOGITECH_FF
{0x46d, 0xc211, hid_lgff_init}, // Logitech Cordless rumble pad
{0x46d, 0xc283, hid_lgff_init}, // Logitech Wingman Force 3d
{0x46d, 0xc295, hid_lgff_init}, // Logitech MOMO force wheel
{0x46d, 0xc219, hid_lgff_init}, // Logitech Cordless rumble pad 2
{0x46d, 0xc294, hid_lgff_init}, // Logitech G25 wheel
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.
|
|
02-20-2007, 06:45 PM,
|
|
thelusiv
Administrator
|
Posts: 2,346
Threads: 223
Joined: Jun 2005
|
|
Now I see what my problem is...in my /boot/config-2.6.17-11-generic file:
Code: # CONFIG_HID_FF is not set
Time to recompile...
|
|
02-20-2007, 06:47 PM,
|
|
stenyak
Junior Member
|
Posts: 44
Threads: 1
Joined: Dec 2006
|
|
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.
|
|
|