Dirt Rally 2.0 issues

[azampatti]

Hi there, I'm positive I have something wrong in my system but I can't find what, hopefully you'll be able to help me.

First of all, THANKS A LOT for all you efforts!

I have PCARS2 and DR2 exclusively, and thanks to your help and contribution, PCARS2 is running flawlessly with Proton 4.11-11 (although it looses ffb after I alt-tab in/out of the game, but I couldn't care less).

Now Dirt Rally 2.0 was working fine for me with Proton 4.2-9 + FFBWrap tweak of yours, but now, FFB won't work at all. I've tried: -The already mentioned versions of proton both WITH and WITHOUT ffbwrap. -Kernels 5.3 and 5.4 (with both versions of proton and both with and w/o ffbwrap). -I've re-download and re-compiled ffbwrap -And finally, downloaded and dkms the driver in. Still no luck

I do see: [user@manjaro-big ~]$ sudo dmesg | grep -i feedback [ 2.960476] logitech 0003:046D:C299.0004: Force feedback support for Logitech Gaming Wheels Also, when I install ffbwrap, I do see this error (might be related?): $ /home/user/Downloads/ffbtools-master/bin/ffbwrap --update-fix /dev/input/by-id/usb-046d_G25_Racing_Wheel-event-joystick -- glxgears ERROR: ld.so: object '/home/mudo/Downloads/ffbtools-master/bin/../build/libffbwrapper-i386.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.

Let me know what else I can look for or where to look for and I'll happily return the info. Thanks a lot in advance. -Aldo

[writequit]

Hi Aldo,

Are you sure it's the new module that's loaded, it should have the version number at the end of the line in the log: # dmesg | grep -i feedback [ 7142.884037] logitech 0003:046D:C24F.0010: Force feedback support for Logitech Gaming Wheels (0.2b)

Regards, Geoff (just a user not a dev)

[azampatti]

I'm not sure at all, but this is what I see:

[writequit]

Try: # lsmod | grep logi Should see: hid_logitech_new

If it doesn't say new unplug the wheel and "rmmod hid_logitech" then plug it in again and see what you get.

[azampatti]

That actually does the trick of loading the correct module but it won't persist after a reboot.

Also, tried to launch DR2.0 w/o ffbwrap and didn't work (while having the _new module loaded), but this time applying the ffbwrap --update-fix command did work and looked like a bit stronger (probably due to the new driver).

Is this expected? Any way I can make this change permanent to persist reboots? thanks a lot once again!

-Aldo

[berarma]

Unless a game update has changed anything it should work using just ffbwrap. The new driver will add some stiffness but that's all.

You can use ffbwrap to write a log and see if it's indeed running. It's the --logger option.

[berarma]

Ah, and the fix for DR2 might work on PC2 so that it doesn't loose FFB. Can someone try it?

[berarma]

Any way I can make this change permanent to persist reboots?

Install it with DKMS.

[azampatti]

Ah, and the fix for DR2 might work on PC2 so that it doesn't loose FFB. Can someone try it? Just tried with the correct driver loaded, and still loose FFB when atl-tabbing out of the game. This is true both with and without ffbwrap at least in my case

Any way I can make this change permanent to persist reboots?

Install it with DKMS.

I did the install with DKMS, but for some reason (as showed above), it won't load your driver at boot. Following @writequit 's advise, I can make it load and definitely feel the difference and I can easily tell when it was loaded.

thanks once again!

[leillo1975]

write in a terminal dkms status and copy/paste here the output

[azampatti]

that's what I get after a fresh boot

[berarma]

You have installed a module called new on version lg4ff. I have no idea how you got this.

Remove it with:

dkms remove new/lg4ff --all

[writequit]

There is something a bit odd about the way it works with dkms. It only installs on the running kernel and when I updated the kernel I had to re-install it:

# dkms status new-lg4ff, 0.2b, 5.4.0-1-amd64, x86_64: installed nvidia-current, 430.64, 5.3.0-3-amd64, x86_64: installed nvidia-current, 430.64, 5.4.0-1-amd64, x86_64: installed virtualbox, 6.1.0, 5.3.0-3-amd64, x86_64: installed virtualbox, 6.1.0, 5.4.0-1-amd64, x86_64: installed

Hopefully your driver gets accepted into the kernel so none of this will be necessary.

[azampatti]

You have installed a module called new on version lg4ff. I have no idea how you got this.

Remove it with:

dkms remove new/lg4ff --all

Thanks, honestly no idea how I managed to do that, I must have typed something wrong. So I removed that and still same result (loading logitech-hid at boot) so I ran dkms remove new-lg4ff/0.2b --all and re-install by instructions with dkms (copy-pasted, ensured I did this right ;-))

Still get the same result. Here is the output I get after a fresh boot:

Then If I disconnect the wheel from the USB, do rmmod then re-connect, new driver is loaded:

Looks like dkms isn't installing the module properly? maybe? :)

Again, thanks all for your help here!

[azampatti]

BTW: DKMS Status output: `[mudo@manjaro-big ~]$ sudo dkms status

new-lg4ff, 0.2b, 5.4.6-2-MANJARO, x86_64: installed (original_module exists) `

[berarma]

There is something a bit odd about the way it works with dkms. It only installs on the running kernel and when I updated the kernel I had to re-install it:

dkms status

new-lg4ff, 0.2b, 5.4.0-1-amd64, x86_64: installed nvidia-current, 430.64, 5.3.0-3-amd64, x86_64: installed nvidia-current, 430.64, 5.4.0-1-amd64, x86_64: installed virtualbox, 6.1.0, 5.3.0-3-amd64, x86_64: installed virtualbox, 6.1.0, 5.4.0-1-amd64, x86_64: installed

Hopefully your driver gets accepted into the kernel so none of this will be necessary.

By default it gets installed only for the running kernel. You could instruct DKMS to install it for another kernel in your system. But from that point it should install for every new kernel that gets installed/updated, the same way your nvidia and virtualbox modules work. That's what DKMS does.

I think it's working for others. I'll try to check on my computer.

[berarma]

@azampatti: The module installed by DKMS shoud override the original module but in your system it seems it doesn't. Do you get some error when installing with DKMS? Seeing a log of your full install procedure could help.

[azampatti]

Okey, one interesting finding, but first... I've removed the module (new) and re-install it so I can share the output here:

Looks normal to me.

Now... I've rebooted and again, 'old' driver was loaded. If I unplug and re-plug the wheel, the old driver still loads.

BUT, if I boot the system with the wheel unplugged, and then plug it normally 'new' driver will load. I'll dig on the dmesg to see If I can find anything worth sharing.

[azampatti]

This might actually be useful. DMESG when booting with the wheel plugged in

DMESG output booting without the wheel plugged in and pluging it in after the fact:

Looks to me that at boot (first output) detects the wheel and loads the default (old) driver and from that moment on, unless manually unloaded, it will always use that one.

On the 2nd one, when I plug the wheel after the boot process, it will just load and defaults to the new driver.

[jotomo]

Error: Driver 'logitech' is already registered, aborting...

That bit seems interesting. I've seen that as well during boot, but haven't had the time to try to find out what's going on (currently using a script as a workaround to start DR2 that unloads/loads the module, overclocks the GPU overclocking and other bits to make DR2 run well).

Using ArchLinux here, so similar to yours.

[berarma]

Error: Driver 'logitech' is already registered, aborting...

That bit seems interesting. I've seen that as well during boot, but haven't had the time to try to find out what's going on (currently using a script as a workaround to start DR2 that unloads/loads the module, overclocks the GPU overclocking and other bits to make DR2 run well).

Using ArchLinux here, so similar to yours.

I see this message too and I think everyone does. It's related to both modules claiming they support the same device vendor ids. I would have liked to fix it but since it seems inoquous I haven't invested much time.

[berarma]

Okey, one interesting finding, but first... I've removed the module (new) and re-install it so I can share the output here:

Looks normal to me.

Now... I've rebooted and again, 'old' driver was loaded. If I unplug and re-plug the wheel, the old driver still loads.

BUT, if I boot the system with the wheel unplugged, and then plug it normally 'new' driver will load. I'll dig on the dmesg to see If I can find anything worth sharing.

The problem is that your kernel is loading the original module from the initramfs at boot. DKMS should be updating your initramfs automatically, but for some reason it's not doing it on your system.

You can do it manually: sudo update-initramfs -u -k all

If you're interested you could ask in your distro's support forums the reason it doesn't work.

[berarma]

I've added quotes around the setting value in dkms.conf just in case it makes a difference in some systems. Please, could you update from the master branch and try again? I'll do a new release if this fixes this issue. Thanks.

[azampatti]

`You can do it manually: sudo update-initramfs -u -k all

If you're interested you could ask in your distro's support forums the reason it doesn't work.`

This did the trick!!! :D The equivalent for Manjaro is: sudo mkinitcpio -p linux**XY** Where XY= kernel version, so 54 in my case for the 5.4.6-2 version I'm running. I'll uninstall everything now and re-try with the change you've made con dkms.conf

[azampatti]

I've added quotes around the setting value in dkms.conf just in case it makes a difference in some systems. Please, could you update from the master branch and try again? I'll do a new release in case if this fixes this issue. Thanks.

Same result as before. After mkinitcpio command is executed, it defaults to your driver.

[berarma]

Thanks for testing. I think this is an issue of DKMS on your system/distro. I don't know if there's something we can do to fix it.

[writequit]

Just updated to a new kernel, note that I am updating here to a non debian kernel but this is the same error I got when I last updated to a debian standard kernel:

`dkms: running auto installation service for kernel 5.4.0-8.2-liquorix-amd64: Kernel preparation unnecessary for this kernel. Skipping...

Building module: cleaning build area... make -j8 KERNELRELEASE=5.4.0-8.2-liquorix-amd64 KVERSION=5.4.0-8.2-liquorix-amd64... cleaning build area...

DKMS: build completed.

hid-logitech.ko: Running module version sanity check.

• Original module
  • No original module exists within this kernel
• Installation
  • Installing to /lib/modules/5.4.0-8.2-liquorix-amd64/updates/dkms/

depmod...

Warning: Unable to find an initial ram disk that I know how to handle. Will not try to make an initrd.

DKMS: install completed. `

I then ran: dkms remove new-lg4ff/0.2b --all and: dkms install /usr/src/new-lg4ff and I get a new initrd with no errors.

[berarma]

Just updated to a new kernel, note that I am updating here to a non debian kernel but this is the same error I got when I last updated to a debian standard kernel:

`dkms: running auto installation service for kernel 5.4.0-8.2-liquorix-amd64: Kernel preparation unnecessary for this kernel. Skipping...

Building module: cleaning build area... make -j8 KERNELRELEASE=5.4.0-8.2-liquorix-amd64 KVERSION=5.4.0-8.2-liquorix-amd64... cleaning build area...

DKMS: build completed.

hid-logitech.ko: Running module version sanity check.

* Original module

  * No original module exists within this kernel

* Installation

  * Installing to /lib/modules/5.4.0-8.2-liquorix-amd64/updates/dkms/

depmod...

Warning: Unable to find an initial ram disk that I know how to handle. Will not try to make an initrd.

DKMS: install completed. `

I then ran: dkms remove new-lg4ff/0.2b --all and: dkms install /usr/src/new-lg4ff and I get a new initrd with no errors.

I don't know the exact events but my guess is that when upgrading the kernel 'dkms autoinstall' was run before creating initramfs. Then initramfs would be created as the last step of the upgrade. In this case everything would be fine even though dkms said there was not ram disk to update when it ran. Did you check if it worked without removing and installing again?

[writequit]

No, I'll do that next time :)

[berarma]

Please, reopen if there's more information for this issue or open a new one for related problems.