Linux Port – Feedback, Known Issues, and FAQ

HDR output appears to be broken in 0.40. The option is there to enable it but it seems to be running inside an SDR container so all the highlights get blown out.

Running on KDE with Wayland and Nvidia GPU.

 

anyone else having crashes on interacting with the buttons in the cars? im running fedora 43 with plasma 6.6 on wayland, specs are a rx 7600 and a 5600g with 16gb of ram, also still having flickering on fullscreen and what appears to be slight stutters

 

Yes. Very slight but persistent with the native linux version. Sometimes seems to be happening with lighting changes (eg driving through shadowy patches), but still can't tell for sure what is causing it. 7900xt, 9950x3d.

 

1. HDR is also broken for me. While also blown out the image also gets a pretty ugly green tint for some reason.
2. DX12 with every Proton version(Cachy-latest, GE-latest, Stable, Experimental) has the exploding geometry issues
3. Windows Vulkan via Proton doesnt even start.
3. Heres my post in the regular 0.40 thread how to switch to the native linux version: https://www.beamng.com/threads/0-40-discussion-thread.112018/page-3#post-1974797
4. At the first start /first time loading a level the loading screen seems to be broken on the native linux version. showing no progress. still loads into the map eventually
5. I consulted the Optiscaler Discord and there isnt a Linux native build as of now from what i understand. So no FSR4 upgrades for us on Linux for the very moment.

Now we wait until either a Beamng or Proton patch arrives. Or for the Linux native Optiscaler build later. Or for AMD to get their... stuff together much later.

Edit: Fresh install and deleted the old user folder.

 

I am having constant issues with stuttering since updating, there are some stutters on the dx12 version but that may be related to the INSANE goddam artifacts I am getting where besically every LOD affected object is trying to give me seizures.

My hardware is defo not the issue as I am running a 12400F, RX 9070 XT and 32GB of ddr5.

 

any workaround for the flickering in fullscreen other than run in windoed mode?

 

Clickable buttons, switches and seats seem to be a bit broken on Linux for me. They just kinda stop working and start flickering and sometimes just don't highlight when I hover over them. On Windows it works fine. Seems to get worse the more you try to interact or if you change between windowed and borderless. Also, might not be related to Linux but on one occasion when loading grid small pure in safe mode the ground just didn't load in and the D-Series just started falling. Not sure how it happened or how to replicate.

Linux Mint 22.3 with Nvidia driver version 615.71.09

 

Running dx12 via proton (ge 11-9 and experimental) produces insane graphical glitches. Vulkan doesnt launch at all, dx11 works but has awful performance. And native version while working great in almost every way doesnt have fsr 4 . Fsr 3 while better then smaa is blurry
Gpu rx 9060xt 16gb, cpu ryzen 3600x, 16gb ram, arch linux with latest stable mesa

 

Running dx12 mode via proton is borked. Vulkan and dx11 are fine. Tried a few different versions (experimental, 11, 10, GE11-7)

 

Why would you? Just use the native Linux binary.

 

Performance.

While 0.38 ran just better in every aspect for me on the linux native build but 0.39 was a mixed bag. CPU overhead was still smaller but rendertimes on DX12 were quite a bit better even when running through Proton. Also with DX12 you could inject better upscalers with Optiscaler or HelixSR. Which would be my main reason to use Beam via Proton when the current graphics glitches get fixed. FSR4/DLSS look just sooo much better than FSR3. tbf kudos to the devs its one of the best FSR3 implementations i've seen. Its a bit blurry but the temporal artifacts like smearing are barely noticeable compared to other games.

 

Post 0.40 / Native Linux / wayland / Steam

CachyOS
KDE Plasma
Wayland

Minor Question:
Bob the silly, appears to not have an option to be repainted. He also refuse to be saved as the game very counterintuitively says something like "You can not save while walking" ... So umm... How then?
I've never been able to save a vehicle config without also having that same vehicle as the used one - including the "walker" / "person" thingy.

Weird issue:
Any time I close BeamNG and then start it up, it crashes without a proper error message.
Took me a good while to figure out that for whatever oddball reason, BeamNGs equivalent of "modlist", a file named db.json that is created by the game itself on startup is causing this.
I have to manually remove that file before starting up BeamNG again.

DLSS is causing some minor... "ghosting" I think its called. Only on external camera tho, such as the Orbit cam. It's most visible on exterior rear view mirrors in my case.
While its not a particularly big deal as I spend most of my driving from inside the car, the driver position, and from there, I haven't seen any such anomalies.

Saved Configs were supposed to have been fixed with this update according to patch notes but I have same issue that was introduced with 0.39 still.
It creates configs in new strangely named folders rather then inside the same folder the parent vehicle is.
It saves them with no vehicle thumbnail (vehicle select menu) and while it does load the cars into the game, the issue of failing to load the colors they were saved with previously, is still there as well. More so on moded cars then others, wich is to be expected I guess, but vanilla vehicles also do these things where they use the colors from previously driven vehicle and the license plate text is also either carried over from previous vehicle, or getting a randomly generated one.

I also noted a significant loss of FPS with 0.40 compared to 0.39 - and on a side-note to that, 0.39 also suffered performance loss compared to 0.38... Like... It feels the game is going in the wrong direction here

The headlights are still completely worthless as well. That bad bad dynamic light that was introduced with 0.39 is hopeless! Night becomes WAY to black and even high beams, I barely see anything at all of the road surface beyond what appears to be like 10-15 meters in front of the car at best - some cars dont light up barely anything at all of the road.
The area lit up from high beams are no better then low beams because of how the automatic EV crap is making them all just goof up. The stronger the light, the worse it gets dimmed down. So what the heck is the point with it then?
I think that worked a LOT better pre 0.39, especially if you had made changed in files like "headlight.jbeam" to color, angle and most importantly, the RANGE of the light cone.

It feels like the whole dynamic lightning (auto EV Bias adjusting) need an option for us to turn it off completely.
If I want high beams that light up the road 600 meter ahead of me (Rally in the woods with 4-6 extra spotlights on the roof for example) - I could do that pre 0.39 but now... Its barely noticeable compared to regular puny low beams.
Something is definately off with that system I think.
Turning signals are also utterly invisible daytime and on many cars, so are the breaking lights.
And speaking of turning signals... Whos brilliant idea was it to have the bloody hazard lights turn on every flippin time a car stops barely outside the road, or parking on a lawn next to a house, doing a vehicle recovery after crash, or simply doing a hard brake of any kind? That is so annoyingly unnecessary LOL

I run Beam on native Linux as mentioned above, but a friend mine runs it on Windows and have seen exact same problems there with the headlights being incredibly insufficient compared with real life cars. Especially the high beams.

Just my 2 cent on this...

 

Are you using any extra environment variables to get this working? It was fine for me on 0.39. I can work around the problem using Gamescope for now.

 

yea i forgot to say but i don't have this issue with proton. Is this just a... NVIDIA issue or something?

 

the crashes i've appear to be related to steam overlay, and like i mentioned on the previous post im runing on a amd rx 7600

 

Edit: This issue only happens with the flatpak version of Steam. In the non-flatpak version of Steam I can start the game just fine.

Kubuntu 26.04 LTS (Plasma 6.6.6)
Kernel 6.19.0 (I mostly run rc kernels, but I wanted to exclude that as a cause of the issue)
13700k 64GiB, 6800XT (16GiB)

Running Steam via Flatpak (app/com.valvesoftware.Steam/x86_64/stable)

Using the Linux binary of the game.

I already hat start issues with the 0.39 version. Where the game randomly (more then 50%) crashes during start, but otherwise would run fine.
But with 0.40 it is rally hard to get the game to start at all. But it works fine if I mange to get it starting.

Note that I run the flatpak version of Steam, because that works best with all the games I run via proton. But this also puts native linux binaries in the flatpak enviroment with specific versions of system libraries (Steam Linux Runtime 3.0).

Considering how random the issue was in 0.39, I would suspect some kind of race condition?! If I see the windows of the game pop up, I know it works and it will start fine.

Here are some traces:

----------
PID: 7705 (BeamNG.drive.x6)
UID: 1000 (xxx)
GID: 1000 (xxx)
Signal: 5 (TRAP)
Timestamp: Tue 2026-10-20 15:59:58 CEST (5s ago)
Command Line: /home/xxx/.var/app/com.valvesoftware.Steam/.local/share/Steam/steamapps/common/BeamNG.drive/BinLinux/BeamNG.drive.x64 -forceCloud on
Executable: /home/xxx/.var/app/com.valvesoftware.Steam/.local/share/Steam/steamapps/common/BeamNG.drive/BinLinux/BeamNG.drive.x64
Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-flatpak-com.valvesoftware.Steam-773895401.scope
Unit: user@1000.service
User Unit: app-flatpak-com.valvesoftware.Steam-773895401.scope
Slice: user-1000.slice
Owner UID: 1000 (xxx)
Boot ID: d6d23a94f7a5428ea0a56cadeec83aea
Machine ID: b713cb6550634473a2a0fc6943df9e19
Hostname: c02
Storage: /var/lib/systemd/coredump/core.BeamNG\x2edrive\x2ex6.1000.d6d23a94f7a5428ea0a56cadeec83aea.7705.1792504798000000.zst (present)
Size on Disk: 69.5M
Message: Process 7705 (BeamNG.drive.x6) of user 1000 dumped core.

Stack trace of thread 1259:
#0 0x00007bfcb72c12ed n/a (libcef.so + 0x8ac12ed)
#1 0x00007bfcb72c40fc n/a (libcef.so + 0x8ac40fc)
#2 0x00007bfcb6ee6915 n/a (libcef.so + 0x86e6915)
#3 0x00007bfcb6f040a3 n/a (libcef.so + 0x87040a3)
#4 0x00007bfcb6e9af69 n/a (libcef.so + 0x869af69)
#5 0x00007bfcb6f04839 n/a (libcef.so + 0x8704839)
#6 0x00007bfcb6ec9327 n/a (libcef.so + 0x86c9327)
#7 0x00007bfcb6f25c38 n/a (libcef.so + 0x8725c38)
#8 0x00007bfcb6f25ded n/a (libcef.so + 0x8725ded)
#9 0x00007bfcb6f3c0c9 n/a (libcef.so + 0x873c0c9)
#10 0x00007bfcac49be61 n/a (/run/parent/usr/lib/x86_64-linux-gnu/libc.so.6 + 0x9be61)
#11 0x00007bfcac523e84 n/a (/run/parent/usr/lib/x86_64-linux-gnu/libc.so.6 + 0x123e84)
ELF object binary architecture: AMD x86-64
----------
...
Signal: 11 (SEGV)
...
Stack trace of thread 1420:
#0 0x00007732ba8efd44 n/a (libcef.so + 0x86efd44)
#1 0x00007732ba8e7ae5 n/a (libcef.so + 0x86e7ae5)
#2 0x00007732ba94db9f n/a (libcef.so + 0x874db9f)
#3 0x00007732ba8e6915 n/a (libcef.so + 0x86e6915)
#4 0x00007732ba9040a3 n/a (libcef.so + 0x87040a3)
#5 0x00007732ba9621b5 n/a (libcef.so + 0x87621b5)
#6 0x00007732ba904839 n/a (libcef.so + 0x8704839)
#7 0x00007732ba8c9327 n/a (libcef.so + 0x86c9327)
#8 0x00007732ba925c38 n/a (libcef.so + 0x8725c38)
#9 0x00007732ba91311d n/a (libcef.so + 0x871311d)
#10 0x00007732ba925ded n/a (libcef.so + 0x8725ded)
#11 0x00007732ba93c0c9 n/a (libcef.so + 0x873c0c9)
#12 0x00007732afe9be61 n/a (/run/parent/usr/lib/x86_64-linux-gnu/libc.so.6 + 0x9be61)
#13 0x00007732aff23e84 n/a (/run/parent/usr/lib/x86_64-linux-gnu/libc.so.6 + 0x123e84)
ELF object binary architecture: AMD x86-64
----------
...
Signal: 11 (SEGV)
...
Stack trace of thread 1584:
#0 0x000078093b924614 n/a (libcef.so + 0x8724614)
#1 0x000078093c23b2f7 n/a (libcef.so + 0x903b2f7)
#2 0x000078093b8e6915 n/a (libcef.so + 0x86e6915)
#3 0x000078093b9040a3 n/a (libcef.so + 0x87040a3)
#4 0x000078093b9621b5 n/a (libcef.so + 0x87621b5)
#5 0x000078093b904839 n/a (libcef.so + 0x8704839)
#6 0x000078093b8c9327 n/a (libcef.so + 0x86c9327)
#7 0x000078093b925c38 n/a (libcef.so + 0x8725c38)
#8 0x0000780938ed2367 n/a (libcef.so + 0x5cd2367)
#9 0x000078093b925ded n/a (libcef.so + 0x8725ded)
#10 0x000078093b93c0c9 n/a (libcef.so + 0x873c0c9)
#11 0x0000780930e9be61 n/a (/run/parent/usr/lib/x86_64-linux-gnu/libc.so.6 + 0x9be61)
#12 0x0000780930f23e84 n/a (/run/parent/usr/lib/x86_64-linux-gnu/libc.so.6 + 0x123e84)
ELF object binary architecture: AMD x86-64
----------
...
Signal: 11 (SEGV)
...
Stack trace of thread 1738:
#0 0x00007af9a1324614 n/a (libcef.so + 0x8724614)
#1 0x00007af9a1c3b2f7 n/a (libcef.so + 0x903b2f7)
#2 0x00007af9a12e6915 n/a (libcef.so + 0x86e6915)
#3 0x00007af9a13040a3 n/a (libcef.so + 0x87040a3)
#4 0x00007af9a13621b5 n/a (libcef.so + 0x87621b5)
#5 0x00007af9a1304839 n/a (libcef.so + 0x8704839)
#6 0x00007af9a12c9327 n/a (libcef.so + 0x86c9327)
#7 0x00007af9a1325c38 n/a (libcef.so + 0x8725c38)
#8 0x00007af99e8d2367 n/a (libcef.so + 0x5cd2367)
#9 0x00007af9a1325ded n/a (libcef.so + 0x8725ded)
#10 0x00007af9a133c0c9 n/a (libcef.so + 0x873c0c9)
#11 0x00007af99689be61 n/a (/run/parent/usr/lib/x86_64-linux-gnu/libc.so.6 + 0x9be61)
#12 0x00007af996923e84 n/a (/run/parent/usr/lib/x86_64-linux-gnu/libc.so.6 + 0x123e84)
ELF object binary architecture: AMD x86-64

 

As MIPS mentioned above, you can get access to other upscalers (Xess, FSR4). Mainly curious for VR. 2D performance is otherwise perfectly acceptable with native, running outside steam. And besides, just probing at all the options.

amdgpu here. Could also be mesa's fault but haven't bisected that yet.

 

Hi. Is there any plans to update the Steam store page to reflect that BeamNG.Drive supports Linux? As of current, it says it only supports Windows.