Skip Navigation
Linux Gaming @lemmy.world
Logh @lemmy.ml

Sim racing and bazzite

Recently I dipped my toes in sim racing and I could run dirt 2.0 and AC fairly easily with a controller. A few weeks ago I bought a G920 and so far the only game that works with it proper is Dirt 2.0. AC and rF2 are a nightmare. AC shakes the wheel or doesn’t recognize it, rF2 just keeps steering on it’s own (even when the car is stationary, with autosteer off). I also tried RSF RBR, which runs, but after the first launch it doesn’t detect the wheel anymore.

DKMS is not supported on bazzite, I couldn’t get new-lg4ff to work. Oversteer works, but is sort of useless without the driver. I’m a little bit disheartened at this point. Since I bought the wheel, I spent way more time troubleshooting than racing.

Does anyone have any experience running these games on bazzite with a G920? Is there an easy fix to all of these issues that I’m overlooking?

I’m way too settled into bazzite to distrohop now and I really wouldn’t like to have MS in my household.

My main priority would be to get RSF RBR running and then AC or rF2 to have something other than rally.

Thanks in advance for any input

16 comments

  • 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

  • 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 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.

16 comments