Quote from MadCatX :

It's kinda necessary to clean up the mess, so there goes another tool whose purpose is to check if at least some commands are supported by all LG wheels. The tool tells you what effect is expected to be generated. It can also send a fully custom command when run like "-c AABBCCDDEEFFGGHH".

Logitech Momo Racing supports all commands (Had to add ID 0xCA03 to device_ids[])

Edit:
G25 supports all commands, but assistance effect itself is too aggressive, wheel just starts to rotate from limit to limit endlessly unless i am holding it. (Tried both DFP and native mode with 900 degrees)

Testing with MOMO would be great, except for that and DFGT we have pretty much everything (I believe that there's no difference between G25 and G27). Simon Wood tested this tool with his Wii wheel and he sent me a slightly modded version of my tool. He had to limit the number of sent bytes to 7, otherwise the Wii wheel went all crazy. I attached his modded tool, so please try that one instead of the original version.

While you was (hopefully) insanely enjoying your holiday, I was stuck at home and came up with these two patches for LTWC.
(I accidentally almost deleted one of those, now I see that the Trash Can was invented for a reason:tilt

Quote from lbodnar :

Is it possible to see enumeration dump for G27 wheel including descriptors?
I can't find it anywhere and I don't have a wheel to check.

sure. How can i do that? google isn't too elaborate on this topic...

"mount -t debugfs none /sys/kernel/debug"
"sudo cat /sys/kernel/debug/hid/000x:046D:029B.000y/rdecs > g27desc.txt"

leo, do you think it might be possible to get the rpm indicator led's working, too? As i understand it, you have done some work in that field, too

i'll get you the dump when i'm back from work.

I can't speak for Leo, but AFAIK the LED commands are sent like custom force feedback commands. Some time ago I wrote a simple hack that allows LFS to send such commands to G27. If anyone with who actually has G27 can grab the source and sniff what is really sent to the wheel, it'd be just a matter of adapting the kernel driver.
If there's anyone up to the job, I suggest ripping out the OutGauge interface and replacing it with something that allows you to set custom "FirstLeds", "Redline" and "RPM" values (read the source to find out what the world I'm talking about here )

Dump is attachjed.

if you want it dumped from windows, i can arrange that, too.

Quote from MadCatX :

Testing with MOMO would be great

Works fine (In case you missed my previous post ;-)

Quote from MadCatX :

While you was (hopefully) insanely enjoying your holiday, I was stuck at home and came up with these two patches for LTWC.
(I accidentally almost deleted one of those, now I see that the Trash Can was invented for a reason:tilt

Patches integrated - Thanks

Quote from MikeB :

Works fine (In case you missed my previous post ;-)

I didn't exactly miss it, you were just way too fast for me with the testing and replying Did you test with Simon's enhanced version too?

Too bad that wolfshark isn't around, it'd be great to know if it works for him too. The only thing that I think needs resolving before we can turn all this knowledge into a patch is how to handle the FF_SPRING effect. Its behavior differs on my DFP depending on whether the set range is <40;200> or <201;900> deg.

BTW anybody has an idea if the Windows driver recalculates the FF_SPRING command somehow if the wheel is set to less than 900/200 deg? My gut tells me it should 'cause the programmer of FF effects in game doesn't know the real range of the wheel, right? So if the tells the wheel to do FF_SPRING with 720 deg deadzone, player wouldn't feel that effect at all if he limited the range to 720 deg. I hope you get what I mean...

Quote from MadCatX :

I attached his modded tool, so please try that one instead of the original version.

Effects work on the G27, tho i don't feel a big difference between the different FF_FRICTION effects. But since i'm not a scale, i'm not quite accurate in measuring :-)

Quote from lbodnar :

Yes, please! Can you post the device descriptor too?

first part: http://team-infinity.ath.cx/slim/G27_lsusb.txt

Since i don't have a clue how to get that under windows, could you please be a bit more specific and explain that to me? Thx :fluffy:

Quote from lbodnar :

It should show all the communication details in the log. Then you can export the log as html file.

I did that some time ago (page 2? in this thread ) - here is the log (see attachment)

Quote from MadCatX :

Too bad that wolfshark isn't around, it'd be great to know if it works for him too.

I will be - maybe Friday or Saturday. I really can't test anything now.

Attention G27 owners! Since it looks like we're going to rewrite the whole driver, we might as well try to add support for those fancy G27 LEDs. I expect the Windows driver to send a single command with three bytes containing the actual RPM, RPM when the first LEDs light up and the redline RPM. (I might by totally wrong of course )
I attached a simple app that allows you to send RPM data to G27, could you give it a try and sniff the output? EXE is in the Debug dir BTW. (It's a quick and dirty hack, but as long as out type unsigned integers only to the input fields it should do the job)

Short update from my side: Although we are discussing on general better integration into the kernel i expect that this will take quite some time, so i still continue on improving ltwheelconf.
On my local copy i have already working udev integration and automatic wheel type detection (based on the revision number). So currently one udev rule is enough to automatically switch DFP, G25 and G27 into native mode

However i stumbled upon a problem with wheels that do not have restricted/native mode: I tried a udev rule to e.g. automatically set the range of the Driving Force to 180 degrees at plugin. But as ltwheelconf needs to disconnect the kernel driver in order to send the special command for setting the range i ended in an endless loop - Because as soon as the kernel driver is attached again, an udev event is triggered again resulting in ltwheelconf being called again... You get the picture
But still for the main problem/usecase "switch to native mode automatically" the udev rule is fine :-)

Quote from lbodnar :

F8 12 xx
xx = [---43210]
LEDs arrangement on the wheel:
[bit0][bit1][bit2][bit3][bit4][bit4][bit3][bit2][bit1][bit0]

I kinda hoped that the wheel does a bit of maths on its own, but never mind. Thanks a bunch!

I began the work on the driver BTW. I want to get the /sys interface done and make sure it's working as it should. I'll post the patch once I'm done with that.

...a couple of kernel panics, reboots and mugs of coffee later...

OK guys, there is the first proof-of-concept version of reworked version of lg4ff patch. It's applicable to 3.0-rc5 and depends of MikeB's DFP descriptor patch and DFGT patch.

"Advanced" features like the range setting is available only for DFP now as I don't have any other wheel to test with.

EDIT: Attachemens deleted, there's now a newer version of the patch which is somewhat DFP-specific. If you want to try it out, please PM me.

Quote from MadCatX :

...a couple of kernel panics, reboots and mugs of coffee later...

OK guys, there is the first proof-of-concept version of reworked version of lg4ff patch. It's applicable to 3.0-rc5 and depends of MikeB's DFP descriptor patch and DFGT patch.

"Advanced" features like the range setting is available only for DFP now as I don't have any other wheel to test with.

Nice work :-) I'll check it out asap, but probably not before the weekend...

OK guys, I think I've made another thing that could qualify as progress. I got the automatic native mode switching working in the kernel driver. Right now it's working for DFP, G25 and G27 only. If you guys can test the patch or provide me with USB revision numbers for other wheels it would be very helpful (you can find USB revision like this).

Logitech Formula Force EX

Quote from MadCatX :

OK guys, I think I've made another thing that could qualify as progress. I got the automatic native mode switching working in the kernel driver. Right now it's working for DFP, G25 and G27 only.

Nice!

Can i patch this against an actual git-kernel or do i need further patches? Haven't tried yet.

It needs MikeB's DFP descriptor patch (kernel-git compliant version available at patchwork.kernel.org), but otherwise it should apply fine.

Yet another update containing few bugfixes and improvements. There's also preliminary support for FFEX autocentering (not exactly working though).
Both incremental and full patches attached.

This patch works with 3.0.X? I might try it soon.

It actually doesn't apply to anything else than 3.0.0 kernel