Quote from lfsrm :

But I prefer to use my eyes to see the mirrors instead of turning my neck all the time to expend field of view, it's more natural for me.

Yes, that's definitely true. The limited FOV is more annoying than the low resolution in the CV1. In real life I have a FOV of almost 180 degrees, especially detecting movements is easy. From the corner of my eyes I can immediately recognize movements that happen left or right of me. With the CV1 this is not possible. I constantly need to turn my head just to check what is left/right or to glance in the mirrors.
So there is still a lot of improvmements possible for the Generation 2 VR headsets

Did you experiment with pinning individual instances of LFS to specific cores? Maybe this can help reduce the occasional judder/fps drop.

Anyway, that's a very interesting project

Quote from cargame.nl :

And after that it collects dust or get sold to someone else who tries everything out.. Not very structural.

Lol, once you exprienced some close racing in VR there is no going back. The immersion and presence is breathtaking, there is no going back ever to Simracing with a flat screen. For me that's like watching a race on TV compared to actually racing.

The CV1 is what brought me back to LFS since several years. And it's working very good. But you know what? After enjoying a few nice races in LFS with the CV1, iRacing added support for it. I reactivated my license there just to try VR. And the races there were not just nice, they were great. Long-distance, perfect match-making, and you have the feeling that you are actually racing for something "larger" compared to the endless 5-laps pickup-racing with the same combos on the public LFS servers.

So you can still count me to the long-time LFS lovers that are disappointed by the devs decisions and therefor moved on. So many chances missed, it is very sad. Still the fact that i regularly check this forum means I still love LFS for all the great times I had. And there is always a little hope that I see an unexpected announcement that convinces me to get S3...

I think having the mirrors flat rendered instead of 3D is a bigger problem than i expected. Several times i tried to move my head around to see if there is something hidden in the blind spot, but of course no luck as mirror image does not take into account head position

So in case you are still working on VR improvements please put this on the todo-list
(And while at it you could make the mirrors adjustable )

Also spent some hours now back in LFS with my Oculus CV1. Overall great experience, but like Eddy said - it would be awesome to be able to move the HUD elements (like damage, tire wear, etc) around. Right now the float somewhere within the interiour, so this is a bit distracting.

I think this was mentioned before, but as Victor seems to be really active at the moment I'll give it another shot - It would be totally awesome if external sites could rely on LFS as an auth provider, so users could sign in using their LFS credentials and at the same time prove their LFS identity.
I am shuffling around some LFS-related ideas again after a long absence, and this would really open up some possibilities...

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...

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 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 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)

Last edited by MikeB, Sun, 26 Jun 2011 20:17.

Wow, 2 weeks vacation and some good progress here
@MadCatx: I'll check your tool with the Momo racing, for DFP and G25 you have everything already, right?

Probably the same issue with combined axes is existing there. I got now a Momo racing at hand - Same situation like with the DFP. The report descriptor needs to be updated to make the separate axes available to the system.

Problem i see here is that so many wheels are using the same IDs (some with different revision, some not, and also count in the various wheels in "fallback" mode) so i do not think we can just replac the report descriptor like we did for DFP. At least this should be tested then with ALL affected wheels.

PS: The patch for DFP is now accepted and will be part of linux 3.0

PPS: I'll be on vacation the next two weeks without internet

I am still looking to find a way to reliable auto-detect the connected wheel. Current idea is to go for the usb device revision number.

Problem is that basically all usb device properties change between restricted and native mode, but it seems the revision stays the same (and is different at least between DFP and G25...)

DFP always reports revision "1106"
G25 always reports revision "1222"

@Slim_one: Could you check the revision your G27 is reporting in restricted and native mode?
Command would be:

Please look for the line "E: ID_REVISION=<some number>".

If this turns out to be working we could soon get nice integration with udev, like slim_one suggested already: Udev knows adress and the revision of connected device, so with only one rule you could set any supported wheel to native mode automatically.

Quote from MadCatX :

As for the range setting, I guess the 200 - 900 range algorithm is as simple as it can get accoring to my USBLyzer captures, not sure what to do with the <199 range, whatever strange maths is behind it, it eludes me

I pushed a new version just now including your changes. Additionally some small refactoring and introduced per-wheel setting for minimum/maximum rotation range (DFP being set to min 200 now ).
And added report descriptors for both DFP and G25 just for reference...

Okay, new patch submitted - *Crossing fingers* :-)

Quote from MadCatX :

It's also necessary to run "jscal" and calibrate the device every time the wheel is switched to the native mode. Unless it's done, there are pretty nasty deadzones on all axes and pedal axes are inverted. Do you observe this problem with G2x too? I'm thinking about calling "jscal" from within LTWC and set the corrections manually. Unless someone has a seriously borked wheel, I don't see a problem with using a "default" set of corrections. If it's needed for more devices than DFP, it might be a good idea to have an extra function for that...

This is an interesting question. Here i have a quite strange situation - Each axis is visible twice in LFS - One has a big deadzone, the other one behaves perfectly.

slightlymoved.png: shows that the upper axis already moved, while the lower one still sticks to zero.
quartermoved.png: The second axis starts moving and catches up with the first one a few degrees later.
allmostfullmoved.png: The upper axis is still not near the end, but the lower axis is "accelerated" somehow to already be close to maximum.

This happens with DFP and G25, both in native and restricted mode. I did not bother with this topic yet as i can always select the "upper" axes which show absolutely no deadzone.
Do you also have these double axes?

Quote from MadCatX :

EDIT: Patch1 incoming

Applied and working fine Only thing is the case of rotation < 200 degrees is not handled. And the math still looks frightening There must be some simpler way to calculate the correct values

Quote from MadCatX :

Tried the updated patch and it seems to work fine. All buttons, axes, hat switch and FF are perfect, so I guess it's ready to challenge HID maintainers' high standards...

Thanks I'll submit new patch tonight (if i don't have to stay too long at work )

After some discussion on linux-input mailinglist here is a smaller patch (less comments and optimized descriptor)

@MadCatX: As my DFP buttons are broken could you please check this patch also to see if all buttons work? Then i will submit it again to linux-input...

Quote from slim.one :

no, i didn't.

btw, is the complete bytearray needed? Can't this be reduced to the changed values, like its done in function lg_report_fixup?

Not really - I know that this does not really fit with the other parts of the report_fixup, but as the new descriptor is much longer than the original one, patching it would be difficult.
I'll post it to linux-input and see whats their opinion. There are other hid-drivers which also do a complete replacement and have been accepted...

Good find!
Last thing: Should we rename then the "Rz" to just "z"? So we have X,Y,Z axes instead of X,Y,Rz?

@Slim_one: Did you already submit the patch with the NOGET flag? If not, i can include it then with these changes as one patch. I think i will submit it as soon as the last question above is cleared...

So, to rule out/confirm the obvious: Does FF work in native mode without my patch?

This sounds strange... I have the following rules setup for udev which seems to work fine in all cases (user has to be member of "games" group):

This also gives me a correct symlink showing which wheel is connected/recognized

Maybe this helps?

Edit: This is how it looks with a DFP in native mode:

Last edited by MikeB, Thu, 26 May 2011 22:13. Reason : Add output of ls -l /dev/input

GOT IT

Please see attached patch for hid-lg.c driver - It replaces the HID descriptor for DFP in native mode:

• remove combined Y-axis
  
• Add Z and RZ axis for brake and throttle
  

Probably you have to remove the last few lines which add the NOGET flag as you already have this change on your codebase.

Funny enough i can not really test it with LFS atm as i did not yet bother to get nvidia driver with the new kernel and nouvea is not yet usable for any game

Please also try if all other buttons still work like expected - On my broken DFP only the shifter is working, the buttons on the wheel are dead...

Quote from MadCatX :

Sure, but figuring it out would be a nice ego booster Getting the separate axes working is much more important tho, any chance you might have or get some info as to how to map the custom fields in the HID descriptor to axes? My simple lame experiments turned out ineffective...

I'm currently playing around with rewriting the HID descriptor of the DFP to make the separate axes available "native" to the driver. In theory i read enough to know how it should work, in practice i hope to get first results tonight. I'll keep you posted

Quote from slim.one :

i can arrange that if you like (you still will be credited )

This would be great, i am currently so busy with work - I did not even install 2.6.39 yet So please go ahead - as i read the merge window will be somewhat shorter for the next linux version...

Quote from slim.one :

did anyone test that on any other wheel? i think this should generally be a good idea to add that flag to all logitech devices, which reconnect after initialisation.

Hmm, at least the G25/G27 do not require this change. So i would rather not add this flag by default - Let's try to get some more enduser feedback
My brother has a Momo Force, i try to get some feedback from him...

Yep, this did not let me go to sleep :-) Accessign the hidraw interface i can get the seperate values from the DFP:


Usage (assuming compiled executable is named dfp_test):

This data is basically derived from the HID descriptor provided by the DFP through /sys/kernel/debug/hid/<hid-device>/rdesc. There you can see that "offically" reported are only two axes, but additionally there are three more "anonymous" fields starting at byte 5.

Tomorrow i'll have a look at "hidinput_configure_usage", but for now its enough :-)