1. A Simple Goal That Should Have Taken Five Minutes
The goal was simple: Run the Shadow of the Tomb Raider benchmark automatically from the command line using Proton. That was it.
No launcher. No clicking. No menus. No human interaction. Just executed, wrote down the measurement, and exited.What should have been a simple benchmark turned into a deep investigation. The native Linux version obeyed every parameter, but Proton didn’t. Logs confirmed everything was correct—yet the game ignored the command. This is the story of chasing a single parameter that refused to work.
This wasn’t new territory. I had already done this before with the Cyberpunk 2077 game, using the Steam version through Proton. Automation is predictable when you understand the environment. Executables take parameters. Parameters change behavior. That’s the contract.
Shadow of the Tomb Raider already had a built-in benchmark mode. It was one of the better ones, actually — deterministic, consistent, and designed specifically for performance testing.
Even better, the native Linux version supported it perfectly.
Running this command:
./ShadowOfTheTombRaider.exe \
-nolauncher \
-benchmark \
-silent \
--non-interactive
would immediately launch the benchmark sequence. No launcher. No menu. No questions. It would run through its predefined scenes, collect data, and exit automatically. Exactly what a benchmark should do.
But there was a problem. The native Linux version didn’t support everything. It lacked DirectX 12. It lacked DLSS.
And those were exactly the features I needed to test.
The Windows version had them.
And Proton made the Windows version fully usable on Linux. So the objective became clear: Run the Windows version through Proton, automatically, in benchmark mode.
It should have been straightforward.
2. Building the Command
Running Windows games through Proton manually requires recreating the environment Steam normally provides.
Steam sets several environment variables automatically when launching a game. Without them, Proton still works, but behavior isn’t always identical.
So the command needed to include them explicitly.
This was the first attempt:
SteamAppId=750920 \
SteamGameId=750920 \
STEAM_COMPAT_CLIENT_INSTALL_PATH=/home/pavel/.local/share/Steam \
STEAM_COMPAT_DATA_PATH=/mnt/Data/Games/Steam/steamapps/compatdata/750920 \
PROTON_LOG=1 \
/home/pavel/.local/share/Steam/compatibilitytools.d/GE-Proton9-27/proton run \
"/mnt/Data/Games/Steam/steamapps/common/Shadow of the Tomb Raider/SOTTR.exe" \
-benchmark -nolauncher
Everything was correct. Paths were correct, please pay attention that I have a custom Steam Library for the games on a separate disk /mnt/Data/Games/Steam. AppID was correct, which is 750920. CompatData path was correct. Proton version was correct, for some reason Proton9 worked better than Proton10 with fullscreen mode.
There was no reason for this to fail. The command executed immediately. Proton initialized. The game window appeared. This was expected. That's normal.
Then the logo animation played, and then the screen faded. And then…
The main menu appeared! Not the benchmark! Just the menu of the game
3. The First Assumption
The most natural assumption was that the parameter was wrong, or maybe it required additional flags, or many games use combinations of parameters.
So I added more:
-benchmark
-autoclose
-nolauncher
The updated command:
SteamAppId=750920 \
SteamGameId=750920 \
STEAM_COMPAT_CLIENT_INSTALL_PATH=/home/pavel/.local/share/Steam \
STEAM_COMPAT_DATA_PATH=/mnt/Data/Games/Steam/steamapps/compatdata/750920 \
/home/pavel/.local/share/Steam/compatibilitytools.d/GE-Proton9-27/proton run \
"./SOTTR.exe" \
-benchmark -autoclose -nolauncher
Same result: the game starts, and the Main Menu appears. No benchmark.
4. Confirming the Parameters Actually Reach the Executable
At this point, it became important to verify whether Proton was even passing the parameters correctly.
Proton logging was enabled:
PROTON_LOG=1
After running the command, Proton created a log file:
~/steam-750920.log
Inside the log, there was a critical line:
Command: ['./SOTTR.exe', '-benchmark', '-autoclose', '-nolauncher']
This confirmed something extremely important. The executable was receiving the parameters. Proton was not stripping them, Proton was not modifying them, Proton was not the problem.
The executable itself was choosing not to act on them.
5. Testing Through Steam Itself
Maybe the issue was launching outside Steam, because Steam provides an additional layer of context, and maybe I'm missing something.
So the next attempt used Steam directly:
steam -applaunch 750920 -benchmark
It took a while to start the game with the Steam command, but in the end It launched normally. The game started, and then the Main Menu appeared again!
The exact same behavior, but this eliminated another possibility. The problem wasn’t manual Proton execution. Even Steam itself couldn’t automatically trigger the benchmark.
6. Configuration File Experiment
Some games rely on configuration files or specific Registry parameters rather than Command Line parameters.
Inside Proton’s prefix, the configuration directory exists here:
/mnt/Data/Games/Steam/steamapps/compatdata/750920/pfx/drive_c/users/steamuser/Documents/Shadow of the Tomb Raider/
A Graphics.ini file was created manually:
BenchmarkMode=1
AutoCloseBenchmark=1
The game was launched again, and nothing changed. The file was ignored.
7. Comparing Native Linux vs Proton Behavior
This was the most important turning point. The native Linux version worked perfectly every time. Using the exact same parameter:
-benchmark
The benchmark started immediately, no menu, no interaction.
The Proton version did not. This meant something subtle but critical was different. Not broken. Just different.
8. Verifying Proton’s Execution Environment
Another command was used to confirm everything was correct:
cd "/mnt/Data/Games/Steam/steamapps/common/Shadow of the Tomb Raider"
SteamAppId=750920 \
SteamGameId=750920 \
STEAM_COMPAT_CLIENT_INSTALL_PATH="/home/pavel/.local/share/Steam" \
STEAM_COMPAT_DATA_PATH="/mnt/Data/Games/Steam/steamapps/compatdata/750920" \
PROTON_LOG=1 \
"/home/pavel/.local/share/Steam/compatibilitytools.d/GE-Proton9-27/proton" \
run ./SOTTR.exe \
-benchmark \
-benchmarkini="C:\\users\\steamuser\\AppData\\Local\\Temp\\sottr_benchmark.ini" \
-autoclose \
-nolauncher
Log output confirmed again:
Command: ['./SOTTR.exe',
'-benchmark',
'-benchmarkini=C:\\users\\steamuser\\AppData\\Local\\Temp\\sottr_benchmark.ini',
'-autoclose',
'-nolauncher']
The parameters were arriving correctly. Still, the benchmark did not start.
9. The Critical Realization
This was the moment everything became clear.
- The problem wasn’t Proton.
- The problem wasn’t Steam.
- The problem wasn’t the command.
The problem was the executable’s internal logic. The Windows version of the game behaved differently from the Linux-native version. Not because Proton was failing, but because the executable itself had different behavior paths. The Linux version trusted the parameter, and the Windows version required additional internal state. Possibly Steam API confirmation. Possibly registry state. Possibly launch context validation.
Whatever the exact condition was, it wasn’t satisfied. So the executable ignored the benchmark parameter.
10. The Working Command (Even Though It Doesn't Trigger Benchmark)
The final correct Proton command remains:
SteamAppId=750920 \
SteamGameId=750920 \
STEAM_COMPAT_CLIENT_INSTALL_PATH="/home/pavel/.local/share/Steam" \
STEAM_COMPAT_DATA_PATH="/mnt/Data/Games/Steam/steamapps/compatdata/750920" \
PROTON_LOG=1 \
"/home/pavel/.local/share/Steam/compatibilitytools.d/GE-Proton9-27/proton" \
run "./SOTTR.exe" \
-benchmark -autoclose -nolauncher
It launches correctly. It passes parameters correctly. It behaves correctly. It simply does not auto-start benchmark mode.