search

berarma / new-lg4ff

Experimental Logitech force feedback module for Linux
GNU General Public License v2.0
298 stars 18 forks source link

Is support planned for the new (direct drive) Logitech G Pro Racing Wheel? #82

Open condaatje opened 10 months ago

condaatje commented 10 months ago

very keen to see this device working with full integration, force feedback etc on linux. Let me know what can do to help. diagnostics below:

device is recognized

cat /proc/bus/input/devices
...
I: Bus=0003 Vendor=046d Product=c272 Version=0111
N: Name="Logitech  PRO Racing Wheel"
P: Phys=usb-0000:06:00.3-2.1/input0
S: Sysfs=/devices/pci0000:00/0000:00:08.1/0000:06:00.3/usb1/1-2/1-2.1/1-2.1:1.0/0003:046D:C272.0003/input/input17
U: Uniq=2319WD040908
H: Handlers=event15 js0
B: PROP=0
B: EV=1b
B: KEY=fff 0 0 0 0 0 0 ffff00000000 0 0 0 0
B: ABS=300fd
B: MSC=10

Force feedback tests fail

fftest -d /dev/input/event15

Force feedback test program.
HOLD FIRMLY YOUR WHEEL OR JOYSTICK TO PREVENT DAMAGES

Device /dev/input/event15 opened
Features:
  * Absolute axes: X, Z, RX, RY, RZ, Throttle, Rudder, Hat 0 X, Hat 0 Y,
    [FD 00 03 00 00 00 00 00 ]
  * Relative axes:
    [00 00 ]
  * Force feedback effects types:
    Force feedback periodic effects:
    [00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ]
  * Number of simultaneous effects: 0

Uploading effect #0 (Periodic sinusoidal) ... Error:: Function not implemented
Uploading effect #1 (Constant) ... Error: Function not implemented
Uploading effect #2 (Spring) ... Error: Function not implemented
Uploading effect #3 (Damper) ... Error: Function not implemented
Uploading effect #4 (Strong rumble, with heavy motor) ... Error: Function not implemented
Uploading effect #5 (Weak rumble, with light motor) ... Error: Function not implemented
Enter effect number, -1 to exit
0
Now Playing: Sine vibration
Enter effect number, -1 to exit
ffcfstress -d /dev/input/event15

ERROR: device (or driver) has no constant force feedback support [ffcfstress.c:194]

these results appear to be the same between the default kernel (latest arch - 6.4.12) and new-lg4ff dkms module (as installed from aur with yay)

berarma commented 10 months ago

Do you know if the device is compatible with XBox? Can you post a link to the exact product page?

There are two protocols used until now by Logitech, the one used on Playstation compatible wheels and HID++ used in XBox compatible wheels. New-lg4ff is for the former protocol. If it uses that protocol the vendor and product ids should be added to the list of supported devices so that the driver at least tries to load. But first we should make sure it's this driver and not the HID++ driver that we should try to use.

motolav commented 10 months ago

@condaatje both lg4ff and HID++ drivers need device IDs explicitly declared, if you're able to compile your own drivers you can follow this commit in the kernel to modify the HID++ driver to add support for your wheel https://github.com/torvalds/linux/commit/e8ab7a10edc7d071f64d8a8352b88e7d7477854a (assuming it doesn't require any wheel specific changes). If your wheel uses lg4ff it could be a bit more complicated to add support here.

for example adding #define USB_DEVICE_ID_LOGITECH_G_PRO_RACING_WHEEL 0xc272 to drivers/hid/hid-ids.h then using that name to add support for that device to drivers/hid/hid-logitech-hidpp.c like in that commit

motolav commented 10 months ago

I'm not sure if did it right but I made a repo to test the HID++ driver with the changes I said just follow the same manual instructions as here to install it, https://github.com/motolav/new-logitech-hidpp/

if your wheel uses the same code as the G920 for initialization then it likely will work just those three lines of code

motolav commented 10 months ago

Do you know if the device is compatible with XBox? Can you post a link to the exact product page?

@berarma There's different 3 different SKUs for Xbox/PC, PlayStation/PC, and PC only

I found on PC Gaming wiki the USB IDs

PlayStation version: device name: Logitech G HUB PRO Racing Wheel for PlayStation and PC, HWID: 046D:C268 Xbox version: device name: Logitech G HUB PRO Racing Wheel for Xbox and PC, HWID: 046D:C272

@condaatje You need the HID++ driver likely so if the changes in my repo work then I could submit a patch to the kernel since its something simple and it might be in 6.6

berarma commented 10 months ago

I'm not sure if did it right but I made a repo to test the HID++ driver with the changes I said just follow the same manual instructions as here to install it, https://github.com/motolav/new-logitech-hidpp/

if your wheel uses the same code as the G920 for initialization then it likely will work just those three lines of code

Thanks!

Please, could you commit first the original files then create another commit with your changes so it's easier to see what's changed?

motolav commented 10 months ago

change to hid-ids.h

#define USB_DEVICE_ID_LOGITECH_G_PRO_RACING_XBOX_WHEEL  0xc272

change to hid-logitech-hidpp.c

{ /* Logitech G Pro Racing Wheel over USB (Xbox version) */
  HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_G_PRO_RACING_XBOX_WHEEL),
  .driver_data = HIDPP_QUIRK_CLASS_G920 | HIDPP_QUIRK_FORCE_OUTPUT_REPORTS },

Assuming the code to the Xbox G920 is generic to all of Logitech's HID++ wheels that should be what's needed for the G Pro Xbox wheel. There's nothing in the HID++ G920 code that necessarily seems model specific like lg4ff

condaatje commented 10 months ago

(for the record, this is the "PC" version of the wheel)

tried this custom driver out, seems like fftest is still not working

here's what I'm getting in the kernel logs (maybe I'm making a mistake?)

[Aug29 09:28] usb 1-2.1: new full-speed USB device number 10 using xhci_hcd
[  +0.148647] usb 1-2.1: New USB device found, idVendor=046d, idProduct=c26e, bcdDevice=33.03
[  +0.000010] usb 1-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  +0.000004] usb 1-2.1: Product: PRO Racing Wheel
[  +0.000002] usb 1-2.1: Manufacturer: Logitech
[  +0.000003] usb 1-2.1: SerialNumber: 2319WD040908
[  +0.150145] input: Logitech  PRO Racing Wheel as /devices/pci0000:00/0000:00:08.1/0000:06:00.3/usb1/1-2/1-2.1/1-2.1:1.0/0003:046D:C26E.0015/input/input25
[  +0.000149] logitech-hidpp-device 0003:046D:C26E.0015: input,hidraw2: USB HID v1.11 Joystick [Logitech  PRO Racing Wheel] on usb-0000:06:00.3-2.1/input0
[  +0.010928] logitech-hidpp-device 0003:046D:C26E.0016: hiddev97,hidraw3: USB HID v1.11 Device [Logitech  PRO Racing Wheel] on usb-0000:06:00.3-2.1/input1
[  +0.056537] logitech-hidpp-device 0003:046D:C26E.0016: Device not connected
[  +0.010892] logitech-hidpp-device 0003:046D:C26E.0017: hiddev97,hidraw3: USB HID v1.11 Device [Logitech  PRO Racing Wheel] on usb-0000:06:00.3-2.1/input2
[  +0.020544] Error: Driver 'logitech-hidpp-device' is already registered, aborting...

edit - the above readout is from connecting the device when it has been set to g923 mode through the OLED interface on the wheelbase. The only difference we were able to see between these logs and the logs of native mode (G PRO, not G923 mode) is in the idProduct field

for posterity, here is the readout when g923 compatibility mode is NOT enabled (default):

[ +15.883974] usb 1-2.1: new full-speed USB device number 7 using xhci_hcd
[  +0.148966] usb 1-2.1: New USB device found, idVendor=046d, idProduct=c272, bcdDevice=33.03
[  +0.000006] usb 1-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  +0.000002] usb 1-2.1: Product: PRO Racing Wheel
[  +0.000002] usb 1-2.1: Manufacturer: Logitech
[  +0.000001] usb 1-2.1: SerialNumber: 2319WD040908
[  +0.150687] input: Logitech  PRO Racing Wheel as /devices/pci0000:00/0000:00:08.1/0000:06:00.3/usb1/1-2/1-2.1/1-2.1:1.0/0003:046D:C272.0011/input/input22
[  +0.000279] hid-generic 0003:046D:C272.0011: input,hidraw4: USB HID v1.11 Joystick [Logitech  PRO Racing Wheel] on usb-0000:06:00.3-2.1/input0
[  +0.010314] hid-generic 0003:046D:C272.0012: hiddev98,hidraw5: USB HID v1.11 Device [Logitech  PRO Racing Wheel] on usb-0000:06:00.3-2.1/input1
[  +0.010924] hid-generic 0003:046D:C272.0013: hiddev99,hidraw6: USB HID v1.11 Device [Logitech  PRO Racing Wheel] on usb-0000:06:00.3-2.1/input2
motolav commented 10 months ago

That has a different ID, idProduct=c26e, so it wouldn't work with my repo yet the ID c26e matches the G923 so maybe its in G923 mode?

motolav commented 10 months ago

Somewhere in .driver_data = HIDPP_QUIRK_CLASS_G920 it's probably initializing the wheel into G923 mode so the G pro would need different code to start in the native mode since it's masking the wheel as ID c26e instead of c272

berarma commented 10 months ago

Is there any feature missing in G923 mode? I'm asking because maybe it's not worth making it work in the default mode.

motolav commented 10 months ago

the analog padals are lost but it since the driver loaded and set the wheel into G923 mode it is HID++ and I think I figured out what caused it to reset into G923 mode

~#define HIDPP_PAGE_G920_FORCE_FEEDBACK 0x8123 Likely the native mode for the wheel requires a different ID from the G920/G923~

JacKeTUs commented 10 months ago

It seems that G Pro wheel have different initialization sequence than g923, even in compatibility mode. Standart hidpp driver initialized inputs (with added vid/pids) just fine, and we with @condaatje see all inputs working in wine control joy.cpl

But standart hidpp driver can't initialize Force Feedback on any of the modes (g923comp and native one)

JacKeTUs commented 10 months ago

Somewhere in .driver_data = HIDPP_QUIRK_CLASS_G920 it's probably initializing the wheel into G923 mode so the G pro would need different code to start in the native mode since it's masking the wheel as ID c26e instead of c272

No, it does not. Switching to hid++ mode is made with usb_modeswitch package (https://www.draisberghof.de/usb_modeswitch/bb/viewtopic.php?t=2510). Kernel devs were against using initialization commands inside the drivers.

But G Pro with G923 compatibility modes tries to connect with g923 hidpp product id (0xc26e), no need to additional initialization command

condaatje commented 10 months ago

I think the earlier kernel messages I posted were in G923 compatibility mode by the way - when I connect now I see c272. @JacKeTUs and I did some experimenting and saw that there is little difference between g923 mode and native G Pro mode other than some inverted axes, an extra input or two, and the c26e ID change.

to clarify - I don't think any drivers are changing the compatibility modes. it was me in the course of experimentation.

JacKeTUs commented 10 months ago

Interestingly enough - without HIDPP_QUIRK_FORCE_OUTPUT_REPORTS wheel with native mode initialized some more - but missing inputs (?)

[Aug29 06:53] usb 1-2.1: USB disconnect, device number 4
[Aug29 06:54] usb 1-2.1: new full-speed USB device number 5 using xhci_hcd
[  +0.149430] usb 1-2.1: New USB device found, idVendor=046d, idProduct=c272, bcdDevice=33.03
[  +0.000013] usb 1-2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  +0.000007] usb 1-2.1: Product: PRO Racing Wheel
[  +0.000004] usb 1-2.1: Manufacturer: Logitech
[  +0.000004] usb 1-2.1: SerialNumber: 2319WD040908
[  +0.169504] logitech-hidpp-device 0003:046D:C272.0006: hidpp_validate_device, supported_reports: 0
[  +0.000111] input: Logitech  PRO Racing Wheel as /devices/pci0000:00/0000:00:08.1/0000:06:00.3/usb1/1-2/1-2.1/1-2.1:1.0/0003:046D:C272.0006/input/input18
[  +0.000159] logitech-hidpp-device 0003:046D:C272.0006: input,hidraw2: USB HID v1.11 Joystick [Logitech  PRO Racing Wheel] on usb-0000:06:00.3-2.1/input0
[  +0.009951] logitech-hidpp-device 0003:046D:C272.0007: hidpp_validate_device, supported_reports: 7
[  +0.000005] logitech-hidpp-device 0003:046D:C272.0007: hidpp_probe: hid_dw_start: 1, 45
[  +0.000126] logitech-hidpp-device 0003:046D:C272.0007: hiddev98,hidraw4: USB HID v1.11 Device [Logitech  PRO Racing Wheel] on usb-0000:06:00.3-2.1/input1
[  +0.000005] logitech-hidpp-device 0003:046D:C272.0007: hidpp_probe:   ret: 0
[  +0.054028] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hidpp_report: 17
[  +0.000013] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: fields_count: 20
[  +0.002032] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hid_hw_request ret: 20
[  +0.001018] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hidpp_report: 17
[  +0.000008] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: fields_count: 20
[  +0.001673] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hid_hw_request ret: 20
[  +0.002238] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hidpp_report: 16
[  +0.000003] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: fields_count: 7
[  +0.002448] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hid_hw_request ret: 7
[  +0.001606] logitech-hidpp-device 0003:046D:C272.0007: HID++ 4.2 device connected.
[  +0.000009] logitech-hidpp-device 0003:046D:C272.0007: hidpp_probe, proto_version: 0
[  +0.000006] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hidpp_report: 17
[  +0.000003] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: fields_count: 20
[  +0.001927] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hid_hw_request ret: 20
[  +0.002008] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hidpp_report: 17
[  +0.000004] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: fields_count: 20
[  +0.001752] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hid_hw_request ret: 20
[  +0.002288] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hidpp_report: 17
[  +0.000009] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: fields_count: 20
[  +0.001720] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hid_hw_request ret: 20
[  +0.001243] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hidpp_report: 17
[  +0.000003] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: fields_count: 20
[  +0.001745] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hid_hw_request ret: 20
[  +0.002253] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hidpp_report: 17
[  +0.000005] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: fields_count: 20
[  +0.001727] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hid_hw_request ret: 20
[  +0.002269] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hidpp_report: 17
[  +0.000008] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: fields_count: 20
[  +0.001737] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hid_hw_request ret: 20
[  +0.002216] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hidpp_report: 17
[  +0.000002] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: fields_count: 20
[  +0.001759] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hid_hw_request ret: 20
[  +0.002255] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hidpp_report: 17
[  +0.000003] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: fields_count: 20
[  +0.001749] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hid_hw_request ret: 20
[  +0.002235] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hidpp_report: 17
[  +0.000002] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: fields_count: 20
[  +0.001757] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hid_hw_request ret: 20
[  +0.001264] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hidpp_report: 18
[  +0.000006] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: fields_count: 64
[  +0.001722] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hid_hw_request ret: 64
[  +0.002254] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hidpp_report: 17
[  +0.000003] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: fields_count: 20
[  +0.001747] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hid_hw_request ret: 20
[  +0.002242] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hidpp_report: 17
[  +0.000002] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: fields_count: 20
[  +0.001760] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hid_hw_request ret: 20
[  +0.002256] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hidpp_report: 17
[  +0.000005] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: fields_count: 20
[  +0.001732] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hid_hw_request ret: 20
[  +0.002254] logitech-hidpp-device 0003:046D:C272.0007: hidpp_connect_event: get_device_name: Logitech PRO Racing Wheel
[  +0.000004] logitech-hidpp-device 0003:046D:C272.0007: hidpp_connect_event: get_device_name length: 25
[  +0.000004] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hidpp_report: 17
[  +0.000002] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: fields_count: 20
[  +0.001741] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hid_hw_request ret: 20
[  +0.002242] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hidpp_report: 17
[  +0.000003] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: fields_count: 20
[  +0.001757] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hid_hw_request ret: 20
[  +0.002253] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hidpp_report: 17
[  +0.000005] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: fields_count: 20
[  +0.001735] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hid_hw_request ret: 20
[  +0.002254] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hidpp_report: 17
[  +0.000003] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: fields_count: 20
[  +0.001748] logitech-hidpp-device 0003:046D:C272.0007: __hidpp_send_report: hid_hw_request ret: 20
[  +0.002240] logitech-hidpp-device 0003:046D:C272.0007: hidpp_connect_event input nodes are already created
[  +0.000003] logitech-hidpp-device 0003:046D:C272.0007: no inputs found
[  +0.000003] logitech-hidpp-device 0003:046D:C272.0007: Unable to initialize force feedback support, errno -19
[  +0.006883] logitech-hidpp-device 0003:046D:C272.0008: hidpp_validate_device, supported_reports: 0
[  +0.000124] logitech-hidpp-device 0003:046D:C272.0008: hiddev99,hidraw5: USB HID v1.11 Device [Logitech  PRO Racing Wheel] on usb-0000:06:00.3-2.1/input2
motolav commented 10 months ago

HIDPP_QUIRK_CLASS_G920 has a block of code within the function hidpp_input_mapped so probably all axis need to be included but the G Pro will need a different quirk from the G920.

    /* Ensure that Logitech G920 is not given a default fuzz/flat value */
    if (hidpp->quirks & HIDPP_QUIRK_CLASS_G920) {
        if (usage->type == EV_ABS && (usage->code == ABS_X ||
                usage->code == ABS_Y || usage->code == ABS_Z ||
                usage->code == ABS_RZ)) {
            field->application = HID_GD_MULTIAXIS;
        }
    }
JacKeTUs commented 10 months ago

Yeah, but it does not even goes there, when second interface is initialized...

motolav commented 10 months ago

It's breaking at the hidpp_ff_init inside hidpp_probe

...
    } else if (connected && (hidpp->quirks & HIDPP_QUIRK_CLASS_G920)) {
        ret = g920_get_config(hidpp, &data);
        if (ret)
            goto hid_hw_init_fail;
    }

    hidpp_connect_event(hidpp);

...

    if (hidpp->quirks & HIDPP_QUIRK_CLASS_G920) {
        ret = hidpp_ff_init(hidpp, &data);
        if (ret)
            hid_warn(hidpp->hid_dev,
             "Unable to initialize force feedback support, errno %d\n",
                 ret);
    }

g920_get_config completes somehow hidpp_connect_event(hidpp); prints HID++ 4.2 device connected. hidpp_ff_init can't find the FF devices

motolav commented 10 months ago

Yeah the G920 code likely isn't compatible at all if I'm reading that log right since there's 3 different devices (hidpp_report: 16, hidpp_report: 17, hidpp_report: 18)

Did you have the shifter and pedals plugged into the wheel? The driver could be operating like a wired unifying hub and each device would need it's own initializing code and IDs added to the kernel

condaatje commented 10 months ago

we have the G Pro pedals plugged into the wheelbase, but it appears that the pedals do not show to the OS, only the wheelbase - which ust passes axis values as if they were its own.

this aligns with what we see on the OLED display by default - bar readouts of axis values (pictured below) including brake/accel/clutch from pedals (or from the bottom two paddles below the shifters, which control the clutch bar on the wheelbase's OLED)

image

berarma commented 10 months ago

Doesn't the most recent G923 patch help?

motolav commented 10 months ago

I'd try plugging the pedals directly into a computer to see if they have their own USB ID, if they do then my theory of the base being a Unifying Receiver might be true. The pedals use either a serial bus using USB connectors or actual USB.

motolav commented 10 months ago

Doesn't the most recent G923 patch help?

The Xbox G923 is identical to the Xbox G920 software wise so all it needed was the USB IDs defined

motolav commented 10 months ago

The pedals are USB devices with their own IDs so they would need to be defined in hid-ids.h as they can be used directly plugged into a PC I found.

condaatje commented 10 months ago 
[Aug29 12:56] usb 1-2.2: new full-speed USB device number 6 using xhci_hcd
[  +0.117621] usb 1-2.2: not running at top speed; connect to a high speed hub
[  +0.017999] usb 1-2.2: New USB device found, idVendor=046d, idProduct=c26a, bcdDevice= 6.00
[  +0.000004] usb 1-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  +0.000001] usb 1-2.2: Product: PRO Racing Pedals
[  +0.000002] usb 1-2.2: Manufacturer: Logitech
[  +0.000001] usb 1-2.2: SerialNumber: 2319WD0057A8
[  +0.094114] input: Logitech PRO Racing Pedals as /devices/pci0000:00/0000:00:08.1/0000:06:00.3/usb1/1-2/1-2.2/1-2.2:1.0/0003:046D:C26A.000F/input/input21
[  +0.000448] hid-generic 0003:046D:C26A.000F: input,hidraw2: USB HID v1.11 Joystick [Logitech PRO Racing Pedals] on usb-0000:06:00.3-2.2/input0
[  +0.006678] hid-generic 0003:046D:C26A.0010: hiddev97,hidraw3: USB HID v1.11 Device [Logitech PRO Racing Pedals] on usb-0000:06:00.3-2.2/input1

pedals are c26a when plugged into the computer directly

when you say this means the base is a unifying receiver, do you mean that the driver will have to be aware of whether there are pedals plugged into the wheelbase?

I ask because it seems capable of sending e.g. clutch data without the pedals present, and represents several axes to the computer regardless of whether the pedals are attached (the brake and throttle axes just remain zero, but I think they are still present on the device all the same)

that is to say - there appears to be no difference in the device configuration when the pedals are/aren't plugged in - only differences in axis values (always zero for pedals-only axes when they aren't plugged in)

motolav commented 10 months ago

when you say this means the base is a unifying receiver, do you mean that the driver will have to be aware of whether there are pedals plugged into the wheelbase?

In the log above there's 3 separate HID++ devices found which is why I'm thinking that the base operates like a hacked up Logitech Unifying Receiver (the little dongle they sell for wireless keyboards and mice). hidpp_report: XX refers to which devices are found on using the HID++ driver, if the pedals were actually completely invisible to the OS I'm not sure if the HID++ driver would've seen it

motolav commented 10 months ago

I added the ID for the G pro pedals to my repo and added it to the hidpp driver, it should detect as a HID++ device now when plugged in directly

JacKeTUs commented 10 months ago

@motolav, no, simply adding new g pro id's to the hidpp driver does not work sadly

Not with g923 compatibility mode, not with native

JacKeTUs commented 10 months ago

May be that link will be helpful Opensourced hidpp protocol details:

https://drive.google.com/drive/folders/0BxbRzx7vEV7eWmgwazJ3NUFfQ28?resourcekey=0-dQ-Lx1FORQl0KAdOHQaE1A

motolav commented 10 months ago

This is what I'm thinking as to why even when in G923 mode the force feedback wasn't working as the driver was probing the hub/receiver instead of the wheel controller directly. g-pro

condaatje commented 10 months ago

@JacKeTUs can correct me if I'm wrong here, but in our tinkering we disabled all but the first HID++ device (device 0) and still got data from the wheel AND pedals when pressed (as with e.g. wine control joy.cpy or captured from usbmon in wireshark

condaatje commented 10 months ago

hmm actually...this might not be the case. ~wine control joy.cpy has its own driver within the wine vm (?) that doesn't care about linux-side driver customizations since it's a guest OS?~ (edit - I don't really know much about how wine works actually)

Here is a wireshark capture from a windows vm of

  1. connect via usb passthrough (device initializes itself with the machine)
  2. press accelerator pedal
  3. steer wheel with my hand
  4. output force to wheel using WheelCheck.exe

i do see different sub-devices (1.2.1, 1.2.2, and 1.2.0) apparently active. @motolav you may be onto something with these other devices showing up in the kernel logs.

(file uploaded as txt for github, download and change extension to .pcapng to load in wireguard)

connect-pedals-steer-force.txt

condaatje commented 10 months ago

ok after some further windows wireshark testing:

1.2.1 - throttle (pedals) 1.2.1 - brake (pedals) 1.2.1 - clutch (pedals) 1.2.1 - steering (wheel) 1.2.1 - clutchpaddles (wheel)

so all the input axes seem to come from the same device, which gels with what we've seen so far. HOWEVER

when I play a force feedback effect from WheelCheck.exe, 1.2.0 and 1.2.2 are activated - screenshot below (actual example data can be examined in the wireshark capture file):

image

so pedal and steering wheel don't have separate devices for joystick inputs, but force feedback appears to go through the other two interfaces?

motolav commented 10 months ago

i do see different sub-devices (1.2.1, 1.2.2, and 1.2.0) apparently active. @motolav you may be onto something with these other devices showing up in the kernel logs.

If you sort the data by type of response there's a pattern of x.x.0 endpoints handling the USB stuff and x.x.1/x.x.2 endpoints handling the raw data via interrupts so 1.2.1 = wheel inputs and 1.2.2 = wheel force feedback

JacKeTUs commented 10 months ago

So it looks like three interfaces: 0th - just for the inputs (descriptor reports for joystick controls etc, no hidpp reports) 1st - HIDPP++2.0 interface (descriptor reports support for all hidpp reports, short, long, verylong) 2nd - something else, may be trueforce?

HID drivers probes for every interface, and there is no way (or i can't find that) to send reports about forcefeedback to second interface from input device on first interface. FFB needs to be initialized on input device.

Is there anybody with g920 or g923 xbox version? If g920 and g923 have hidpp reports declared on the first interface, with joystick inputs etc, that may explain why g pro can't initialize ffb with the same driver

UPD: found g920 descriptor, and yeah, it's hidpp reports and input joystick reports all in one interface

motolav commented 10 months ago

In the Arch Linux Wiki there's a couple tools to see what exactly an input device reports, I'd try running evtest to see if FFB is included in the input device.

Maybe the base requires the quirk HIDPP_QUIRK_DELAYED_INIT because the Windows VM USB logs go from communication between 1.1.0/1.1.1 until the driver eventually only talks to 1.2.X. That quirk will set will_restart to true and it's right before the hidpp-ff-init where the driver breaks

    } else if (connected && (hidpp->quirks & HIDPP_QUIRK_CLASS_G920)) {
        ret = g920_get_config(hidpp, &data);
        if (ret)
            goto hid_hw_init_fail;
    }

    hidpp_connect_event(hidpp);

    if (will_restart) {
        /* Reset the HID node state */
        hid_device_io_stop(hdev);
        hid_hw_close(hdev);
        hid_hw_stop(hdev);

        if (hidpp->quirks & HIDPP_QUIRK_DELAYED_INIT)
            connect_mask &= ~HID_CONNECT_HIDINPUT;

        /* Now export the actual inputs and hidraw nodes to the world */
        ret = hid_hw_start(hdev, connect_mask);
        if (ret) {
            hid_err(hdev, "%s:hid_hw_start returned error\n", __func__);
            goto hid_hw_start_fail;
        }
    }

    if (hidpp->quirks & HIDPP_QUIRK_CLASS_G920) {
        ret = hidpp_ff_init(hidpp, &data);
        if (ret)
            hid_warn(hidpp->hid_dev,
             "Unable to initialize force feedback support, errno %d\n",
                 ret);
    }
JacKeTUs commented 10 months ago

If FFB is included in the input device

No, it is not: Here is dumped descriptors from @condaatje pcap files:

0th interface: 05010904a1010939150025073500463b01651475049501814205091901291c6500250145017501951c81020501093027ffff000047ffff000075109501810209330934093509320936093765007510950681020600ff2501450119002907750195088102c0

1st interface: 0643ff0a0107a101851075089506150026ff000901810009019100c00643ff0a0207a101851175089513150026ff000902810009029100c00643ff0a0407a10185127508953f150026ff000903810009039100c0

2nd interface: 06fdff0a01fda1018501150026ff007508953f09018100953f09019100c0

You can use that service to decode it - https://eleccelerator.com/usbdescreqparser/

JacKeTUs commented 10 months ago

I am trying to tinker with it on my repo (https://github.com/JacKeTUs/hid-logitech-hidpp), and every commit you see there - did not initialize ffb on @condaatje device. We tried to ignore errors, try to force driver to think that 0th interface is hidpp device, etc, but no luck

Now i'm trying to redirect inputs (or vice versa) from 1 to 0 interface, as it does in hid-holtek-kbd driver. Later maybe ill try to initialize ffb on the 0 interface from 1st one, but i need some functions to send hidpp ffb reports to the 1st interface.

JacKeTUs commented 10 months ago

We got it working with that patch right here: https://github.com/JacKeTUs/hid-logitech-hidpp/commit/e84f9d13621a5889ad3b53175c587de20f4e98d7

Wheelcheck.exe, fftest works

motolav commented 10 months ago

there still needs to be fixes to the g920 code and hidpp_ff code to allow 1080 degrees of range https://github.com/torvalds/linux/blob/1687d8aca5488674686eb46bf49d1d908b2672a1/drivers/hid/hid-logitech-hidpp.c#L2763 https://github.com/torvalds/linux/blob/1687d8aca5488674686eb46bf49d1d908b2672a1/drivers/hid/hid-logitech-hidpp.c#L3453 could just hack it temporarily until its fixed to be kernel appropriate

JacKeTUs commented 10 months ago

Yep, hacked https://github.com/JacKeTUs/hid-logitech-hidpp/commit/a31dedd1b26fdb50177c1323d11d5454113591a5

We need testers now. @condaatje have some issues with Steam on Arch, which prevents controller to work with Proton games. Native game like ATS, and wine control joy.cpl and wine WheelCheck.exe works perfectly.

motolav commented 10 months ago

Since there isn't any physical limit on rotation, unless there's a firmware limit in the controller, it's possible to see if the range could be extended further for games like ATS/ETS supposedly most semi trucks are like 1800 degrees

JacKeTUs commented 10 months ago

G Pro does have stops btw https://youtu.be/lNWHTbvq6UE?si=a9j0JEs-7MrM1YpK&t=166

Hmm, Fanatec lets you spin it infinitely, there's no stops. This one [G Pro Wheel] does have stops, but they are both direct drive.

And you can see in the video wheel bumps from the stopper

atzufuki commented 10 months ago

I tried JacKeTUs's repo and fftest is working fine as well as the FFB test in Oversteer.

I also tried a native game called Speed Dreams and it's detecting the wheel and I was able to do couple laps. However FFB didn't work. Did anyone else get FFB working in a native game?

Assetto Corsa Competizione through Proton didn't detect the wheel at all, except in G923 mode which also had no FFB. I'm running Fedora 38 btw.

I can confirm that there indeed is physical stoppers limiting the rotation of the wheel.

berarma commented 10 months ago

I tried JacKeTUs's repo and fftest is working fine as well as the FFB test in Oversteer.

I also tried a native game called Speed Dreams and it's detecting the wheel and I was able to do couple laps. However FFB didn't work. Did anyone else get FFB working in a native game?

Assetto Corsa Competizione through Proton didn't detect the wheel at all, except in G923 mode which also had no FFB. I'm running Fedora 38 btw.

I can confirm that there indeed is physical stoppers limiting the rotation of the wheel.

I think the next step would be making SDL recognize the device as a wheel.

JacKeTUs commented 10 months ago

@atzufuki, try g_native_report_fixup branch

SDL detects joystick if there is X and Y axis - in G Pro Native mode there is no Y axis. I tried change Z to Y axis on g_native_report_fixup branch

We with @condaatje got FFB working on native game (ATS), and ACC in Proton detects the wheel with g_native_report_fixup branch, but no FFB as well for now

berarma commented 10 months ago

@atzufuki, try g_native_report_fixup branch

SDL detects joystick if there is X and Y axis - in G Pro Native mode there is no Y axis. I tried change Z to Y axis on g_native_report_fixup branch

We with @condaatje got FFB working on native game (ATS), and ACC in Proton detects the wheel with g_native_report_fixup branch, but no FFB as well for now

No, we don't want the wheel to be detected as a joystick but as a wheel. I wouldn't mess with the axes.

It just has to be added to the whitelist. See libsdl-org/SDL@7237c56 for an example.

JacKeTUs commented 10 months ago

Hm... But what about that code here? https://github.com/libsdl-org/SDL-1.2/blob/main/src/joystick/linux/SDL_sysjoystick.c#L393

And we have G923 PS version, c267 and c266 product id's, and these aren't in the whitelist, but FFB works

berarma commented 10 months ago

Hm... But what about that code here? https://github.com/libsdl-org/SDL-1.2/blob/main/src/joystick/linux/SDL_sysjoystick.c#L387

That's old code. Current version is SDL 2.

And we have G923 PS version, c267 and c266 product id's, and these aren't in the whitelist, but FFB works

They should be added too. FFB might work without adding them but applications may use them as joysticks and that can lead to issues.

JacKeTUs commented 10 months ago

May be you know, can we manipulate/change controller guid? https://github.com/libsdl-org/SDL/blob/7237c5649994d2b2c2b364c3b116a6db80ea671d/src/joystick/SDL_joystick.c#L2463C26-L2463C26 guid.data[15] needs to be 0x02