Some Feeback on T248 Use

[MicHaeL-MonStaR]

Some Feeback on T248 Use

[MicHaeL-MonStaR]

Hi and thanks for the reply.

As for the Manual Installation error: It's very much like what's in the post you linked, but then it also said things like "warning: the compiler is not the same as used" and "vmlinux" is not available. - Seems to be some additional things, but I'm not sure if it all comes down to the same.

For a log of when the hard crash happened: I entered what you said and it does show something from yesterday, but I don't think it's from the time the crash happened. - It doesn't show much or anything special, as far as I can tell. - So I'll try to do it next time it might crash.
I don't know about Pop!_OS and its GNOME-environment. It can be a bit quirky, I think, and I've also noticed that the gnomeshell-issue, of it using a lot of the CPU the more programs and the longer you use it, happens consistently. - That said, I tested all this on a "fresh boot", when that issue isn't there (or at least small). - But generally speaking, I've had very few instances of this system just getting frozen up, and when it did it was likely because I used too much RAM and it would grind to a halt (but not completely frozen).
And again, it could just be a Proton-thing with the game in general, I'm not sure. - It's just that I haven't played this game for long enough to say if it would do that without this driver or wheel anyway.

For 'Race Driver: GRID', I did get it on Steam when it was still available years ago, and it still works (unlike "DiRT 2" for some reason, which I would've sworn worked through Proton, or I would've tested the wheel with that as well). - Maybe I should check if there's a device-conflict. I might have had an Xbox-style gamepad plugged in, which I could imagine being an issue. So I'll try something with that, also if THAT even gets detected in the menu. - But at least it adds wheel-functionality at all.

As for that weird issue with Rally Cross: I tried playing it again, but while the first racer (or practice-round or whatever) it didn't do that, it did do it with each next one. - I can link a quick phone-video to it happening here: https://youtu.be/dWfRRly5BtI
It starts when already acting up, and then I start another practice-round and you can see that it immediately "completes" the race when it's actually time to initiate the handbrake, which happens automatically, but it then also immediately releases it, prompting the game to end the race (and this is a disqualification in a real race). - The only way to avoid this is to turn off the manual "handbrake-start" completely, or perhaps a different button or something could work.
But then, you can tell the entire wheel is acting up anyway, so I guess it's getting all the wrong signals somehow.

Finally, about the on-board settings: I've gone through everything, but while I've only set the settings under Mode to preference, I don't know what the flippy buttons on the left and right do exactly, if anything for the wheel at all. - So basically I've only changed the Force, Rotation, something about the pedal-placement I think, maybe one more thing, at least intentionally. - Other things in that menu seem to be for monitoring, like the temperature and such.

Hope this helps a bit.

[Kimplul]

Thanks for the report, appreciate it. Glad to hear the Xbox version of the wheel more or less works, I only have the PS version to test with. Presumably they're effectively identical with some logos switched around, but it's possible that each version has some quirks that should be handled in the driver and that I'm currently only handling some of them.

Anyway, I followed the steps on the main page, which first is adding the dependencies. I don't know a whole lot about using Linux or at least the terminal, but it seemed to not apply or be necessary. As in, it said no changes were made, so I can only assume perhaps the dependencies were already present or something like that.
To be specific, I used the Debian-method because I use the Ubuntu-based Pop!_OS. - That's all I know.

A lot of the more plug-and-play distributions tend to come with a lot of packages preinstalled, so that's normal. Some more cut-down distros would still have to run those installation commands, for example a minimal Debian installation, which I tend to use. Maybe good to know that Pop!_OS belongs in the plug-and-play category for future reference, but running the commands to be safe doesn't hurt.

I decided to move on and first try the Manual Installation, but also there it came up with some errors and things like non-existent directories. - So I tried the DKMS-method, which simply worked.

Could you paste the errors here? DKMS is 'just' a wrapper around the manual installation procedure, so if one fails I would kind of expect the other one to fail as well. Could it be that you ran into this? There's a note about it in the installation instructions, but it could maybe be more obvious.

In 'DiRT Rally', while it mostly worked fine, there was a case where, when trying a quick Rally Cross event, for some reason it would act up at the start where you have to hold the handbrake, which I have simply programmed under a button (LSB). It would seem to give a repeated input (as if I were pressing it repeatedly, but without touching anything at all) and of course immediately make me fail the race because of a "false start" (cause you can't let go until "GO!"). On top of that, on the result-screen, the wheel would also start turning randomly. - This actually puts it in a loop, unless you "Save & Exit".
This all didn't happen before, without this software, with Rally Cross, but it also doesn't happen with other events. (Though, I need to try a Rally Cross event again to see if it always happens.) - So it can be very game-specific, even though it does seem like an input/output-issue.

Interesting, haven't run into this behaviour myself, though I don't really play rallycross. I'll see if I can replicate this on my end. Button (or, more specifically, pedal) behaviour has been reported to have inconsistencies before. The path from device to Linux to Wine to game can be long and pretty messy in places, so it's not unthinkable that there are bugs or some things that I've missed. Out of curiosity, the T248 has some settings accessible through the LCD, have you changed any of them?

There was also a fatal crash with this game for the first time in 10-12 hours of playing in the last few weeks, where it just froze the entire system. - But that could be anything or coincidental. I'm not sure. - I've been running the game with Proton 8.0-4.

I assume this was a little while ago and you don't have system logs of the crash? If this happens again, please run sudo journalctl --boot=-1 directly afterwards and look at the end of the output. Typically the Linux kernel will print out some message when it encounters fatal errors that can help pinpoint what the issue could be. The ideal case would be to find some way to consistently replicate the crash, but that tends to be rather difficult.

I might also note that there a couple different ways a system can appear completely frozen, one cause could be this driver doing something dumb and crashing the kernel, which I would take very seriously. Another possibility is the desktop environment freezing, which would be a separate issue from this driver. I know Pop!_OS is developing their own spin on a desktop environment, I have no idea how stable it is or if it's even relevant to the discussion, but without some kind of logs or something I can unfortunately only guess at things.

In 'Race Driver: GRID', while it works for gameplay, the game doesn't recognize the wheel's input/output at all within the menus (other than when mapping the controls). So I can't navigate the menus with the wheel's buttons, despite having programmed the buttons for it in the game itself, while 'DiRT Rally' has no issue with that.
Though, this is where the Thrustmaster-drivers might be necessary, so that it actually gets recognized completely, I suppose. Or more specifically as an Xbox-style controller (which is the version of the T248 I have), with the buttons showing as A, B, X, Y, Menu, and so on, which currently games seem to see more as "generic" numbered buttons. - Am I right in thinking that?

It's possible that the official drivers need to be installed, but that would be a first for me. Did you buy GRID on Steam before it was pulled or are you playing it through something else? I don't seem to have the game and Steam apparently doesn't sell it anymore, so replicating this might be a bit tricky.

Yeah, typically Xbox controllers are the 'default' for unknown controllers, so A/B/X/Y buttons tend to pop up in some surprising places. There are a number of games that rely on some kind of wheel database to detect which controllers are wheels and which are just generic controllers, sometimes we've managed to add these wheels under Linux to the databases (see for example #38) and 'enabled' better support for some games. Unsure if GRID might fall into this category as well, but regardless, I would still expect it to respect generic controller input enough to work in menus and so on even if the game can't positively detect the controller as a wheel so I'm slightly stumped. Please do add a comment if you find out something new.

[Kimplul]

As for the Manual Installation error: It's very much like what's in the post you linked, but then it also said things like "warning: the compiler is not the same as used" and "vmlinux" is not available. - Seems to be some additional things, but I'm not sure if it all comes down to the same.

Yeah, I'm fairly certain it's the same issue. In other words, the driver probably installed fine the first time around, just printed a misleading message. Sorry, not a great experience for people just getting started with command lines, but unfortunately out of my control, unless I start demanding people sign their modules which would make the installation way more cumbersome.

For a log of when the hard crash happened: I entered what you said and it does show something from yesterday, but I don't think it's from the time the crash happened. - It doesn't show much or anything special, as far as I can tell. - So I'll try to do it next time it might crash.

Great, thanks. The parameter --boot=-1 means 'show me the logs generated the boot before this one', so unless you haven't rebooted in a couple weeks, it was probably not the logs we're looking for. You can run man jounalctl for an overview of the available parameters for journalctl. Depends on the system, but usually logs are kept for around a week, so it could be a good idea to save the crash log to a file for safe keepings, something like sudo journalctl --boot=-1 > whatever.txt.

[...] - I can link a quick phone-video to it happening here: https://youtu.be/dWfRRly5BtI [...]

Yeah, looks pretty annoying.

Finally, about the on-board settings: I've gone through everything, but while I've only set the settings under Mode to preference, I don't know what the flippy buttons on the left and right do exactly, if anything for the wheel at all. - So basically I've only changed the Force, Rotation, something about the pedal-placement I think, maybe one more thing, at least intentionally. - Other things in that menu seem to be for monitoring, like the temperature and such.

Okay, sounds like a fair few changes. I'll just play around with the wheel for a bit and see if I can come up with something, haven't yet started DiRT up but I'll try to make time for it this week.

[MicHaeL-MonStaR]

I have just tested a bit more and found some additional things:

First: I've accidentally lied about the "only workaround" for the handbrake-issue with Rally Cross: You can actually avoid it by just holding down the handbrake immediately, then it won't act up.
The only downside then is that you don't get a moment to prepare, which I usually take a few seconds to do before I go. Oh well, just something to keep in mind then. - But if you don't hold it within a second or two, it will just start throwing a fit.

I've tried it without the gamepad connected and it doesn't make a difference, it still does it. - That said, it doesn't respond to the gamepad when it's set to the wheel anyway, not even in the menus or during replay. It's just "off" then, which takes that out of the equation I suppose.

What's also interesting is that the handbrake-issue doesn't happen with the Rally and Hillclimb modes, I believe, and I think it has only crashed during Rally Cross as well. - So, seemingly there's something weird going on with that mode.

Speaking of which, I've just had another hard crash and here's what the readout is:

Dec 04 00:55:31 pop-os kernel: Linux version 6.5.6-76060506-generic ([email protected]) (x86_64-linux-gnu-gcc-12 (Ubuntu 12.3.0-1ubuntu1~22.04) 12.3.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #202310061235~1697396945~22.04~9283e32 SMP PREEMPT_DYNAMIC Sun O
Dec 04 00:55:31 pop-os kernel: Command line: initrd=\EFI\Pop_OS-4e2e253a-80c6-46a8-b2db-e4011816b63a\initrd.img root=UUID=4e2e253a-80c6-46a8-b2db-e4011816b63a ro quiet loglevel=0 systemd.show_status=false splash
Dec 04 00:55:31 pop-os kernel: KERNEL supported cpus:
Dec 04 00:55:31 pop-os kernel:   Intel GenuineIntel
Dec 04 00:55:31 pop-os kernel:   AMD AuthenticAMD
Dec 04 00:55:31 pop-os kernel:   Hygon HygonGenuine
Dec 04 00:55:31 pop-os kernel:   Centaur CentaurHauls
Dec 04 00:55:31 pop-os kernel:   zhaoxin   Shanghai  
Dec 04 00:55:31 pop-os kernel: BIOS-provided physical RAM map:
Dec 04 00:55:31 pop-os kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009ffff] usable
Dec 04 00:55:31 pop-os kernel: BIOS-e820: [mem 0x00000000000a0000-0x00000000000fffff] reserved
Dec 04 00:55:31 pop-os kernel: BIOS-e820: [mem 0x0000000000100000-0x0000000009d81fff] usable
Dec 04 00:55:31 pop-os kernel: BIOS-e820: [mem 0x0000000009d82000-0x0000000009ffffff] reserved
Dec 04 00:55:31 pop-os kernel: BIOS-e820: [mem 0x000000000a000000-0x000000000a1fffff] usable
Dec 04 00:55:31 pop-os kernel: BIOS-e820: [mem 0x000000000a200000-0x000000000a20dfff] ACPI NVS
Dec 04 00:55:31 pop-os kernel: BIOS-e820: [mem 0x000000000a20e000-0x000000000affffff] usable
Dec 04 00:55:31 pop-os kernel: BIOS-e820: [mem 0x000000000b000000-0x000000000b01ffff] reserved
Dec 04 00:55:31 pop-os kernel: BIOS-e820: [mem 0x000000000b020000-0x00000000bae78fff] usable
Dec 04 00:55:31 pop-os kernel: BIOS-e820: [mem 0x00000000bae79000-0x00000000bb1f8fff] reserved
Dec 04 00:55:31 pop-os kernel: BIOS-e820: [mem 0x00000000bb1f9000-0x00000000bb25cfff] ACPI data
Dec 04 00:55:31 pop-os kernel: BIOS-e820: [mem 0x00000000bb25d000-0x00000000bc95bfff] ACPI NVS
Dec 04 00:55:31 pop-os kernel: BIOS-e820: [mem 0x00000000bc95c000-0x00000000bdbfefff] reserved
Dec 04 00:55:31 pop-os kernel: BIOS-e820: [mem 0x00000000bdbff000-0x00000000beffffff] usable
Dec 04 00:55:31 pop-os kernel: BIOS-e820: [mem 0x00000000bf000000-0x00000000bfffffff] reserved
Dec 04 00:55:31 pop-os kernel: BIOS-e820: [mem 0x00000000f0000000-0x00000000f7ffffff] reserved
Dec 04 00:55:31 pop-os kernel: BIOS-e820: [mem 0x00000000fd200000-0x00000000fd2fffff] reserved
Dec 04 00:55:31 pop-os kernel: BIOS-e820: [mem 0x00000000fd600000-0x00000000fd7fffff] reserved
Dec 04 00:55:31 pop-os kernel: BIOS-e820: [mem 0x00000000fea00000-0x00000000fea0ffff] reserved
Dec 04 00:55:31 pop-os kernel: BIOS-e820: [mem 0x00000000feb80000-0x00000000fec01fff] reserved
Dec 04 00:55:31 pop-os kernel: BIOS-e820: [mem 0x00000000fec10000-0x00000000fec10fff] reserved
Dec 04 00:55:31 pop-os kernel: BIOS-e820: [mem 0x00000000fec30000-0x00000000fec30fff] reserved
Dec 04 00:55:31 pop-os kernel: BIOS-e820: [mem 0x00000000fed00000-0x00000000fed00fff] reserved
Dec 04 00:55:31 pop-os kernel: BIOS-e820: [mem 0x00000000fed40000-0x00000000fed44fff] reserved
Dec 04 00:55:31 pop-os kernel: BIOS-e820: [mem 0x00000000fed80000-0x00000000fed8ffff] reserved
Dec 04 00:55:31 pop-os kernel: BIOS-e820: [mem 0x00000000fedc2000-0x00000000fedcffff] reserved
Dec 04 00:55:31 pop-os kernel: BIOS-e820: [mem 0x00000000fedd4000-0x00000000fedd5fff] reserved
Dec 04 00:55:31 pop-os kernel: BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved
Dec 04 00:55:31 pop-os kernel: BIOS-e820: [mem 0x0000000100000000-0x000000083f37ffff] usable
Dec 04 00:55:31 pop-os kernel: BIOS-e820: [mem 0x000000083f380000-0x000000083fffffff] reserved
Dec 04 00:55:31 pop-os kernel: NX (Execute Disable) protection: active
Dec 04 00:55:31 pop-os kernel: e820: update [mem 0xb6a2b018-0xb6a39057] usable ==> usable
Dec 04 00:55:31 pop-os kernel: e820: update [mem 0xb6a2b018-0xb6a39057] usable ==> usable
Dec 04 00:55:31 pop-os kernel: e820: update [mem 0xb6a0c018-0xb6a2a257] usable ==> usable
Dec 04 00:55:31 pop-os kernel: e820: update [mem 0xb6a0c018-0xb6a2a257] usable ==> usable
Dec 04 00:55:31 pop-os kernel: extended physical RAM map:
Dec 04 00:55:31 pop-os kernel: reserve setup_data: [mem 0x0000000000000000-0x000000000009ffff] usable
Dec 04 00:55:31 pop-os kernel: reserve setup_data: [mem 0x00000000000a0000-0x00000000000fffff] reserved
Dec 04 00:55:31 pop-os kernel: reserve setup_data: [mem 0x0000000000100000-0x0000000009d81fff] usable
Dec 04 00:55:31 pop-os kernel: reserve setup_data: [mem 0x0000000009d82000-0x0000000009ffffff] reserved
Dec 04 00:55:31 pop-os kernel: reserve setup_data: [mem 0x000000000a000000-0x000000000a1fffff] usable
Dec 04 00:55:31 pop-os kernel: reserve setup_data: [mem 0x000000000a200000-0x000000000a20dfff] ACPI NVS
Dec 04 00:55:31 pop-os kernel: reserve setup_data: [mem 0x000000000a20e000-0x000000000affffff] usable
Dec 04 00:55:31 pop-os kernel: reserve setup_data: [mem 0x000000000b000000-0x000000000b01ffff] reserved
Dec 04 00:55:31 pop-os kernel: reserve setup_data: [mem 0x000000000b020000-0x00000000b6a0c017] usable
Dec 04 00:55:31 pop-os kernel: reserve setup_data: [mem 0x00000000b6a0c018-0x00000000b6a2a257] usable
Dec 04 00:55:31 pop-os kernel: reserve setup_data: [mem 0x00000000b6a2a258-0x00000000b6a2b017] usable
Dec 04 00:55:31 pop-os kernel: reserve setup_data: [mem 0x00000000b6a2b018-0x00000000b6a39057] usable
Dec 04 00:55:31 pop-os kernel: reserve setup_data: [mem 0x00000000b6a39058-0x00000000bae78fff] usable
Dec 04 00:55:31 pop-os kernel: reserve setup_data: [mem 0x00000000bae79000-0x00000000bb1f8fff] reserved
Dec 04 00:55:31 pop-os kernel: reserve setup_data: [mem 0x00000000bb1f9000-0x00000000bb25cfff] ACPI data
Dec 04 00:55:31 pop-os kernel: reserve setup_data: [mem 0x00000000bb25d000-0x00000000bc95bfff] ACPI NVS
Dec 04 00:55:31 pop-os kernel: reserve setup_data: [mem 0x00000000bc95c000-0x00000000bdbfefff] reserved
Dec 04 00:55:31 pop-os kernel: reserve setup_data: [mem 0x00000000bdbff000-0x00000000beffffff] usable
Dec 04 00:55:31 pop-os kernel: reserve setup_data: [mem 0x00000000bf000000-0x00000000bfffffff] reserved
Dec 04 00:55:31 pop-os kernel: reserve setup_data: [mem 0x00000000f0000000-0x00000000f7ffffff] reserved
Dec 04 00:55:31 pop-os kernel: reserve setup_data: [mem 0x00000000fd200000-0x00000000fd2fffff] reserved
Dec 04 00:55:31 pop-os kernel: reserve setup_data: [mem 0x00000000fd600000-0x00000000fd7fffff] reserved
Dec 04 00:55:31 pop-os kernel: reserve setup_data: [mem 0x00000000fea00000-0x00000000fea0ffff] reserved
Dec 04 00:55:31 pop-os kernel: reserve setup_data: [mem 0x00000000feb80000-0x00000000fec01fff] reserved
Dec 04 00:55:31 pop-os kernel: reserve setup_data: [mem 0x00000000fec10000-0x00000000fec10fff] reserved
Dec 04 00:55:31 pop-os kernel: reserve setup_data: [mem 0x00000000fec30000-0x00000000fec30fff] reserved
Dec 04 00:55:31 pop-os kernel: reserve setup_data: [mem 0x00000000fed00000-0x00000000fed00fff] reserved
Dec 04 00:55:31 pop-os kernel: reserve setup_data: [mem 0x00000000fed40000-0x00000000fed44fff] reserved
Dec 04 00:55:31 pop-os kernel: reserve setup_data: [mem 0x00000000fed80000-0x00000000fed8ffff] reserved

There's nothing that really seems to indicate an error, unless you see something in this. - I don't even understand why Mr. Jenkins' e-mail is in there...

Don't worry about the annoyances though, I know this is all experimental and Linux is just quirky all over the place.
As long as it doesn't blow up my wheel, it's fine, and even that would technically be my responsibility. XD
So far, the worst thing is the occasional crashing, and we don't even know what causes that. - If this log doesn't indicate anything, do you know any other way to find data? - Perhaps the game itself has crash-logs?

[Kimplul]

I played a little bit of rallycross, afraid I couldn't replicate anything. I didn't play for long, so could be that I just didn't run across the specific conditions that would cause the symptoms you're describing. Could you please clarify exactly which track, car etc. you're using? If the issues are only happening in one gamemode under some specific conditions, it could be that there's some setting that for some reason differs between our two installs, so I'd like to get as close to your setup as reasonably possible.

[...] There's nothing that really seems to indicate an error, unless you see something in this. - I don't even understand why Mr. Jenkins' e-mail is in there...

That looks like the start of a log file, are you sure there wasn't more? You would probably have to scroll down for a bit to reach the bottom, usually the logs are pages and pages of stuff.

I don't even understand why Mr. Jenkins' e-mail is in there...

Jenkins is a CI/CD tool, seems like Pop!_OS have automated their kernel compilations and the build system adds the name and machine running it to the final result. Nothing out of the ordinary.

If this log doesn't indicate anything, do you know any other way to find data? - Perhaps the game itself has crash-logs?

DiRT doesn't seem to have logging, as far as I can tell. You can collect everything the game spits out by adding %command > ~/whatever.txt, to the launch options in steam, but at least when I tried it the resulting file was empty. Besides, if the system crashes, the game likely won't be aware of it.

That being said, if you crash again, you can try pressing CTRL-ALT-F1 through CTRL-ALT-F7. If you get dropped to a login prompt, the kernel itself is (probably) fine and the issue is somewhere else. From the login prompt, you can log in and do a more controlled reboot. Otherwise, the kernel is dead and this driver is (probably) to blame, but some kind of logs would still be required to diagnose further.

[MicHaeL-MonStaR]

I played a little bit of rallycross, afraid I couldn't replicate anything. I didn't play for long, so could be that I just didn't run across the specific conditions that would cause the symptoms you're describing. Could you please clarify exactly which track, car etc. you're using? If the issues are only happening in one gamemode under some specific conditions, it could be that there's some setting that for some reason differs between our two installs, so I'd like to get as close to your setup as reasonably possible.

I didn't really think about which track or anything, but I think I did happen to just go for the same one both times.
Now I'm also wondering what would happen if I'd use something completely different, so I'll try that next time. - Tell me which settings you want to know, if anything.

[...] There's nothing that really seems to indicate an error, unless you see something in this. - I don't even understand why Mr. Jenkins' e-mail is in there...

That looks like the start of a log file, are you sure there wasn't more? You would probably have to scroll down for a bit to reach the bottom, usually the logs are pages and pages of stuff.

That was it, really. It fit on the screen exactly, so it wasn't much. - The only thing I believe I left out was a line that said... well, how many lines there are in the log above.

I don't even understand why Mr. Jenkins' e-mail is in there...

Jenkins is a CI/CD tool, seems like Pop!_OS have automated their kernel compilations and the build system adds the name and machine running it to the final result. Nothing out of the ordinary.

Ah, thanks for explaining.

If this log doesn't indicate anything, do you know any other way to find data? - Perhaps the game itself has crash-logs?

DiRT doesn't seem to have logging, as far as I can tell. You can collect everything the game spits out by adding %command > ~/whatever.txt, to the launch options in steam, but at least when I tried it the resulting file was empty. Besides, if the system crashes, the game likely won't be aware of it.

That being said, if you crash again, you can try pressing CTRL-ALT-F1 through CTRL-ALT-F7. If you get dropped to a login prompt, the kernel itself is (probably) fine and the issue is somewhere else. From the login prompt, you can log in and do a more controlled reboot. Otherwise, the kernel is dead and this driver is (probably) to blame, but some kind of logs would still be required to diagnose further.

It seemed it was entirely stuck as no input gave any response and I also heard the sound stuck. You know that horrible buzz it makes, probably from looping a tiny fraction of audio. - So unless the Ctr+Alt+F# method overrides something, I think it would still be stuck. - But I will try it next time for sure.

[Kimplul]

I didn't really think about which track or anything, but I think I did happen to just go for the same one both times.
Now I'm also wondering what would happen if I'd use something completely different, so I'll try that next time. - Tell me which settings you want to know, if anything.

Let's start with track, car, weather. I could maybe imagine that for example slippery conditions could cause different behaviour than dry or something.

That was it, really. It fit on the screen exactly, so it wasn't much. - The only thing I believe I left out was a line that said... well, how many lines there are in the log above.

Apologies if I sound patronizing, but seems like a massive coincidence that the whole log would exactly fit onto one screen. Could you confirm that you tried pressing up/down arrow keys or page up/down or something?

If the journalctl logs really are more or less completely empty, I guess the only way to get any reasonable logs (besides coming up with a way to replicate the crash so I could directly investigate it on my machine) is to have a terminal open on a second screen or something and having sudo dmesg -w outputting kernel logs as they come in. In some cases, the kernel crashes before systemd has time to collect the error logs.

It seemed it was entirely stuck as no input gave any response and I also heard the sound stuck. You know that horrible buzz it makes, probably from looping a tiny fraction of audio. - So unless the Ctr+Alt+F# method overrides something, I think it would still be stuck. - But I will try it next time for sure.

Yeah, does kind of sound like a kernel crash. I have experienced some individual game crashes that kept repeating some sound, but no input would point towards the kernel. Still, as previously mentioned, without logs of some kind or being able to replicate the issue it's difficult for me to say anything for sure, sorry. I have looked over my code a couple of times, but nothing immediately obvious has stood out.

[MicHaeL-MonStaR]

I didn't really think about which track or anything, but I think I did happen to just go for the same one both times.
Now I'm also wondering what would happen if I'd use something completely different, so I'll try that next time. - Tell me which settings you want to know, if anything.

Let's start with track, car, weather. I could maybe imagine that for example slippery conditions could cause different behaviour than dry or something.

OK, I have some time now, so I'll try to actually hunt for a crash and keep note of what exactly was used.

That was it, really. It fit on the screen exactly, so it wasn't much. - The only thing I believe I left out was a line that said... well, how many lines there are in the log above.

Apologies if I sound patronizing, but seems like a massive coincidence that the whole log would exactly fit onto one screen. Could you confirm that you tried pressing up/down arrow keys or page up/down or something?

No, it's OK. - But I had tried scrolling up and down and there was nothing beyond what I grabbed, although I did already think that was very little information.

If the journalctl logs really are more or less completely empty, I guess the only way to get any reasonable logs (besides coming up with a way to replicate the crash so I could directly investigate it on my machine) is to have a terminal open on a second screen or something and having sudo dmesg -w outputting kernel logs as they come in. In some cases, the kernel crashes before systemd has time to collect the error logs.

I do happen to still have a second screen up, so I can actually do that.
So if I type sudo dmesg -w it will just start posting events in the Terminal? - I suppose the point would be so that I could still see the last thing as it would freeze up and I could still take a note or picture or something.

It seemed it was entirely stuck as no input gave any response and I also heard the sound stuck. You know that horrible buzz it makes, probably from looping a tiny fraction of audio. - So unless the Ctr+Alt+F# method overrides something, I think it would still be stuck. - But I will try it next time for sure.

Yeah, does kind of sound like a kernel crash. I have experienced some individual game crashes that kept repeating some sound, but no input would point towards the kernel. Still, as previously mentioned, without logs of some kind or being able to replicate the issue it's difficult for me to say anything for sure, sorry. I have looked over my code a couple of times, but nothing immediately obvious has stood out.

I wouldn't be surprised if it's just something quirky in my system in general, even though I haven't messed with much serious over the last 10 months or so of this Linux-install, and the game itself was installed just weeks ago. - Oh, I was also wondering if you're running the game's Linux-port by Feral or also through Proton? - That might make a significant difference. But I think I had mentioned I was running it through Proton, so you probably know.

[Kimplul]

No, it's OK. - But I had tried scrolling up and down and there was nothing beyond what I grabbed, although I did already think that was very little information.

Alright, wow. I was not expecting that, pretty much all other logs I've received have been pages and pages of stuff, maybe Pop!_OS just has some weird configuration values set or something. Interesting.

So if I type sudo dmesg -w it will just start posting events in the Terminal? - I suppose the point would be so that I could still see the last thing as it would freeze up and I could still take a note or picture or something.

Correct, and that's the idea, yeah.

Oh, I was also wondering if you're running the game's Linux-port by Feral or also through Proton? - That might make a significant difference. But I think I had mentioned I was running it through Proton, so you probably know.

Yeah, I'm running through Proton, but an important thing to clarify. Good catch.

[MicHaeL-MonStaR]

Hi - It has been a while, but just a bit of an update on the weird crashing-issue I had: I had actually tried to replicate it multiple times, but couldn't GET 'Dirt Rally' to crash anymore. - So I also don't have anything of a log to show for.
The weird handbrake-input (or whatever it is) still occurs, but perhaps that's just the game bugging (like how it doesn't like the Esc-key remapped either), cause I didn't have issues in other racing-games I've tried since (although "WRC9" doesn't give FFB).
But as for the crashing, I kind of suspect it might had to do with a gamepad being connected to a specific port and causing conflict simply by existing in the system. But that's the best theory I can come up with. - I do have another controller, being a keypad, hooked up, even using Input Remapper for it, but that doesn't seem to create issues either. I even use it to change car-setup during gameplay and that's no problem.

[Kimplul]

Hello again, thanks for the update. Glad there haven't been more crashes, though sort of unfortunate there still isn't any definite proof one way or the other about the cause.

Out of curiosity, did you ever try remapping the handbrake to some other button?

although "WRC9" doesn't give FFB

Could be something akin to #38, but don't know for sure, sorry. Don't have the game myself so can't really check.

[MicHaeL-MonStaR]

Hello again, thanks for the update. Glad there haven't been more crashes, though sort of unfortunate there still isn't any definite proof one way or the other about the cause.

Out of curiosity, did you ever try remapping the handbrake to some other button?

That's a good suggestion, I don't know why I didn't think to do that.
I've just tried it, mapping Handbrake from LSB/10 to Space, and then it didn't do the thing anymore. However, when I mapped it back, it also didn't do it anymore, so... I don't know what's going on. - By chance it might be that I'm using the Feral-port, but I thought it did it with both versions, so now I'm not sure.

although "WRC9" doesn't give FFB

Could be something akin to #38, but don't know for sure, sorry. Don't have the game myself so can't really check.

I'll look into that. I probably won't play WRC9 anymore, but just in case I'll play 'Dirt Rally 2.0' and it happens. - Thanks for the suggestion.