Fellow sim racer! I asked quite a few similar questions on here before making the switch again (last time was 10 years ago and just on spare pcs that I put linux on). I am sorry I don’t have in depth knowledge to help you; Mint with oversteer seems to work ok with my dfgt. I have tested it in AMS2 and beamng and it has worked well. Have not installed AC yet. Maybe try a quick install of mint on a spare drive and see if it works there ? I’d do that since it seems easiest. Then you know if it’s distro related.

I got new-lg4ff working some time ago and posted this on the Bazzite discord. I have not tried for some time though:

I managed to get new-lg4ff going at least on a per use basis. Not ideal this way but at least something. First you need to pull the driver from Github:

git clone https://github.com/berarma/new-lg4ff

Then you need a toolbox matching your base image in my case:

toolbox create --image ghcr.io/ublue-os/bazzite-gnome:testing --container bazzite-devel
toolbox enter bazzite-devel

Next you need to pull in the kernel-devel files. They are on a separate github page “kernel-bazzite”. Find your running kernel version.

uname -r

Then download the appropriate kernel-devel and kernel-devel-matched from https://github.com/hhd-dev/kernel-bazzite/releases, in my case:

wget https://github.com/hhd-dev/kernel-bazzite/releases/download/6.11.5-310/kernel-devel-matched-6.11.5-310.bazzite.fc41.x86_64.rpm
wget https://github.com/hhd-dev/kernel-bazzite/releases/download/6.11.5-310/kernel-devel-6.11.5-310.bazzite.fc41.x86_64.rpm

Install them into the toolbox:

sudo rpm -if kernel-devel-matched-6.11.5-310.bazzite.fc41.x86_64.rpm kernel-devel-6.11.5-310.bazzite.fc41.x86_64.rpm

Then the build of the module should succeed. From the folder you cloned the new-lg4ff repo run:

make

To insert the module you need to relax SELINUX (against idea of SELINUX, but it is a hacky solution).

sudo setenforce Permissive

Then you should be able to insert the kernel module:

sudo insmod hid-logitech-new.ko

This is it.

There’s an issue on Bazzite’s repo asking for new-lg4ff and other kernel modules to be added. While the issue is still open, it describes a workaround^[1][2] but it requires building the DKMS module and layering it on top of Bazzite on every kernel update.

Edit: re-reading your post and Oversteer’s README your wheel should be supported by the default kernel, I’m not sure new-lg4ff will fix your issue (and the latter does not list the G920). The issue must be somewhere else. I wish I could help you, but I have yet to try Assetto Corsa and Dirt Rally with my Driving Force GT on Bazzite.

---

1. https://github.com/ublue-os/bazzite/issues/901#issuecomment-2054077901 ↩︎

2. https://github.com/ublue-os/bazzite/issues/901#issuecomment-2395749374 ↩︎

So, I’m far from knowledgeable enough to help you fully, but it seems like something is wrong with the games rather than with your wheel. If DR2.0 and oversteer both work (I’m assuming you mean with proper ffb) then that means that the wheel is being detected by your computer and that the driver, which for the g920 is already built into the kernel according to new-lg4ff, is working.

Like I said, I unfortunately can’t help you other than suggesting reinstalling the games or using a different proton version, but hopefully this is enough to help you find a proper answer

DKMS is not supported on bazzite.

I mean, not having DKMS sounds like it’d be obnoxious for gaming to me.

But if all you need is a kernel module, you shouldn’t have to have it built via DKMS.

I don’t use Bazzite, but the driver project has instructions for a non-DKMS build:

https://github.com/berarma/new-lg4ff

Manual method

Use only if DKMS doesn’t work.

You’re going to need to manually do a new build and install if you update your kernel, though, since otherwise the new kernel won’t have that driver (well, unless the Bazzite people include it in the new kernel).

EDIT:

I was under the impression that new-lg4ff cannot be installed due to the immutable nature of the system.

I haven’t used an immutable distro, but if it’s a problem, I’m sure that there’s a way to defeat the immutability. If it just mounts the root filesystem read-only, then

# mount -o remount,rw /

Will probably do it.

I’m also pretty sure that you can use a non-standard directory with modprobe and if you want to manually load the module out of some other directory. Looking at the modprobe(8) man page, looks like it takes a -d flag and an alternate module root directory.

EDIT2: Hmm. insmod might be simpler than modprobe, since then you don’t have to worry about dependent modules, especially if new-lg4ff is just a single module. It’s been ages since I’ve insmodded something, but if it can take a path to a kernel module file, then one doesn’t need to worry about having modprobe see both new-lg4ff and any modules that it depends on.

EDIT3: Just realized one other bit of complexity. This isn’t just loading a driver that isn’t present. If some other driver is “claiming” the steering wheel first — you say that it’s working, but not with all the functionality you want? — then you might need to prevent that other driver from doing so, or make it release the device, as I don’t think that your steering wheel driver can claim the device if another already has it.

I’m gonna bet that it’s usbhid. I think — honestly, never looked into whether anything’s changed since the udev daemon showed up — that as soon as a module is loaded, it grabs all the devices that it recognizes. And another complication — you don’t want to prevent usbhid from loading, which is one approach that’s used when an old, broken driver is used, because it gets used for all sorts of other things like your keyboard and mouse.

If you run:

# evtest

You’ll get a list of all of your event devices. On my system, for example, I have:

/dev/input/event22:     8BitDo Pro 2 Wired Controller

If you want to know which driver is associated with a given event device:

$ ls -l /sys/class/input/event22/device/device/driver
lrwxrwxrwx 1 root root 0 May  4 22:50 /sys/class/input/event22/device/device/driver -> ../../../../../../../../../bus/usb/drivers/xpad

The xpad kernel driver owns that device for me. In your case, I bet that it’s gonna be something like: “…/…/…/…/…/…/…/…/…/…/bus/hid/drivers/hid-generic”.

From this:

https://stackoverflow.com/questions/51858074/preventing-usbhid-from-claiming-device

It sounds like doing an unbind will work to make the usbhid module release the device. That guy has a udev rule written, which will cause the udevd daemon to cause the usbhid driver to automatically release the device.

goes looking for an example of adding a udev rule

https://linuxconfig.org/tutorial-on-how-to-write-basic-udev-rules-in-linux

RHEL-based distros use akmods not DKMS.

A different distro isn’t going to help. It’s an issue of game telemetry and hardware not being supported. Unfortunately Simracing really requires dual-booting windows.