[PATCH] Fix autocentering command in hid-lgff driver

Hello,

this patch fixes two issues with autocentering in lgff driver. Current implementation incorrectly assumes that the saturation force is always 0x80 which is 
inconsistent with behavior of the official driver. It also makes it impossible to disable autocentering on some wheels - at least Logitech Formula Force RX is 
the case. Values of stiffness coefficient were also calculated incorrectly. Formula used in this patch appears to generate the same commands as the official 
Logitech drivers. The patch also fixes two minor coding style issues.

Regards, Michal.


Signed-off-by: Michal Malý <redacted>
---
 drivers/hid/hid-lgff.c |   18 ++++++++++++------
 1 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/hid/hid-lgff.c b/drivers/hid/hid-lgff.c
index 088f850..3d30a8e 100644
--- a/drivers/hid/hid-lgff.c
+++ b/drivers/hid/hid-lgff.c

@@ -129,18 +129,24 @@ static void hid_lgff_set_autocenter(struct input_dev *dev, u16 magnitude)
 	struct list_head *report_list = &hid->report_enum[HID_OUTPUT_REPORT].report_list;
 	struct hid_report *report = list_entry(report_list->next, struct hid_report, list);
 	__s32 *value = report->field[0]->value;
-	magnitude = (magnitude >> 12) & 0xf;
+	u8 saturation_force = magnitude >> 8;
+	u8 stiffness_coeff;
+	if (magnitude <= 32768)
+		stiffness_coeff = saturation_force / 10;
+	else
+		stiffness_coeff = (saturation_force / 62) + 11;
+
 	*value++ = 0xfe;
 	*value++ = 0x0d;
-	*value++ = magnitude;   /* clockwise strength */
-	*value++ = magnitude;   /* counter-clockwise strength */
-	*value++ = 0x80;
+	*value++ = stiffness_coeff;   /* clockwise strength */
+	*value++ = stiffness_coeff;   /* counter-clockwise strength */
+	*value++ = saturation_force;
 	*value++ = 0x00;
 	*value = 0x00;
 	usbhid_submit_report(hid, report, USB_DIR_OUT);
 }
 
-int lgff_init(struct hid_device* hid)
+int lgff_init(struct hid_device *hid)
 {
 	struct hid_input *hidinput = list_entry(hid->inputs.next, struct hid_input, list);
 	struct list_head *report_list = &hid->report_enum[HID_OUTPUT_REPORT].report_list;

@@ -180,7 +186,7 @@ int lgff_init(struct hid_device* hid)
 	if (error)
 		return error;
 
-	if ( test_bit(FF_AUTOCENTER, dev->ffbit) )
+	if (test_bit(FF_AUTOCENTER, dev->ffbit))
 		dev->ff->set_autocenter = hid_lgff_set_autocenter;
 
 	pr_info("Force feedback for Logitech force feedback devices by Johann Deneux <johann.deneux@it.uu.se>\n");

-- 
1.7.5.4


--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hello,

this patch fixes two issues with autocentering in lgff driver. Current
implementation incorrectly assumes that the saturation force is always
0x80 which is
inconsistent with behavior of the official driver. It also makes it
impossible to disable autocentering on some wheels - at least Logitech
Formula Force RX is
the case. Values of stiffness coefficient were also calculated
incorrectly. Formula used in this patch appears to generate the same
commands as the official
Logitech drivers. The patch also fixes two minor coding style issues.

Hi Michal,
Can you elaborate more on the difference between stiffness and saturation?
And how these might work in the Linux FF system which only accounts a
single parameter.

On my reverse engineering of the Wii Wheel (1) I noticed that the
AutoCentre consisted of 3 variables, but did realise the precise details.
Perhaps I can factor in a similar adjustment....

BTW - I also discovered some other modes of feedback beyond AutoCentre and
CF which might be applicable to other Logitech wheels. (2)

Simon

1.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=drivers/hid/hid-lg4ff.c;h=fa550c8e1d1bc639bd3e9c34a299903391bca44a;hb=3a2289a4a317e0290a8bc7af28c62c9830cb12e5#l72

2. http://wiibrew.org/wiki/Logitech_USB_steering_wheel

On Tuesday 14 of June 2011 17:20:52 you wrote:

quoted

Hello,

this patch fixes two issues with autocentering in lgff driver. Current
implementation incorrectly assumes that the saturation force is always
0x80 which is
inconsistent with behavior of the official driver. It also makes it
impossible to disable autocentering on some wheels - at least Logitech
Formula Force RX is
the case. Values of stiffness coefficient were also calculated
incorrectly. Formula used in this patch appears to generate the same
commands as the official
Logitech drivers. The patch also fixes two minor coding style issues.

Hi Michal,
Can you elaborate more on the difference between stiffness and saturation?
And how these might work in the Linux FF system which only accounts a
single parameter.

On my reverse engineering of the Wii Wheel (1) I noticed that the
AutoCentre consisted of 3 variables, but did realise the precise details.
Perhaps I can factor in a similar adjustment....

BTW - I also discovered some other modes of feedback beyond AutoCentre and
CF which might be applicable to other Logitech wheels. (2)

Simon

1.
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=dr
ivers/hid/hid-lg4ff.c;h=fa550c8e1d1bc639bd3e9c34a299903391bca44a;hb=3a2289a4
a317e0290a8bc7af28c62c9830cb12e5#l72

2. http://wiibrew.org/wiki/Logitech_USB_steering_wheel

Sure, but please don't take it like I have some inside knowledge of Logitech FF implementation. I've been given few bits of useful information, the rest I 
figured out from sniffed USB communication.

Centering force seems to be modeled as a spring effect. Force created by a spring can be calculated as "F = -k*x" where F = force, k = stiffness coefficient 
and x = deflection from centre. The higher the k is, the faster the centering force increases when the wheel is turned. Saturation force seems to be the limit 
centering force, so when kx > saturation_force => F = saturation_force.
Logitech driver has a slider which sets the centering force from 0 % to 150 % (it's actually from 0 % to 200 %, at least the values in the command suggest 
so) and both the stiffness coeff and saturation force increase gradually with the centering force according to the formula I provide in the patch, so just the 
magnitude value is enough. It looks like the stiffness coeff actually wraps around, because 0 = no stiffness, 7 = max stiffness, 8 = low stiffness, 15 = max 
stiffness. It'd be interesting to see if you can observe the same behavior on the Wii wheel.

As for the other FF effects, I guess these are things like "rumble" etc. I'm planning to look into it more when I'll have some extra free time.

Regards, Michal.

quoted

2. http://wiibrew.org/wiki/Logitech_USB_steering_wheel

Sure, but please don't take it like I have some inside knowledge of
Logitech FF implementation. I've been given few bits of useful
information, the rest I figured out from sniffed USB communication.

Of course, we're all in the same boat of trying to figure it out. Our only
help is that Engineers are lazy and often reuse stuff they've done before.

It looks like the stiffness coeff actually
wraps around, because 0 = no stiffness, 7 = max stiffness, 8 = low
stiffness, 15 = max
stiffness. It'd be interesting to see if you can observe the same behavior
on the Wii wheel.

Yes the Wii Wheel only does 0-7 and then loops too...

I actually meant to quantify the force produced and purchased a torque
meter, but its range wasn't low enough to be useful so I took it back. I
think I can do something with a 'luggage scale' pulling at a tangent to
the wheel so will give that a try.

My reverse engineer technique had a python-hid script so that I could
throw packets directly at the wheel to produce specific force setups. I
need to port this to python-libusb (as python-hid is dead), but that
should be relatively simple and can forward off list to anyone who wants a
copy.

As for the other FF effects, I guess these are things like "rumble" etc.
I'm planning to look into it more when I'll have some extra free time.

If you figure codes out, I'd love to try them against my Wheel. I did have
a PS3 Driving Force Wireless, but fried it's micro whilst I was hooking
the BusPirate up to it.

This would work under Windows and playback various effects in test mode as
you pushed buttons - if anybody can grab some USB logs of this I can
attempt to parse them for the codes....

Simon

On Tuesday 14 of June 2011 19:16:37 simon@mungewell.org wrote:

My reverse engineer technique had a python-hid script so that I could
throw packets directly at the wheel to produce specific force setups. I
need to port this to python-libusb (as python-hid is dead), but that
should be relatively simple and can forward off list to anyone who wants a
copy.

You might want to check out Michael Bauer's LTWheelConf [1]. It's written in C so it's not the niftiest thing to use for 
playing around with the wheel, but adding support for the Wii wheel is a matter of 30 seconds. It uses libusb and I'm sure 
it can be easily modified to send whatever data you want to the wheel.

This would work under Windows and playback various effects in test mode as
you pushed buttons - if anybody can grab some USB logs of this I can
attempt to parse them for the codes....

That's kind of my plan. I'll try to write some simple "effect generator" app using DirectInput and sniff the commands. By 
the way, I've been provided with the anti-center spring command description for my Driving Force Pro which I use to set 
the wheel's range. Is it accepted by the Wii wheel as well?

As I read the source of all lgff drivers, I wonder if all Logitech wheels shouldn't be handled in the lg4ff driver. I'm worried 
that further patching of lgff could break functionality with some older joysticks it's been originally meant to work with.

81 0B 19 E6 FF 4A FF:
 8* - set effect number 4, *1 - start effect command
 0B - effect type: spring
 19 - left hand ramp start (MSB)
 E6 - right hand ramp start (MSB)
 F* - RH stiffness (0xF:max), *F - LH stiffness (0xF:max)
 4* - RH ramp start (LSB) , LSbit is RH stiffness sign (0:+ 1:-)
 *A - LH ramp start (LSB), LSbit is LH stiffness sign (0:+ 1:-)
 FF - saturation level for spring force (0xFF = max)

In above example the wheel soft stops are set to
0x19A and 0xE64 or 410 and -412 where 0x7FF or 2047 corresponds to half a rotation range or 450 degrees. Therefore 
the wheel soft stops are set to +-360 degrees - the boundaries are calculated from the outsite.(410 / 2047 * 450)

(Description provided by lbondar, original can be found here [2])

[1] https://github.com/TripleSpeeder/LTWheelConf
[2] http://www.lfsforum.net/showthread.php?p=1603971#post1603971