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

[condaatje]

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]

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

That's only for Windows. XInput reports the device type in the GUID, and that's what SDL is using when XInput is the backend. For Linux, SDL is doing the job that XInput does for Windows in this case, and it's done using the mentioned whitelist.

[JacKeTUs]

Oh, okay, thanks for the info Simagic id's also not in the whitelist, but their descriptor have X and Y axis.. I'll try to reproduce the issue with absence of Y axis in the descriptor (i have simagic base, but not g pro wheel), and i'll see how games will react to that

[berarma]

Some users are using HIDPP wheels through Proton's USB pass-through. I don't know the details about how it's done but that would bypass Linux and connect the wheel directly to the Windows software (drivers and XInput) running on Proton. In that case, no Linux drivers or SDL compatibility is required.

But if you're not doing that and you want XInput in Proton to correctly report the wheel device type to Windows applications, you need to patch SDL to correctly recognize the device as a wheel. And in order to improve SDL compatibility and leverage the Linux device support to that on Windows, we should add all wheel devices to this whitelist.

[JacKeTUs]

hmm... a bit of offtop, but Simagic is kind of hidpp compatible - without one descriptor. I wasn't able to use ffb on any games without patches to hidpp - through proton and native. Patched hidpp without 0xa7 descriptor - and device is now ffb capable both native and proton

[berarma]

hmm... a bit of offtop, but Simagic is kind of hidpp compatible - without one descriptor. I wasn't able to use ffb on any games without patches to hidpp - through proton and native. Patched hidpp without 0xa7 descriptor - and device is now ffb capable both native and proton

I don't know if Proton/SDL uses heuristics to detect wheels. Maybe it's the case. Anyway trying to accomodate the device to the heuristics isn't the way to go. Heuristics are intended as a last resort, not the standard that devices should follow.

Have you tried checking the device type on SDL/Linux?

[JacKeTUs]

Yep, and Simagic wheel with fixed hidpp driver (no descriptor fixup), is SDL_JOYSTICK_TYPE_UNKNOWN

G29, on the other hand, 0x02 - SDL_JOYSTICK_TYPE_WHEEL, because of the whitelist inside of SDL G923 ps - SDL_JOYSTICK_TYPE_WHEEL, but i think because of presence in gamecontrollerdb.txt - is also detected as the wheel

But with all three - FFB working as expected (g29 with and without new-lg4ff, g923 ps with new-lg4ff, simagic with my patched hid-pidff) on all native games and Proton

Tested with this repo https://github.com/Grumbel/sdl-jstest With this little patch right here

diff --git a/src/sdl2-jstest.c b/src/sdl2-jstest.c
index e5dcb44..2089a19 100644
--- a/src/sdl2-jstest.c
+++ b/src/sdl2-jstest.c
@@ -64,11 +64,13 @@ int str2int(const char* str, int* val)
 void print_joystick_info(int joy_idx, SDL_Joystick* joy, SDL_GameController* gamepad)
 {
   SDL_JoystickGUID guid = SDL_JoystickGetGUID(joy);
+  SDL_JoystickType type = SDL_JoystickGetType(joy);
   char guid_str[1024];
   SDL_JoystickGetGUIDString(guid, guid_str, sizeof(guid_str));

   printf("Joystick Name:     '%s'\n", SDL_JoystickName(joy));
   printf("Joystick GUID:     %s\n", guid_str);
+  printf("Joystick GUIDType: %02x\n", type);
   printf("Joystick Number:   %2d\n", joy_idx);
   printf("Number of Axes:    %2d\n", SDL_JoystickNumAxes(joy));
   printf("Number of Buttons: %2d\n", SDL_JoystickNumButtons(joy));

[berarma]

Gamecontrollerdb is only a mapping of axes and buttons for games expecting an XBox controller.

I think the only way the type can be wheel is by adding to the whitelist. If there's another way I'd like to know. Which SDL version are you using?

As I said, SDL doesn't have to return valid information for the FFB to work, but it might help in some cases.

[JacKeTUs]

I'm using SDL version 2.28.3 (link to packages.debian). There is no c267/c266 in sdl github, only an xbox version present here https://github.com/libsdl-org/SDL/blob/36b5f3e35c00f1b392618f657d1cc32d8327527f/src/joystick/SDL_joystick.c#L2643

Interesting case... Thank you for the info, i'll dig deeper

[JacKeTUs]

With Y branch present in report_fixup on G Pro we have SDL detecting the wheel as UNKNOWN_JOYSTICK, as my Simagic Without Y branch and my driver - same thing

bagheera@bagheera-eos ~/c/w/s/build (master)> ./sdl2-jstest --list
Found 1 joystick(s)

Joystick Name:     'Logitech PRO Racing Wheel'
Joystick GUID:     030049316d04000072c2000011010000
Joystick GUIDType: 00
Joystick Number:    0
Number of Axes:     7
Number of Buttons: 28
Number of Hats:     1
Number of Balls:    0
GameControllerConfig:
  missing (see 'gamecontrollerdb.txt' or SDL_GAMECONTROLLERCONFIG)

[JacKeTUs]

Maybe Proton just bundles SDL 1.2? Because we can't detect the device in wine control joy.cpl running through Proton without an Y axis present

[condaatje]

@kisak-valve do you mind if I call your attention to this issue? Working to get functional ffb in proton with the new logitech g pro race wheel.

I believe JacKetUs has a PR that's just been merged into SDL that might help, but the updated library would have to make it into Proton Experimental for us to try it out. Any chance you could help us get that update into Proton?

[motolav]

There is already a few issue reports in the ValveSoftware/Proton repo related to wheels

[Theogore]

Another Logitech G Pro wheel and pedal owner here. I'm not a programmer and I am a novice when it comes to Linux, but if I can help in any way, please let me know.

At present, my wheel is recognized in Overdrive but rFactor2 and ACC don't detect the wheel.