Is support planned for the new (direct drive) Logitech G Pro Racing Wheel? #82
Comments
|
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. |
berarma
added
enhancement
|
@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 torvalds/linux@e8ab7a1 (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 |
|
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 |
@berarma There's different 3 different SKUs for Xbox/PC, PlayStation/PC, and PC only I found on PC Gaming wiki the USB IDs
@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 |
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? |
|
change to hid-ids.h change to hid-logitech-hidpp.c 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 |
|
(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?) 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): |
|
That has a different ID, idProduct=c26e, so it wouldn't work with my repo yet |
|
Somewhere in |
|
Is there any feature missing in G923 mode? I'm asking because maybe it's not worth making it work in the default mode. |
|
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
|
|
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 But standart hidpp driver can't initialize Force Feedback on any of the modes (g923comp and native one) |
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 |
|
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. |
|
Interestingly enough - without |
|
|
|
Yeah, but it does not even goes there, when second interface is initialized... |
|
It's breaking at the
|
|
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 |
|
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)
|
|
Doesn't the most recent G923 patch help? |
|
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. |
The Xbox G923 is identical to the Xbox G920 software wise so all it needed was the USB IDs defined |
|
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. |
pedals are 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) |
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). |
|
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 |
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 |
|
So it looks like three interfaces: 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 |
|
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 |
No, it is not: 0th interface: 1st interface: 2nd interface: You can use that service to decode it - https://eleccelerator.com/usbdescreqparser/ |
|
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. |
|
We got it working with that patch right here: Wheelcheck.exe, fftest works |
|
there still needs to be fixes to the g920 code and hidpp_ff code to allow 1080 degrees of range |
|
Yep, hacked 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 |
|
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 |
|
G Pro does have stops btw
And you can see in the video wheel bumps from the stopper |
|
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. |
|
@atzufuki, try 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 We with @condaatje got FFB working on native game (ATS), and ACC in Proton detects the wheel with |
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. |
|
Hm... And we have G923 PS version, c267 and c266 product id's, and these aren't in the whitelist, but FFB works |
That's old code. Current version is SDL 2.
They should be added too. FFB might work without adding them but applications may use them as joysticks and that can lead to issues. |
|
May be you know, can we manipulate/change controller guid? |
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. |
|
Oh, okay, thanks for the info |
|
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. |
|
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? |
|
Yep, and Simagic wheel with fixed hidpp driver (no descriptor fixup), is G29, on the other hand, 0x02 - 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 |
|
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. |
|
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 |
|
With Y branch present in report_fixup on G Pro we have SDL detecting the wheel as |
|
Maybe Proton just bundles SDL 1.2? Because we can't detect the device in |
|
@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? |
|
There is already a few issue reports in the ValveSoftware/Proton repo related to wheels |
|
Another Logitech G Pro wheel and pedal owner here. At present, my wheel is recognized in Overdrive but rFactor2 and ACC don't detect the wheel. |
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
Force feedback tests fail
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)
The text was updated successfully, but these errors were encountered: