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

A constant force effect will pull the wheel in left/right direction with a specified force. 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.

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

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?

Force feedback (in a wheel or in a joystick) is only a force, to the left or to the right, so there is no direct way of telling the device "I want you to be in that exact position".
If you want your wheel to stop at 90º left, you must stop sending that forces just before it reaches that point, or maybe even apply a little force to the sopposite direction if you turned more than you wanted.

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

Whiskey explained it perfectly.

To check if the wheel is where you want it, you have to use X-axis value. I don't have any documentation here at the moment, but if I remember correctly, all HID compliant joysticks/wheels should report axes positions in <-32768, 32768> range in Linux. If your wheel's rotation range is 900 degrees, you can get current angle of the wheel like

Positive values indicate the wheel is rotated to the right, negative to the left.

If you set the range to something else, 32768 will STILL mean +/-450 degrees, the wheel does not recalculate max X-axis value automatically, so keep this in mind. (Unless the wheel is in 200 deg "fallback" mode, in that case 32768 means +/- 100 deg)
(I'm assuming here that you're using the DFGT)

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

No problem, please note that I wrote the last post off the top of my head so I might have made some stupid mistake. You can use "jscal" and "jstest" utils to read raw axes values to check what data you're getting from the wheel... Good luck

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.

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

A lot of what your trying to do depends on the driver, if your device uses the standard force feedback signals defined in the usb hid specifications it will just work(tm) with the tests your using. Unfortunately the hid specs also allow for custom signals which the manufacturer can incorporate into their own driver, this really screws things up for open source drivers, its possible ff-utils is unable to communicate with your device due to this.

If you can get it working then a spring effect would suit your purposes better than a constant force effect (if your device supports it). Some maybe useful links:
This document is the USB physical interface spec, page 8 has some info on force types.
If you have windows then usblyzer is a simple option to see exactly what kind of communications your device uses, some folks have issues with the required driver though.
If not you will need to unbind the linux driver from your device (details here) then use lsusb -vvv to view details for the device.

Quote from Anisha Kaul :

linux-dopx:/home/anisha/# [B]ffcfstress -d /dev/input/js0 [/B]
ERROR: can not get key bits (Invalid argument) [ffcfstress.c:118]


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

Force feedback support for DFGT is available only since kernel 3.2. Unless you patch the kernel manually, force feedback won't work with DFGT in the native mode (it should work in the fallback mode though).

EDIT: It's also preferred to send FF events to /dev/input/eventX rather than jsX.

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?

The patches can be found on git.kernel.log, but they are slightly large and most likely won't apply clearly to any kernel older than 3.0. The easiest way to get FF working in the native mode would be to get kernel 3.2. I'm certain that Ubuntu provides packages for the latest kernel, dunno how about other distributions.

Well, thanks for following up.

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

Quote from Anisha Kaul :

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

Yes, every FF tool relies on the support of the kernel driver.

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

Thanks.

It's good to hear that, please let me know if you run into any troubles related to the updated kernel driver.

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?

As far as I'm aware yes, everything you need is loaded. MadCatX would know the inner workings of joystick drivers better though, I think in some cases extra functionality can be added either by extra modules or different parameters passed to the modules already being used.

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

Again, my knowledge of joystick drivers on linux isn't great. A joystick needs a driver, the usbhid driver contains everything they should need but manufacturers like to be awkward and do things their own way through their own drivers. The basic functionality of your wheel is supported by usbhid, force feedback is supported through MadCatX implementation, I'm not even sure where he added it (I'm using an older kernel) but I'm guessing its now part of usbhid.

$ modinfo usbhid
filename: /lib/modules/2.6.32-30-generic/kernel/drivers/hid/usbhid/usbhid.ko
license: GPL
description: USB HID core driver
author: Andreas Gal, Vojtech Pavlik, Jiri Kosina
srcversion: 84CAE6E46ACCA3B9F140D12
alias: usb:v*p*d*dc*dsc*dp*ic03isc*ip*
depends: hid
vermagic: 2.6.32-30-generic SMP mod_unload modversions
parm: mousepoll:Polling interval of mice (uint)
parm: ignoreled:Autosuspend with active leds (uint)
parm: quirks:Add/modify USB HID quirks by specifying quirks=vendorIDroductID:quirks where vendorID, productID, and quirks are all in 0x-prefixed hex (array of charp)

The last line gives details of how to pass parameters to the driver (this doesn't apply to all modules and its not always visible with modinfo). In this case the vendor and product id's passed to usbhid when loading enable different functions, usually when the manufacturer hasn't used the standard signals defined in the USB HID specifications but has made use of the vendor defined signals. This is still covered by the USB specifications but it make life difficult

Thats the basics of whats happening, I think usbhid has more ways of passing parameters, I kind of remember something about the 900deg function of your wheel being separate to the force feedback function but you will need to either read through the source (not that difficult, just takes a bit of getting used to) and/or check with MadCatX.

To use a USB HID joystick the "joydev" module has to be loaded and since every USB HID device should behave the same, that's pretty much all you need to read the joystick. When my DFP is connected, kernel loads these modules


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

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?

Quote :

most of it lies in /drivers/hid/hid-lg4ff.c

Sounds like your missing some parts, imho you would be better compiling the full kernel as you would know for sure everything is as it should be.