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