The unity_beta branch launches fine on my system, albeit with wonky haptics, offsets, and bindings (which probably aren't Linux-specific issues):

• AMD Radeon RX 580
• Mesa 23.1.0-devel (git-a7c051b5ac)
• kernel 6.1.25-1-MANJARO
• Proton experimental

In logs there is mentions of missing extension like XR_KHR_D3D12_enable

That warning is superfluous, as Beat Saber will default to D3D11 unless the API is explicitly forced. Edit: It seems the unity_alpha branch defaulted to D3D12, but they switched back to D3D11 for unity_beta. For me, the game still loads with -force-d3d12, but without VR support due to the aforementioned missing extension.

The stable branch also seems to be broken to add to this, it launches but not in VR or without detecting the headset and controllers. The beta just crashes like in the initial report.

• AMD Radeon RX 6700 XT
• Mesa 23.2.0-devel (git-0d9ceeee3f)
• kernel 6.3.1-1-zen
• Proton experimental(bleeding edge)

Replying to https://github.com/ValveSoftware/Proton/issues/6638#issuecomment-1542829271

stable works for me
mesa 23.0.3
kernel 6.2.11-300.fc38.x86_64
proton 8.0-2

Replying to https://github.com/ValveSoftware/Proton/issues/6638#issuecomment-1542829271

Same here, launches but doesn't output to the index hmd. Could be because of the recent OpenXR update?

RTX 3090
kernet 6.2.11
GEproton8.2 (tried experimental too)

Using the SteamVR beta causes the NVIDIA driver to hang temporarily and throw these error messages:

May 11 18:30:52 neptune kernel: NVRM: Xid (PCI:0000:06:00): 32, pid=52359, name=Beat Saber.exe, Channel ID 000000de intr0 00040000 May 11 18:30:52 neptune kernel: NVRM: Xid (PCI:0000:06:00): 32, pid=52359, name=Beat Saber.exe, Channel ID 000000de intr0 00040000 May 11 18:30:54 neptune kernel: nvidia-modeset: ERROR: GPU:0: Idling display engine timed out: 0x0000c67e:6:0:1060 May 11 18:30:56 neptune kernel: nvidia-modeset: ERROR: GPU:0: Idling display engine timed out: 0x0000c67e:6:0:1060 May 11 18:30:58 neptune kernel: nvidia-modeset: ERROR: GPU:0: Idling display engine timed out: 0x0000c67e:6:0:1060

In addition, SteamVR no longer outputs any game after this error occurs. Game is also stuck on a permanent black screen and never completely launches. This may be a Wayland-exclusive problem though.

RTX 3080
Mesa 23.0.3-1
Kernal 6.3.1-arch1-1
Proton Experimental

@Parapass

This may be a Wayland-exclusive problem though.

nope, i'm on xserver, also doesn't launch since the last engine update

as a temporary workaround, go to the game settings, beta versions, select legacy build, it would work.
no idea how long the old build would stay there though

I think this has something to do with OpenXR, since the same error happens on BONELAB.

I'm having the same issue.

Graphics System: Xorg
GPU: RTX 3090
GPU driver: nvidia proprietary driver 535.113.1.0
Kernal 6.5.6-zen2-1-zen
Proton Experimental (8.0-104), older proton versions cause steam vr to crash on game start or the game gets stuck on a black frame.

I am consistently crashing on SteamVR beta 2.1.9, Proton experimental, and Beat Saber version legacy1.29.1.
Downgrading to proton 8.0-4 fixes the issue.
Just staying in the main menu doesn't crash, but navigating the menu or playing crashed within ~3 minutes.

I also have various mods installed.

This log entry gets spammed on the problematic proton version:

[CRITICAL @ 12:34:57 | UnityEngine] NullReferenceException: Object reference not set to an instance of an object
[CRITICAL @ 12:34:57 | UnityEngine] Valve.VR.CVRSystem.PollNextEvent (Valve.VR.VREvent_t& pEvent, System.UInt32 uncbVREvent) (at <5868de6629974f01886115908ff93cc2>:0)
[CRITICAL @ 12:34:57 | UnityEngine] OpenVRHelper.Update () (at <e01c36b4cfa8495b82e4c53668601dc2>:0)

After the crash, beatsaber crashes immediately after restarting, restarting steamvr just gets it back to crashing within 3 minutes.

Computer Information:
Manufacturer: ASUSTeK COMPUTER INC.
Model: ROG STRIX X570-E GAMING
Form Factor: Desktop
No Touch Input Detected
Processor Information:
CPU Vendor: AuthenticAMD
CPU Brand: AMD Ryzen 9 3900X 12-Core Processor
CPU Family: 0x17
CPU Model: 0x71
CPU Stepping: 0x0
CPU Type: 0x0
Speed: 4672 MHz
24 logical processors
12 physical processors
Hyper-threading: Supported
FCMOV: Supported
SSE2: Supported
SSE3: Supported
SSSE3: Supported
SSE4a: Supported
SSE41: Supported
SSE42: Supported
AES: Supported
AVX: Supported
AVX2: Supported
AVX512F: Unsupported
AVX512PF: Unsupported
AVX512ER: Unsupported
AVX512CD: Unsupported
AVX512VNNI: Unsupported
SHA: Supported
CMPXCHG16B: Supported
LAHF/SAHF: Supported
PrefetchW: Unsupported
Operating System Version:
"Manjaro Linux" (64 bit)
Kernel Name: Linux
Kernel Version: 6.5.13-1-MANJARO
X Server Vendor: The X.Org Foundation
X Server Release: 12101009
X Window Manager: KWin
Steam Runtime Version: steam-runtime_0.20231024.64411
Video Card:
Driver: NVIDIA Corporation NVIDIA GeForce RTX 2080 SUPER/PCIe/SSE2
Driver Version: 4.6.0 NVIDIA 545.29.06
OpenGL Version: 4.6
Desktop Color Depth: 24 bits per pixel
Monitor Refresh Rate: 74 Hz
VendorID: 0x10de
DeviceID: 0x1e81
Revision Not Detected
Number of Monitors: 1
Number of Logical Video Cards: 1
Primary Display Resolution: 2560 x 1440
Desktop Resolution: 2560 x 1440
Primary Display Size: 28.54" x 16.85" (33.11" diag), 72.5cm x 42.8cm (84.1cm diag)
Primary Bus: PCI Express 16x
Primary VRAM: 8192 MB
Supported MSAA Modes: 2x 4x 8x 16x
Sound card:
Audio device: Nvidia GPU 92 HDMI/DP
Memory:
RAM: 32003 Mb
VR Hardware:
Headset: Valve Index (lighthouse)
Tracker: Tundra Labs Tundra Tracker (lighthouse)
Base station or sensor: HTC HTC V2-XD/XE (lighthouse)
Base station or sensor: HTC HTC V2-XD/XE (lighthouse)
Controller: Valve Knuckles Right (lighthouse)
Controller: Valve Knuckles Left (lighthouse)
Miscellaneous:
UI Language: English
LANG: en_US.UTF-8
Total Hard Disk Space Available: 701170 MB
Largest Free Hard Disk Block: 145771 MB
Storage:
Number of SSDs: 1
SSD sizes: 1000G
Number of HDDs: 0
Number of removable drives: 0

@kisak-valve I just changed the proton version to proton experimental, played for a few minutes, crashed, and this is the file:
steam-620980.log.gz

So very reproducible for me.

@RedlineTriad Does this issue happen with the mods uninstalled that you mentioned?

@RedlineTriad For some reason I was seeing this crash while testing yesterday, and then it disappeared and now I can no longer recreate it on Experimental. Could you try experimental again, and if you are still seeing the crash could you capture a log of the crash by adding PROTON_LOG=+steam,+steamclient,+vrclient,+openxr %command% to the game launch options?

@RedlineTriad For some reason I was seeing this crash while testing yesterday, and then it disappeared and now I can no longer recreate it on Experimental. Could you try experimental again, and if you are still seeing the crash could you capture a log of the crash by adding PROTON_LOG=+steam,+steamclient,+vrclient,+openxr %command% to the game launch options?

Somebody check if heisenberg is still in his grave, I smell a heisenbug.

1. Play with experimental, crash (~2m).
2. Add debug options, play for 20 min, no crash.
3. Restart without debug options, crash (~1m).
4. Add debug options, play for 15 min, no crash.

So I think the reason you aren't able to reproduce it anymore might be because you are playing with debug options.

@RedlineTriad You are partially correct - it did stop appearing when I enabled logging, but then after I turned logging off again it was still very hard to reproduce ...which is typical of a race condition of course 😭 Perhaps something was running in the background and changing my computer timing just enough.

It is unfortunate that you couldn't capture a log though. Since it seems to be happening more consistently for you than for us (now I've had someone else try on a third machine with similar results to me, although it took them even longer than me to get a crash) I was hopeful that even with logging you would be able to capture something. I will keep looking into this ... in the meantime - could you play with that logging enabled and maybe you will get lucky? Worst case, it just avoids the crashing and so the game will at least be playable :D

@alasky17

It is unfortunate that you couldn't capture a log though. Since it seems to be happening more consistently for you than for us

PROTON_LOG=1 seems to work while crashing (see above).

Can you link me some documentation of what makes this different?
PROTON_LOG=+steam,+steamclient,+vrclient,+openxr %command%
If so I could check how much I can enable and still get the crash.
Also, which of this might be the most important to collect.

@RedlineTriad Thank you for taking the time to dig into this. We've been making massive changes to lsteamclient and vr, so it seems relatively likely that this is a "real regression" rather than just a bug that was there all along (either in our code or game code) that we are just hitting more frequently now. PROTON_LOG=1 includes our general "default" logging channels ... I don't think there is any documentation on this, but if you look at the top of your log file created with the variable, you can see the "WINEDEBUG" line which will list all of the channels that are being set.

The easiest way to reduce the logging load is to use user_settings.py instead of PROTON_LOG. To do this:

1. Go to your Proton folder, for experimental would be ~/.steam/steam/steamapps/common/Proton - Experimental
2. cp user_settings.sample.py user_settings.py (Proton looks for the user_settings.py filename to exist in the Proton folder)
3. Edit this file to mess with the logging options.

• You will want to remove the # from the beginning of the WINEDEBUG. WINE_DEBUG will override PROTON_LOG.
• You could start with removing all of the defaults from WINE_DEBUG and only using the extra logging (+steam,+steamclient,+vrclient,+openxr) ... within those, I would say +steamclient and +vrclient are the two most likely candidates for something interesting.
• As a bonus, you can comment out (#) all the other logging lines that are not for Wine. (DXVK, 2 VKD3D lines, wine mono, and GST_DEBUG).

In order to further attempt to confirm if this regression is coming from the suspected set of changes, I have a couple of builds that I think are "last good" and "first bad". If you have the time, it would be great if you could confirm this for me since you are producing the failure so much more consistently than I was during my testing. Could you test the two builds in this folder - https://www.codeweavers.com/xfer/alasky/beat-saber-crash/ (lock code is "saber") and see if either or both cause the crash? To test the builds easily:

1. Create ~/.steam/steam/compatibilitytools.d if you don't have a folder there already
2. Drop both build tarballs in that folder
3. Untar them
4. Reboot Steam
5. The builds will now show up in the dropdown menu of Proton builds to choose from for a game. You can get rid of them by removing the untarred build folders and rebooting Steam again.

@alasky17 Sorry for the long wait, life got a bit busy.
Decided to bisect your two builds first:

Test Setup: A

Command: None
Version: experimental-bleeding-edge-8.0-63848-20231116-pb35cd1-w61198d-dd998de-v7b2ea8

Test Setup: B

Command: None
Version: experimental-bleeding-edge-8.0-63895-20231116-p5d3865-w61198d-dd998de-v5deb87

Results:

Will try the different logging stuff when I have time, if you want me to bisect more version feel free to link them.
Though if possible in order so I can start with failing ones (it's faster to test those) or binary search.

@RedlineTriad Thank you! This confirms that the commit series I suspected is indeed the likely culprit here. Unfortunately, it is a cluster of changes that is particularly nasty to bisect within. Maybe you will get lucky and manage to catch a log of the crash -- I think that is likely to be a lot more productive than an attempted bisect where many of the commits won't build or won't launch the game (which is what happened when I tried to bisect some earlier portion of this work :/) .

@alasky17 Here the proton logs with as many of the 4 options as I could get using Proton Experimental:
steam-620980.log.gz
This was made using the following options:

user_settings = {
    "PROTON_LOG": "1",
    "WINEDEBUG": "+steam,+steamclient,+openxr",
}

Adding +vrclient made it not crash anymore, so I had to remove it.

Also, since it runs into the crash handler at the end you might need to ignore that part of the logs, decided to let it crash completely without doing anything myself to taint the data as little as possible.

Hope this helps, and I am available if any further testing is needed.

Hi @RedlineTriad, I added a change to the "bleeding-edge" beta branch of Proton Experimental, trying to fix the crash (though we weren't able to reproduce it). Would you mind testing if it helps?

Hi @RedlineTriad, I added a change to the "bleeding-edge" beta branch of Proton Experimental, trying to fix the crash (though we weren't able to reproduce it). Would you mind testing if it helps?

Testing 2 times with bleeding-edge branch and proton experimental and no crash, once with "stable" proton experimental and crashed.

Thanks for fixing this!

Could you link the fix? Super curious what caused such a weird failure mode.

Fix is https://github.com/ValveSoftware/Proton/commit/cdd2db6da2e16120d4bdefce37d3d7b5da1026aa, the issue is probably that we were not respecting the provided event struct length anymore and were copying the entire even structure, even if the client had allocated a smaller one. Not completely sure why it didn't cause consistent crashes.

Is there any update to this? I want to try the fix and see if it solves the issue on my system. Running NixOS 24.05 with Nvidia on KDE Plasma 6.0.2+Wayland

@NovaViper The fix mentioned above shipped with Proton 9.0. However, in recent testing the game had issues with the legacy branch after an update to the legacy branch. I'm not sure if you would run into those issues, so you are welcome to try the game yourself and see. I would recommend trying the legacy branch of the game.

@alasky17 I actually can run the legacy branch of the game (1.29.1, the pre-unity version). The version I can't run is the all of the 1.30 builds and beyond; since those feature the unity engine change. I tried several different Proton versions and none of them seem to fix the instant crashing issue I'm experiencing. The only version that works is the legacy 1.29.1 version of the game.

Alright, with the new Proton Experimental, the legacy branch is no longer needed :)

However, with my Valve Index the right eye seems to be rendered too far left, because of that Beat Saber is unplayable. This only happens in Beat Saber.

@bblacher Hello! Can you get an output of your system information and upload it please? You can find it in Help -> System Information in Steam. You can copy paste the output, save it as a file and upload it here.

Additionally, can you grab a log of the issue? You can add a launch option to the game to create a log. Open up the Properties of the game, and under Launch options add PROTON_LOG=+steam,+vrclient,+openxr,+vulkan,+win,+x11drv %command% please. It will create a log file in your home directory. Please upload that log file here.

Are you opening the game via Steam, or within a SteamVR environment?

Sure!

Here is my system information.

Here is a log of the issue with the requested options. - this is using the current Beat Saber version (v1.36.2)

I am opening the game from within SteamVR home as I've found launching from Steam Desktop unreliable in the past. (Not only with Beat Saber, with many VR games, but that's another issue :))

Thank you so much for your work on Proton, it really makes gaming on Linux a delight :)
@AJuujarvi

@bblacher I should have asked before asking for a log, is the eye funkiness specifically with Beat Saber current, or with the legacy1.29.1_unity_ver2019.4.28f1 Beta Branch? Or both? And which one is the log from?

The issue only appears on Beat Saber current (v1.36.2 as of writing), when downgrading to legacy1.29.1_unity_ver2019.4.28f1, the issue disappears. The log appended to my previous comment is from Beat Saber current, I've edited my comment to reflect that.

Here is a log from the legacy branch, I don't know if this will be helpful in any way but it won't hurt to have it posted as well. :)

Also, something I noticed when launching the current version of the game is that the issue only appears when the loading of the main menu is complete. The first "splash screen" that says "Beat Saber" "Oculus Games" and something else is rendered correctly.

I got the same (or similar) issue: left eye seems to be working fine but right eye looks kind of "warped" and misplaced.
I'm running the "regular" Beat Saber version 1.36.2 with Proton Experimental.
Logfile using the options:
steam-620980.log

My issue was fixed today with this version update of Proton Experimental:
https://github.com/ValveSoftware/Proton/wiki/Changelog/_compare/ff410f560fa87dab971889b644418b7285892dc7...496e06506f90187cc788c7f80dc1dd3bde82fe9f

I got the same (or similar) issue: left eye seems to be working fine but right eye looks kind of "warped" and misplaced. I'm running the "regular" Beat Saber version 1.36.2 with Proton Experimental. Logfile using the options: steam-620980.log

I'm using a very similar setup with more or less the same issue as you. I did some more testing and it seems that the right eye can handle positional displacement just fine, but rotational movement is wildly skewed, and really hurts my eye and I rotate around. This is with my left eye closed.

For me the issue reappeared with Beatsaber version 1.37.1 (I'm using Proton Experimental)
on Beta version "1.34.2_legacy" it still works fine

The right eye warp issue seems to come and go away at random. When it happens it can persist for hours even with restarts of the desktop or the computer or changing the settings, and sometimes changing the render resolution per eye and restarting SteamVR can make it go away (as happened in today's debugging of the issue on my end). It does happen with Beat Saber versions that used to retroactively work fine.

I can't pin point the exact version of SteamVR when this started breaking, however I can tell this only affects Beat Saber in particular. Other games such as VRChat seem to render fine.

Someone explained to me the theory that this may actually be some correction built into SteamVR that is supposed to know when a game is projecting VR in a specific way, and sometimes it may fail to trigger now? Not sure how much weight there is to that.

The issue appears to still be present on the latest SteamVR version, on my desktop with a GeForce RTX 4090 (running Arch Linux).

1080 Ti + Ryzen 1700X + Linux Mint 22.1 (kernel: 6.11.0-25-generic) with Cinnamon as DE.

Successfully runs on legacy1.29.1 (played a bunch of songs, no crash), fails on all other (latest, 1.34.2, 1.37.1), non-recoverable and forces restart of Steam VR.

Also on closing of the game throws this error ^

Edit: will test on Plasma some time this week and report back.

Just tested on Plasma, same issue, checked dmesg, seeing the same as this poster: https://github.com/ValveSoftware/Proton/issues/6638#issuecomment-1544782400

Game freezes without crash on Wayland.

For context, I believe this to be an issue with the SteamVR OpenXR runtime itself, rather than Proton.

Using WiVRn for HMD connection (which uses libmonado under the hood) I'm able to play the game just fine - even with mods - no crashes, no issues at all. I'm using GE-Proton9-27 as the compatibility layer.

Have the same using SteamVR and Proton experimental. Switched to WiVRn using GE-Proton9-27 and the game runs!

Hi folks - thank you for reporting this! It is indeed a SteamVR regression, and it should be fixed with SteamVR Beta: https://github.com/ValveSoftware/SteamVR-for-Linux/issues/786#issuecomment-2887517161

Confirmed, just successfully launched with beta.

currently having a new issue in regards to running beat saber 1.41+ with BSIPA 4.3.7

Compatibility Report

• Name of the game with compatibility issues: Beat Saber 1.41+ w/ BSIPA mod loader 4.3.7
• Steam AppID of the game: 620980

System Information

• GPU: 7900XTX
• Video driver version: 25.3.5-arch1.2
• Kernel version: Linux 6.19.2-2-cachyos
• Gist
• Proton version: Proton Experimental

I confirm:

• [x] that I have checked whether there are updates for my system available.

Symptoms

playing versions of Beat Saber that use the 4.3.7 version of the BSIPA modloader will inconsistently cause access violation error spam & beat saber level breakage; or crashes. The consistency of this happening increases the more plugins are installed. When Beat Saber causes access violation errors, the lightshow breaks and there is no music. You are unable to return to the menu and you'll have to force quit Beat Saber. Leaving Beat Saber on for too long will cause the OS to run out of RAM. This is not present on Windows.

Reproduction

1. install BSIPA version 4.3.7 onto a version of Beat Saber after 1.41
2. install core beat saber plugins & libs such as SongCore, SiraUtil & BeatSaberMarkupLanguage. install more mods to increase the frequency at which the bug occurs
3. add WINEDLLOVERRIDES="winhttp=native,builtin" %command% to the launch arguments, and optionally add "fpfc" command if you're planning to test Beat Saber in desktop, and "-vrmode none" to stop Beat Saber from clogging up logs with searching for an XR Runtime.
4. load a map, and then continually restart the map (P to pause, then R to restart if you're using FPFC) until either the game crashes or Beat Saber causes the access violation errors.

Proton log + the mod loader's log
proton_and_bsipa_log.zip