Arch Linux User Repository

Subject: Success fix for Fanatec BMW M4 GT3 Clutch Paddles (Axis 10/11) on Linux

Problem: Clutch paddles on the Fanatec BMW M4 GT3 (USB ID 0eb7:0020) not detected as axes or showing as "dead" in-game, despite the hid-fanatec module being loaded.

Solution: 1. Use the correct fork: The standard AUR version might lack specific initialization. Use a fork that includes the recent M4 GT3 patches (e.g., 0.2.2-3-gf7bf935).

1. Module Parameters: The key is to force hardware initialization and range calibration. Create/edit /etc/modprobe.d/fanatec.conf:

   options hid_fanatec init_load=1 init_range=1 enable_module_init_led=0
   

Note: Older parameters like ff_m4_gt3=1 are deprecated/invalid in newer forks.

3.Reload Driver: sudo modprobe -r hid_fanatec

        sudo modprobe hid_fanatec

1. Verification: Check jstest /dev/input/jsX. The paddles should now respond on Axis 10 and 11.

System Info: Arch Linux, Kernel 6.19+, Fanatec Podium Wheel Base.

Thank you for the update! I appreciate you very much for maintaining this tool.

Just reporting that on CachyOS, installation was a breeze with paru. I simply used 'linux-cachyos-headers' instead, which is specific to Cachy.

Also, I didn't install the hid-fanatecff-tools package, but my wheel lights and shift indicators worked out of the box with Assetto Corsa Rally specifically. No issues with the wheel at all using the latest proton GE. Going to test Assetto Corsa EVO today.

Thanks again!

Hey all,

I've updated the package to 0.2.2 . I do still actively maintain this, it's just that tagged versions from upstream are quite rare, so I oft don't notice until someone mentions it to me.

I've spoken to an individual interested in co-maintaining possibly, so hopefully we'll get the lag down on the update timeframes.

It is a bit of work to verify that devices are still detected and whatnot after updating a kernel module package, so sometimes it gets put off for a while. You can always reach out to me directly (especially if with a patch and an attestation of some testing) to speed up the process.

Thanks, mcoffin

Thanks for your hard work on this. Any chance this AUR could be updated to 0.2.2?

Is there a reason why you use m4, which is hardly used nowadays, and not just use the sed for a dkms.conf.in?

Please remove the direct dependency on linux-headers; this causes that package to be required even when using another kernel. Depending on just dkms should be sufficient (this is what all official *-dkms packages do)

hey, thanks mcoffin. appreciate it.

@ortango - OOPS! I built it but because pkgver()-containing packages update the pkgver line in the PKGBUILD afterwards, I neglected to remove the function, so it wouldn't have worked for anyone after. My bad. fixing it now

currently this is broken, correct? [that] $pkgver is not a valid tag.

also, this package doesn't need those pkgver or prepare functions.

Also do not use the next branch anymore, try to update the AUR to use the latest tagged release (v0.1 at this moment).