Hmm, this correlates with my observation of G25. I tried to analyze what happens when you switch the pedals from combined to separate in the logitech software, but i could not see any specific USB traffic. So this also seems to be a "software-only" switch in the Logitech driver, not in the actual device.

Quote from MadCatX :

Nice, how did you find out about that? If I get it right, the NOGET flag tells the HID core to not poll the device upon connecting but rather wait until the device reports its status by itself?

To be honest adding that flag was my first guess without really understanding what it does. Because it is also set for the basic Logitech wheel

Quote from MadCatX :

I'll take another look on the range setting for range <201, I suppose it won't be a big deal to make it right.

EDIT: Just tried the LG_NOGET patch on the 2.6.39 (it's been out for a couple of hours, even the BFS is available already ) and... it WORKS! It would seem that the last thing to do is to get separate throttle/brake axes working. I suppose we could modify the module and make it create two devices in /dev/input, one reporting separated and the other combined axes.

Hmm, i did not try the pedals at all yet I assumed they should be automatically separated in native mode. Why do you think this requires kernel-side changes? Is this not a property of the DFP device itself if it reports combined/separate axes?

Quote from MadCatX :

To make matters rather interesting, I think I figured out the formula to construct range setting commands for DFP. According to my logs the Logitech driver always sends F8 03 (or F8 02 is the range to set is 200 deg or less) command followed by the command that specifies the range.

Please check out the attached PDF for details about the range specifying command. It's not exactly a PhD thesis, but I hope it'll be useful

EDIT: To make my forensic investigation actually useful, I attached a patch for LTWC which (surprise!) seems to work! It works with 201+ degrees ranges only, but it's a good start

EDIT2: Uploaded a patch in proper format

EDIT3: Third time does it I fixed 2 typos in the PDF and added a bit broader description of the "algorithm".

Wooho, great work! I just integrated your patch into LTWC and it is working fine. I added also support for setting ranges < 200 degree (but it seems the range calculation is not really correct here, e.g. setting a range of 100 results in effective ~50-60 degrees)


And even more good news:
There is a really simple kernel patch necessary to fix the "parse failed" kernel errors. The DFP needs the flag "LG_NOGET" added - thats all

Change in drivers/hid/hid-lg.c this line:

to that:

and rebuild the modules.

I am waiting for the kernel 2.6.39 to be final, then i will provide a proper patch and cross fingers it gets integrated

I got the DFP yesterday, only had time for a quick check - I can fully reproduce the trouble reported by MadCatX. Now i am trying to understand how the hid-drivers in kernel work :-)

Edit: By the way i am surprised that the DFP has a kind of hardware rotation limitation? It seems there is a mechanical limit at 200 degrees that you can clearly hear when being (de)activated. Is this true?

Small *bump* - Beginning of next week i should finally have a (slightly broken) DFP in my hands (thanks to Ebay :tilt. So there is hope i can probably sort out the problems reported by MadCatX...

Quote from MadCatX :

In any case, it appears that we need to figure out the formula for DPF range setting commands, changing just the prefix doesn't seem to work...

MadCatX, maybe you could log the USB traffic when setting different wheel ranges from the Logitech control panel? I am sure we can find the correct formula when we have a few more samples.
I would do that myself, but still have no access to DFP wheel here (still working on it - with some luck next week...)

Interesting thing from the usb log of the DFP:

At timestamp 7:43:38.335 driver issues this command:

This is the prefix to set wheel range, but with all other bytes zero'ed instead of range value.

Immediately afterwards another command is sent:

I have no idea what this command is for, but as previous command does not include any reference to rotation degrees this might be encoded here?

Thanks for the info MadCatX
Indeed this looks like a kernel issue. Which kernel are you running? Are the patches from slim.one for G25/DFP support already included?
If yes we probably need to get engaged in kernel hacking. Maybe some of the "quirks"-flags from lg-ff.c need to be set...

@slim.one: As you are probably already more into kernel hacking Any idea?

Quote from MadCatX :

I have a small suggestion regarding autocenter though, I find it rather superfluous to specify ramp speed when centering force is set to 0 - you want to disable autocenter. Perhaps something like would work?
(code snipped)

Definitely good idea, will do this in the next update

Quote from slim.one :

hm, maybe for udev there should be an option to append the usb bus- and device-number ltwheelconf should use - this way one udev-rule would suffice for all Logitech wheels, since they all connect with the same id. Or we screw udev completely and make a nice GUI for ltwheelconf

(edit: since --list successfully recognizes my G27, specifying bus and device should enable ltwheelconf to use the right commands for each wheel)

Problem is i do not know (yet) how the Logitech driver recognizes that a connected wheel is in reality not a DF but a G27 in restricted mode. It must query some other parameter besides PID and VID (and i assume/hope it does NOT rely just on the name string reported by the device... ). With this knowledge the --wheel parameter could be obsolete again and the whole process could be very well automated.
...Or maybe i did not fully understand your point

Quote from MadCatX :

Yes and no. The problem occurs when I attempt to set range, but it's not the only case. Actually any command I send after the "set to native mode" command triggers the error. I can provide you with dmesg log if you'd like. If you get your hands on a DFP, let me know if I can be of any help. What tools are you planning to use to check the USB traffic? Perhaps I can get some useful data for you...

dmesg output would be welcome And if you have the possibility to create a USB traffic log when the device is plugged in on Windows and e.g. wheelrange is set to different values it would be even better. Regarding USB analyzer tool i do not yet have an opinion - Most tools i saw sofar are quite expensive but offer some trial mode.
I will do this myself when i get hands on a DFP but it is not confirmed yet if/when i get it

Quote from MadCatX :

A GUI frontend like Logitech Control Panel would be nice. I might pull something off when MikeB's LTWheelConf get some stable CLI...

This would be awesome But i think it will take some more time untill the CLI is kind of stable...

Okay, i just pushed new version 0.2.2 to github containing the new command to set G27 into "real" native mode.

Also new:

• Command --list to get an overview of found/supported devices
  
• Mandatory parameter --wheel where you have to specify which wheel you have connected
  
• Prepared to support (theoretically, but not tested) the following wheels:
  • Driving Force
    
  • Momo Force
    
  • Driving Force Pro
    
  • G25
    
  • G27
    
  • Driving Force GT
    

As always I am curious about your feedback

Quote from slim.one :

Hi, nice work. The G27 needs a different initialization, i just managed to get it to reconnect with the right USB ID (046d:029b). But since the G27 isn't listed in the kernel, it isn't reported correctly by the kernel and thus gets not recognized as a wheel/joystick by wine (i wonder how the G25 should work without a patched kernel, because the wheel shouldn't have FF support, but if it works... i'll just shut up ). I'll try to get the G27 integrated into the kernel as well, no idea in which version it'll be included tho.

As for LTWheelConf, the initialization bytearray(s) for the G27 are:
0xf8, 0x0a, 0x00, 0x00, 0x00, 0x00, 0x00
and
0xf8, 0x09, 0x04, 0x01, 0x00, 0x00, 0x00
They have to be sent in this order instead of only one bytearray for the DFP/G25.

Nice find i will integrate this into LTWheelConf asap.

Quote from MadCatX :

I tried the kernel-oblivious autocenter adjustment and it works, nice I suppose you haven't noticed any change regarding the "parse failed" and "probe failed with -110 error"? That is really a showstopper for me...

Nice to hear the autocenter works on DFP also, thanks for testing

Quote from MadCatX :

I suppose you haven't noticed any change regarding the "parse failed" and "probe failed with -110 error"? That is really a showstopper for me...

Are you referring to the problems with setting wheel range on DFP? With some luck I'll have a DFP available here for testing within the next week. I am confident to get it running when i can have a detailed look at the usb traffic

Quote from slim.one :

As for LTWheelConf, i found an error in the Makefile which prevented it from building here; instead of
gcc -Wall -lusb -g3 -o ltwheelconf ltwheelconf.c
it has to be
gcc -Wall -lusb-1.0 -g3 -o ltwheelconf ltwheelconf.c
for my gcc to work.

Hmm, looks like i should go check the autoconf tools and have a proper ./configure command to prevent trouble like this. I hate it

*Bump*
There is now a "native" implementation of autocenter settings which does not rely on kernel 2.6.39 anymore and as a bonus allows finer control of behaviour by also providing a setting for the rampspeed.

MadCatX: I am very curious if this also works on your DFP, as i only have a G25 here. Could you give a try to the latest version if the autocenter and rampspeed settings work on your side?

In case it is not working the old implementation is still available through parameter "--altautocenter".

Quote from MadCatX :

Good work, I like the autocenter and gain settings. Might I suggest increasing the delay when attempting to set the wheel to the native mode? 1 second is definitely not enough for my DFP (I used at least 3 when I was toying around with this)

Thanks for the feedback In the next version I'll increase the waiting time to 3 seconds after sending the wheel into native mode.

Quote from MadCatX :

EDIT:
I just realized that I saw this on VDrift forums. Can you test it with your G25, because neither this nor your code set the range properly on my DFP.


int16_t range = 900 // 16-bit integer representing degrees to set range to
command = [0xf8, 0x81, range & 0x00ff, range & 0xff00, 0, 0, 0]


Not working here, without the bitshift the maximum rotation is around 250 degrees - Probably an overflow problem.

Hey guys,

based on your and vdrift forums work and research i created a tool to setup the logitech wheels on linux -> See this thread for details.

Let me know if it works for you :-)

This is for anybody who wants to use his Logitech wheel to its full potential on Linux. For example running LFS through wine

Based on discussion and code in this thread and some more info in the vdrift forums i created a tool to configure the wheels correctly on linux.

From the Readme:

Quote :

This tool allows you to change various settings of the Logitech racing wheels
-> Driving Force Pro (DFP)
-> G25
-> G27

Available options:
-> set wheel to "native" mode (support separate axes and clutch pedal, full 900 degree rotation)
-> Set wheel rotation range
-> Set autocenter force and rampspeed
-> Set ForceFeedback gain

Credits:
Based on:
- Original "G25manage" as part of the vdrift driving simulator (http://vdrift.net)
- Modified "G25manage" posted by slim.one on the lfsforum (http://www.lfsforum.net/showthread.php?p=1564187#post1564187)
- Various Information & research from vdrift forum: http://vdrift.net/Forum/viewto ... tdays=0&postorder=asc

The code is GPL'ed and hosted on github:
https://github.com/TripleSpeeder/LTWheelConf
Currently there are no binaries provided, but it is really easy to build. Just download & extract the sources and type "make"

With this tool and the latest kernel 2.6.39 LFS runs perfectly with all features also on Linux (through wine)

Edit:
-> Developed & tested on Arch linux x86_64
-> I only have a G25, so i could not test if it really works with DFP/G27

Last edited by MikeB, Fri 29 Apr 2011, 08:51. Reason : changing autocenter does not rely on kernel 2.6.39 anymore :-)

Quote from MadCatX :

I'm afraid it's not that simple. Even G25manage cannot properly deal with separate throttle/brake axes because of the rather unusual way the wheel sends throttle and brake position when they're separated. (at least in case of DFP).
There is also a bug in the HID stack that causes my DFP to disappear from /dev/input when I set it to native mode with 0x01 and 0x03 commands (sending them in the opposite order somewhat works though).

Separate axes works fine with the G25 here. But i have the same problem of disappearing input device after setting native mode. But this can be fixed by reloading of some usb modules:

If you do this after setting the wheel to native mode/full range it is available again in dev/input. I tried to put this into the udev ruleset so it happens automatically after plugging it in, but didn't get it to work yet...

Also the autocenter issue i did not try to fix yet - maybe i find some time to build a patched kernel, or i'll just wait for 2.6.39 to be released

But there is another issue: I need to recalibrate axes everytime LFS window loses focus and whenever i change FF setting, which is quite annoying.
Any idea how to prevent this?

Hey, this is seriously good news! :-)

Quote from slim.one :

Disabling autocenter will work with kernel 2.6.39 and above (at least i hope i gets commited soon enough).

Did you already get feedback if the patch will make it into the 2.6.39?

Edit: Just noted that current Wine release available for my distro (Arch linux) is alread 1.3.18. Does this mean that no more patches are necessare there?

Last edited by MikeB, Sun 17 Apr 2011, 21:35.

Quote from troy :

fixed, you shouldn't take the german lfs forums so serious. Especially that one thread only consisting of moaning, sarcasm and bad jokes.

Ohh, come on you grinch

Sorry guys, currently i have absolutely no time to care for TeamStats. I know that the update is not working for quite some time now, but had no chance to sit down and figure it out.
Probably i will take the site down, because with obsolete data it does not make sense at all. Rather be offline than display wrong data...

Quote from St4Lk3R :

On the other hand, 10/10 to this thread. It's funny on one hand, but on the other, it kinda makes me sad.

Couldn't say it better. I laughed my ass of reading this, on the other hand there's a quite feeling of sadness. Anyway, whatever the future might bring with LFS - This is one of the best threads in a long time :smileyrai

10/10 Thanks Guys

Come on, what is this about? Do you have a website or anything else? Some description of the whole thing? Being at work i can not connect to the server

Quote from kaynd :

I get the “parsing failed!” error message, every time I try to load a replay in mpredit.
Does anyone else have this problem?
I am using win xp sp2 and I extracted the program with it's 3 dll in the same folder. It brings the same error message even with patch Υ replays so it has to be e problem in my end

Thats strange If you can send me the replay i'll have a look at it.

Edit: Or is it happening with ALL replays?

Agreed that it may be unrealistic as hell. But nevertheless it would be awesome if you can literally "feel" when the wheels stop turning. I imagine it would work like this:
Apply brakes -> pedal vibrates
wheel starts slipping -> decrease vibration
wheel completely stops -> stop vibration

This way you could "balance" on the maximum brake force just by feel in the foot! When you sense a decrease of vibration you just release the pressure a little bit until the vibration comes back at full volume.

I see only one issue here - You have 4 wheels, each one having a separate grip level at any given situation. I am not sure this could be handled well with only one way of feedback. Think of the rear inner wheel, sometimes not spinning at all because it just has no contact to tarmac during braking/turning in...?

Ahh, thanks for the info
Regarding the session (practice/qualy/race) type: I think I already found where it is stored (somewhere later in mpr file).
Maybe this would be useful to include in the officially documented mpr header?