DFP on Linux - Discussion & Development

[bopApocalypse]

Hi folks!

I've been reading through some of the old stuff on here, and I think it's time to get the Logitech Driving Force Pro wheel working 100% under linux. With the work that's been done before, esp. the G25 stuff, I don't think it should be too hard.

What I've gotten so far:
* Using this info and tof8pool's kernel patch, I've added the unique hardware ID for the DFP to the kernel. I'll try to make an actual patch later - basically, take the 2.6.28 patch, s/299/298/, s/G25/DFP/

* Grabbed the G25manage app, tweaked it to use the few known DFP commands.

At this point, I can put the wheel into native mode & set 900 deg rotation. As soon as I put it into native mode, the device (/dev/input/event4) disappears [as semi-expected]. My impression was that the kernel changes would take care of this, but apparently not.

DFP initial plug-in

Code:

usb 4-1: new low speed USB device using uhci_hcd and address 3
usb 4-1: configuration #1 chosen from 1 choice
input: Logitech Logitech Driving Force as /class/input/input5
logitech 0003:046D:C294.0002: input: USB HID v1.00 Joystick [Logitech Logitech Driving Force] on usb-0000:00:10.2-1/input0
Force feedback for Logitech force feedback devices by Johann Deneux <johann>

Sending [0xf8, 0x01]

Code:

mahayana G25manage # ./G25manage --verbose --nativemode
Device opened
Kernel driver released
USB interface claimed
USB command sent
USB interface released
usb_rebind_kernel_driver_np: no device found to rebind to kernel
usb_rebind_kernel_driver_np: -19 No such device

dmesg:

Code:

usb 4-1: USB disconnect, address 3
usb 4-1: new low speed USB device using uhci_hcd and address 4
usb 4-1: configuration #1 chosen from 1 choice
logitech 0003:046D:C298.0003: timeout initializing reports
input: Logitech Logitech Driving Force Pro as /class/input/input6
logitech 0003:046D:C298.0003: input: USB HID v1.00 Joystick [Logitech Logitech Driving Force Pro] on usb-0000:00:10.2-1/input0
Force feedback for Logitech force feedback devices by Johann Deneux <johann>

sending [0xf8, 0x03]

Code:

mahayana G25manage # ./G25manage --verbose --range=900
Device opened
Kernel driver released
USB interface claimed
USB command sent
USB interface released
Device opened
Kernel driver rebinded

dmesg

Code:

logitech 0003:046D:C298.0004: parse failed
logitech: probe of 0003:046D:C298.0004 failed with error -110

Code:

mahayana G25manage # rmmod joydev; rmmod hid_logitech; rmmod usbhid; modprobe usbhid
mahayana G25manage # ls /dev/input/
by-path  event0  event1  event2  event3  mice  mouse0

Obviously, the problem is in the 'no device to rebind' error - for whatever reason, the new device at 0xc298 isn't showing up - even though it seems to be according to dmesg.

Any tips or thoughts are appreciated, I just started digging in to this, so haven't exactly done all the research I should've. I'll keep digging in my spare time, and hopefully learn a thing or two and make some progress.

//Also, I'm going to start hacking on a new user space util, hopefully one that can deal with both G25 and DFP. Or at least make my own DFPmanage program...

[joevenzon]

I don't know enough to help out, but good luck and keep us up to date! :-)

[thelusiv]

You might want to read this post and some of the other information in that thread. I never did get anywhere with that, I know very little about kernel hacking and linux input. I did my best to get some information and tried to give it to the linux-input people but nobody did anything with it. I still have my DFP so if you ever get anywhere let me know and I'm happy to do some testing.

[bopApocalypse]

well, little bit of an update...

hacked up the code to be dedicated to the DFP - it'll be easier right now, ATMO, to just maintain two separate tools to manage the two separate devices.

I found that, at least on my system, the attempt to rebind was just happening too soon - by increasing the sleep() call, the --nativemode works just fine - /dev/input/event4 reappears. [or, simply running DFPmanage --reconnect after running --nativemode will do the trick too].

Not much progress from there though. Sending the commands to switch to 900 degree works (wheel can be turned 900 degrees), but after that, /dev/input/event4 disappears, and I get the same parse/probe errors as listed in my initial post.

running reconnect at this point doesn't do anything.

Guess now it's time to start really learning something about the linux USB HID layer...