Thanks, but my point was that I "just" replaced the hid-ld4ff, nothing else. So, I wouldn't have been surprised if FF didn't work in the native mode. My problem is that it doesn't work at all now.

Secondly we have to make this work on many different machines. So, is there any way of getting 3.2.1 on them without compiling it for every machine separately?

Thanks for bothering, Stan and MadCatX

Quote from MadCatX :

The enhanced support for the Logitech wheels is a part of hid_logitech driver and most of it lies in /drivers/hid/hid-lg4ff.c

Actually, I know this. Simon Wood informed me about this on the linux-input mailing list.

The current problem is that for kernel 3.0.0, I replaced the old "hid-lg4ff.c" with the same file from the 3.2.1 kernel. Updated the makefile accordingly.
Compiled and installed successfully.

To my horror, when I rebooted, even in the normal mode the force feedback wasn't working. "jstest" though did read the joystick.

Any wild guesses/helps?

Thanks for replying. What would be that extra functionality that you are talking of?

Off topic:

If the `jstest` recognizes the joystick and reads from it, does it mean that all the required modules required for the joystick have been already loaded?

So, finally I downloaded the kernel 3.2.1, compiled and installed it.
The force feedback does work in the native mode now.

Thanks.

Well, thanks for following up.

Will the same problem still persist if I use libsdl 1.3? It is said to be supporting FF.

Yeah, but fftest works for me with the constant force on the kernel 2.6.32. See my other thread.

But, you are right, it works only in default mode, not in native mode.

Which kernel patch were you talking about?

Last edited by Anisha Kaul, Wed 18 Jan 2012, 07:04.

• I replaced the label LOGITECH_FF with LOGIWHEELS_FF in the file /usr/src/linux-2.6.34-12/drivers/hid/Kconfig.
  
• Set default y as shown below:
  
  config [COLOR="red"]LOGIWHEELS_FF [/COLOR]
bool "Logitech force feedback support"
depends on HID_LOGITECH
[COLOR="Red"]default y [/COLOR]
select INPUT_FF_MEMLESS
help
Say Y here if you have one of these devices:
-Logitech WingMan Cordless RumblePad
-Logitech WingMan Cordless RumblePad 2
-Logitech WingMan Force 3D
-Logitech Formula Force EX
-Logitech WingMan Formula Force GP
-Logitech MOMO Force wheel

and if you want to enable force feedback for them.
Note: if you say N here, this device will still be supported, but without
force feedback
  
  The fftest worked with constant force as shown below.
  
  linux-dopx:/home/anisha/ # fftest /dev/input/event4
Force feedback test program.
HOLD FIRMLY YOUR WHEEL OR JOYSTICK TO PREVENT DAMAGES

Device /dev/input/event4 opened
Axes query:
Effects: Constant
Number of simultaneous effects: 16
Upload effects[0]: Invalid argument
Upload effects[2]: Invalid argument
Upload effects[3]: Invalid argument
Upload effects[4]: Invalid argument
Upload effects[5]: Invalid argument
Enter effect number, -1 to exit
1
Now Playing: Constant Force
Enter effect number, -1 to exit

  
  

Thanks to: Simon from linux-input mailing list.
http://www.spinics.net/lists/linux-input/msg19084.html

Last edited by Anisha Kaul, Wed 18 Jan 2012, 10:44.

The wheel is DFGT logitech,
Kernel: 2.6.32 64 bit




Any helps?

This error appears with the wheel DFGT.
Not sure what it means.

Quote from MadCatX :

ff-utils provide a good set of tools and sources you might want to check out http://sourceforge.net/projects/libff/files/ffutils/

Thanks for that link.

I talked with the people of the mailing list "linux-input" too w.r.t the same issue.
They too pointed me to "ffcfstress" program (included in ffutils) which uses the "constant force" with "ioctl()" system call.

I hope that does the trick.

Thanks MadCatX, you have been too helpful. I will get back to this if something works or if something doesn't work.

Ok, what is the way to detect (through code) whether the wheel has reached 90 or not? thanks again.

Thanks.

Quote from MadCatX :

If you want to rotate the wheel by a certain angle, you have to switch the effect off when the wheel is in the position you want.

Can you elaborate a bit more on this one please?

I wish to physically rotate the joystick wheel through the code/terminal.
I mean if I run a command, the wheel should rotate to the left/right.

I looked in here: http://www.mjmwired.net/kernel/Documentation/input/ff.txt

Is ioctl() system call as shown in the above link appropriate for the task
or I am barking at the wrong tree?

Can constant effect be used to rotate the wheel the way we want?

Any hints on how to achieve this from userspace?

I noticed this thread so thought I could ask it here: http://www.lfsforum.net/archive/index.php/t-74115.html

MadCatX,

Thanks for testing the code.

Some days back my ex boss discovered that this problem occurs when we plug the wheel plug out and then plug it "back" again, and the LTconf configuration program (which in my case runs in an infinite loop) writes the configurations to the driver file BEFORE our wheel can complete its "initial default rotation".

So, we decided to put a sleep(7) before the code which configures the wheel so that the code doesn't start executing till the rotation completes. This trick worked.

Currently we haven;t updated to kernel 3.0.

Thanks for your help and tests.

Okay so here is the code: (Combined in one file)
Have attached the zip file at the end of the post.

Required untouched functions from the wheels.c. I have removed the extra functions.

The major three functions of wheelfunctions.c. These are the ones needed for setting autocenter, nativemode, and the wheel name and range. I have removed the extra ones here too.

and finally the main(): The while loop is only for the process running forever.

Last edited by Anisha Kaul, Tue 13 Dec 2011, 05:39.

Thanks for following up.

I found this: http://permalink.gmane.org/gma ... ibusb.devel.general/12888

and you were right, the code is claiming and releasing the interface before and after sending a command.

See this:
I haven't "touched" this code. this is from the LTconf's wheelFunctions.c file.

One way to set the wheel up completely and then release the interface is by making the variables global (currently the handle is local)? How and why will that help, BTW?

Actually, now, the code of calling these usb functions is in a while (1) loop currently.
After the wire is "plugged" in, I start this program.
The wheel gets configured properly.
I take out the wire, and then plug it back again.
This time too the wheel gets configured "properly" but after a few seconds, these messages get displayed:


Please see if you can guide.

Well, anyway, here is the whole dmesg.

Thanks again.

Is this what you were talking about?

-EDIT: The above output is what I get from the end of the dmesg-

This is after the reconnection. wheel is stuck at 180. :mad:

Last edited by Anisha Kaul, Thu 8 Dec 2011, 10:43.

Quote from MadCatX :

The wheel has to be sent a specific command that makes it switch from fallback mode to native mode.

Thanks for replying.

Actually, after reconnecting, the following code gets called: See the red.

This even prints the proper messages. Did you mean something else?

Quote from MadCatX :

You might try the latest 3.2 kernel which is patched to handle Logitech wheels properly.

I am currently on 2.6.34 kernel (64 bit) Suse 11.3.

For testing reasons, I picked up the relevant code from the LTWheelConf for calibration of Driving Force GT DFGT.

In a separate thread (C++) I keep on checking whether the wheel is physically connected or not (by checking the read() status).

When I run this program the first time, the wheel options get set perfectly and the wheel rotates up to 900 degrees (as desired).

While the program continues running, I manually take out the wheel wire and then reconnect it again.

The modified code detects the reconnection, and thus recalls the all relevant LTWheelConf functions again (based on the originally supplied parameters like -w DFGT, native mode, range 900, autocenter=0).

All works fine - except that the wheel's rotation range gets automatically set to 180 degrees rather than the original 900 degrees.

I tried to reset the driver too (libusb_reset_device), but that doesn't help.

Any ideas?

Last edited by Anisha Kaul, Thu 8 Dec 2011, 09:46.

But MadCat, weren't you who had written a patch for the joystick driver? I saw your post in this forum, that's why thought this could be the place to ask.

I want to understand the "coef" member of this struct.
Is this used to set axis values? If yes, then are the axis
values to be set as follows?

1. Center Min
   
2. Center Max
   
3. Range Min
   
4. Range Max
   

If I set the values as shown in the screenshot below to struct directly in the program, will that make sense?

Last edited by Anisha Kaul, Wed 7 Dec 2011, 03:47.