[Linux] TF2 freeze while starting game in fullscreen mode

[StufkaTeam]

When launching TF2 in fullscreen mode game freeze, starting it by -window parameter helps. After turning on fullscreen mode in settings game freeze while minimizing window

Operating system: Linux Mint 21.3 Graphics Card: RTX3070 Processor: AMD Ryzen 5 5600x Motherboard: Aorus b450 elite v2

[Toquita3D]

Can confirm this. It happens to me as well.

Steam: Flatpak version OS: Rocky 9.3 DE: KDE 5.27.6 Resolution: 1920x1080 165 Hz Processor: Ryzen 7 5800X RAM: 128 GB Corsair Vengeance Pro RGB GPU: NVIDIA RTX 3060 12 GB LHR.

Starting the game with -window and then setting it to full screen works. I tried the fixes in #5043 but none worked.

EDIT: starting the game with "-vulkan" seems to have fixed the issue for me. @kisak-valve @StufkaTeam EDIT2: nope, that didn't fix it.

[nickpelone]

Personal +1.

I was not able to launch TF2/x64 native on Linux until I passed the -windowed option to stop it from crashing / nuking my X server.

(I hope to go wayland one day but not relevant to this issue message)

For reference, what my launch options became:

gamemoderun mangohud %command% -novid -windowed

System Information

```log Computer Information: Manufacturer: HP Model: 8876 Form Factor: Desktop No Touch Input Detected Processor Information: CPU Vendor: AuthenticAMD CPU Brand: AMD Ryzen 5 5600X 6-Core Processor CPU Family: 0x19 CPU Model: 0x21 CPU Stepping: 0x0 CPU Type: 0x0 Speed: 4650 MHz 12 logical processors 6 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: "Arch Linux" (64 bit) Kernel Name: Linux Kernel Version: 6.8.8-arch1-1 X Server Vendor: The X.Org Foundation X Server Release: 12101013 X Window Manager: Mutter (Muffin) Steam Runtime Version: steam-runtime_0.20240304.79797 Video Card: Driver: NVIDIA Corporation NVIDIA GeForce RTX 3070 Ti/PCIe/SSE2 Driver Version: 4.6.0 NVIDIA 550.76 OpenGL Version: 4.6 Desktop Color Depth: 24 bits per pixel Monitor Refresh Rate: 170 Hz VendorID: 0x10de DeviceID: 0x2482 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: 0.04" x 0.04" (0.04" diag), 0.1cm x 0.1cm (0.1cm diag) Primary Bus: PCI Express 16x Primary VRAM: 8192 MB Supported MSAA Modes: 2x 4x 8x 16x Sound card: Audio device: Nvidia GPU 9e HDMI/DP Memory: RAM: 23939 Mb VR Hardware: VR Headset: None detected Miscellaneous: UI Language: English LANG: en_US.utf8 Total Hard Disk Space Available: 544079 MB Largest Free Hard Disk Block: 40503 MB Storage: Number of SSDs: 3 SSD sizes: 2000G,1000G,256G Number of HDDs: 0 Number of removable drives: 0 ```

I also attached my Steam Runtime System Information. Perhaps verbose, but I wanted to try and provide as much information as possible. Thank you for maintaining this and your time. steam debug.json

[UFeindschiff]

Can confirm, same thing started happening for me. It only happens with the Vulkan version, the OpenGL version remains working fine.

To the others having the same issue: Are you all running multi-monitor setups as well? Because to me it started happening after I replaced one of my monitors. As it seems to be a multi-monitor issue. The game starts starting up normal on my primary , but eventually (when it would show the main menu) would hang up while another monitor would show a blank grey image and a single CPU core woud remain at 100% usage forever. Fun thing is that the monitor that turns grey is the monitor X11 by default sees as the primary monitor, but I have a different monitor configured as the primary monitor for the current X11 screen, so it seems like TF2 is getting confused where to render on and hangs up (as TF2 is configured to render on monitor 0).

[Toquita3D]

OK so it works on Debian, with Steam's native package (apt install steam). No need to go Windowed or OGL. Full 64-bit Vulkan client works fine.

It didn't on Rocky 9.4 with Flatpak. So it could be a flatpak package/library problem.

[UFeindschiff]

So it could be a flatpak package/library problem.

Most definetely not. I'm using neither flatpak nor snap and it's broken for me

[Toquita3D]

So it could be a flatpak package/library problem.

Most definetely not. I'm using neither flatpak nor snap and it's broken for me

Can you tell us which nvidia driver you're running? I'm running 550.54.15 on Debian Stable, installed using NVIDIA's CUDA tutorial.

[UFeindschiff]

Can you tell us which nvidia driver you're running?

535.154.05 (which I have been using for a few months). There was no driver change between "the Vulkan version works" and "the Vulkan version is broken".

[chaorace]

I'm also experiencing the same issue when launching the Vulkan version. Just like everyone else, I can bypass the problem by using -windowed. I'm using Mesa AMD drivers, so I think this might be a vendor-neutral issue.

System information

Steam: nixpkgs unstable (non-flatpak) Steam Channel: Stable Kernel: 6.7.11-3-MANJARO Display Server: Wayland via Hyprland (git commit f47c89d495bbd819370875081325bbf04746603e) GPU: AMD Radeon RX 6650 XT @ Mesa 24.0.5 Monitor: 3440x1440@165hz (VRR enabled, single display)

[nickpelone]

I personally noted today this seems to be resolved - I don't know if it was a change in my system, or some kind of quiet update, or what. I'll report back if I find out more.

[HollowVin]

Here to personally confirm I was having the same issue. I have a multi-monitor setup like some commenters mentioned but going back to a single monitor for testing didn't help. In my case, installing Steam through a .deb and not through Flatpak (both installed through the Pop!_Shop since I'm on Pop!_OS) solved the issue. I am now able to play TF2 in fullscreen after the change.

Is it possible that Steam/TF2 in a Flatpak is attempting to access something outside its sandbox when TF2 gets to the main menu, causing some kind of issue which results in this freeze? Might explain why the .deb doesn't run into this issue.

System information

- Steam: Version 1716584667, .deb or Flatpak installed through Pop!_Shop - Steam Channel: Stable - OS: Pop!_OS jammy 22.04 x86_64 - Kernel: Linux 6.8.0-76060800daily20240311-generic - DE: Gnome 42.9 - WM: Mutter (X11) - GPU: AMD Radeon RX 6700 XT - Monitor: MSI1462 2560x1440 @ 144Hz

[Skincanvas]

Thank you for this fix, windowed into fullscreen works for me. So frustrating because this bug didn't give me any logs or feedback, just froze my system. Attaching my system information in case it helps.

system information.txt

Edit; Windowed gets me past title screen but 20 minutes into the game it turns into a slideshow that isn't fixed by retry or switching between windowed/fullscreen. I think it is related, because its the same sort of performance I initially get when I switch from windowed to fullscreen, until alt-tabbing which 'fixes' it. It seems like the Vulkan port isn't worth using yet.

[robotman40]

I encountered this issue on PopOS several days ago and I accidently launched the game in Vulkan fullscreen today. This time, it changed my refresh rate to 24hz and when I quit the game, my refresh rate reverted back to 165hz.

How do I get the application shortcut to launch OpenGL mode instead of Vulkan (I set the game to launch OpenGL when launched through the Steam client).

[Toquita3D]

I encountered this issue on PopOS several days ago and I accidently launched the game in Vulkan fullscreen today. This time, it changed my refresh rate to 24hz and when I quit the game, my refresh rate reverted back to 165hz.

How do I get the application shortcut to launch OpenGL mode instead of Vulkan (I set the game to launch OpenGL when launched through the Steam client).

Try this https://steamcommunity.com/sharedfiles/filedetails/?id=1576097804

If the above doesn't work, try setting the launch options to "-gl" instead, or "-ogl" (without quotes).

[slxdy]

So, I might be totally wrong on this, but OpenGL doesn't seem to have true full screen mode. It still has latency and gets a bit choppy sometimes. You can achieve similar results with Vulkan windowed borderless

[GermanAizek]

@nickpelone,

gamemoderun mangohud %command% -novid -windowed

many thanks!

After launching game menu, I just right-click on top window bar and select 'Fullscreen' on LXQt, game thinks that I am playing in windowed mode, but it is stretched without windows borders.

[TheBoctor]

I am almost sure this is not distro/vendor specific. Trying to start TF2 in fullscreen, single-display, AMDGPU with DXVK (Vulkan; default backend) on GNOME (X11), Plasma 6.1 (X11) or Xfce on Arch freezes my entire X server, and even attempts to change the mode of my monitor. Sometimes, I cannot even change ttys. This is with vanilla/upstream everything, regular kernel, no wrappers, no Flatpak, Mesa all the way down. A configuration which previously worked flawlessly.

Gamescope works in a pinch, but since that's nested, there's quit a bit of latency. As people are saying, ToGL (-gl) still works absolutely fine, albeit with the increased overhead of translation between two higher-level APIs. However, it is concerning that a retail game's default configuration runs the risk of doing this at all. Even if you play on GNOME or Plasma Wayland like I usually do, quitting TF2 occasionally violates the DRM explicit sync protocol, which in turn kills your entire XWayland server. (If you're in a certain Electron-based VoIP client when this happens, your teammates may be very confused.)

Proton/Wine, Steamplay, and DXVK all continue to work perfectly. I have observed zero other games or applications with this behavior.

[slxdy]

Another interesting thing, even with OpenGL, when fractional scaling is enabled, the game literally goes nuts. It messes with all my other monitors, starts with the wrong resolution and somehow locks my monitor to 60hz (I got a 144hz display)?

I know fractional scaling has always been terrible, but just another issue to add to the pile.

[Leniptic]

Still happening to me on Pop_OS! with both KDE and Gnome (X11 on both). Using fullscreen at all nukes my computer and I have to do a system restart by holding the power buttion. I only have one monitor. Using -windowed lets me play the game. This is the only game that does this on my system.

[UFeindschiff]

Using fullscreen at all nukes my computer and I have to do a system restart by holding the power buttion.

A power cycle shouldn't be needed. You can switch to a TTY, kill TF2 from there and your X server should unfreeze.

[thevbw]

Vulkan is used when joining a friend, even when OpenGL is selected in the Steam game properties. On my machine (gtx1070, nvidia 555, X11), Vulkan mode TF2 opens in fullscreen and sets my refresh rate to 60 hertz, which needs to be manually undone and persists in some programs (chromium programs?) until a relog. I have added the launch option -gl to TF2 now.

I want to use OpenGL mode because after playing for a few minutes with Vulkan, the game starts stuttering.

Edit: I am using Debian 12. I observed similar system-wide messups playing CS2 in its early days, which I put down to Vulkan being poorly designed / implemented.

[kitrodian]

Having this happen on Linux Mint 22 with Xorg. Using native .deb package with an RTX 3080 Ti, proprietary drivers. Running windowed works but fullscreen completely freezes my entire display, except for my mouse cursor which I can move but can't interact with anything. I would prefer to be able to use Vulkan because of some minor graphical bugs with OpenGL.

Driver version is 535.183.01-0ubuntu0.24.04.1.

[slxdy]

OpenGL seems to be the only solution rn on Linux Mint. So far the only issues I've had with it is the HUD freaking out and the game will start stuttering like hell when I unfocus from the game sometimes. The last bug is the most annoying, because it only goes away once you restart the game, hoping it won't happen again. It's a weird stutter that makes it feel like I'm playing on 30 fps, even though that's obviously not the case.

[TheBoctor]

Can confirm, after weeks of testing during free time, that Plasma Wayland is possibly the only session where the game behaves correctly, and doesn't freeze, nor crash your entire rootless XWayland server. The latter problem seems like it got worse on GNOME after explicit sync landed, and the experimental Mutter VRR option seems to further exacerbate the problem, i.e., making XWayland crash even more frequently.

Plasma's session has been seemingly unaffected for as long as I can remember, or it at least tolerates some offending quirk of TF2+DXVK. I can only speculate that Plasma or Gamescope were where this was predominantly tested. Since the time of writing, even this is no longer the case, and the game froze my whole compositor after a 50 minute play session.

When I next use my Plasma/Wayland desktop, I will try setting SDL_VIDEODRIVER to wayland, as the default is x11. I have had luck, however, in running TF2 (Vulkan) on Xfce with the -refresh and -freq launch args set to my monitor's scan rate. No odd behavior in 2 play sessions, but will not bump this issue until I conclude anything.

[TheBoctor]

I have been playing on DXVK and X11 (Xfce) for the past week, thanks to the launch options -refresh 170 -freq 170 (You probably already understand this, but for posterity: Set these to match your monitor). No failures to launch, no invalid video modes, no blank screen, and have not had the X server freeze during play, nor have I observed the game freezing/lagging while backgrounded. This is on Arch with the 6.6 LTS kernel and VRR enabled in Xorg.conf.

Has anyone with a different distro, DE/WM, or different hardware tried setting refresh and freq to match your display, yet? I am curious to know if other users can play the game fine by explicitly setting these launch options. #4817 mentioned this, too.

[UFeindschiff]

can confirm. Setting refresh and freq manually makes the game with the Vulkan renderer start up normally in fullscreen mode.

[slxdy]

I switched from Linux Mint to EndeavourOS and had no issues with TF2 so far. Either way, I discourage anyone from using Mint 22 rn considering the HUGE performance issues with Ubuntu 24

[christiandlloyd]

This also occurs for me, running Mint 22 Cinnamon Ryzen 9 5950x Arc A770

[toxx1220]

Has anyone with a different distro, DE/WM, or different hardware tried setting refresh and freq to match your display, yet? I am curious to know if other users can play the game fine by explicitly setting these launch options. #4817 mentioned this, too.

@TheBoctor Thanks so much, setting this worked for me! (-refresh 144 -freq 144) When trying to run TF2 before it would weirdly try to change my monitor config (resulting in them going black for a few seconds, for 2-3 times), while also showing tf2 does not respond for a few times, then just freezing my whole desktop/display server.

PopOs 22.04 LTS with Linux 6.9.3-76060903-generic Intel core i5 10600K RTX 2070 super, with driver version 560.35.03 Mutter (X11)

[MooZonkey]

I am experiencing this exact same issue ever since the Scream Fortress update was pushed. Running the launch options -freq, -refresh, -novid, -skip, -windowed, -sw, LD_PRELOAD* in any mix or match does not let me launch the game. I have also tried running the game with both vulkan and opengl with and without the above mentioned launch options.

Furthermore, I have created a symlink to a libtcmalloc_minimal.so file that I manually downloaded. This is a popular 'fix' method for Arch, but it did not work for me. Alternatively I tried outright replacing the default malloc file present in the /tf/bin/linux64/ folder, and that also did nothing. Even further, I have tried multiple different malloc files using both the symlink and file replacement method. No dice there either. After tinkering with the malloc fixes I normalized the game's files, removed launch options, and verified game integrity. No dice. The game continues to launch to a frozen black screen over 9 times out of 10. The only workaround I have found is to continually relaunch the game until it just works. This is a lengthy and nonsensical procedure. Additionally, running X11 or Wayland does not yield a different result. EDIT 2: Reinstalling the game changed nothing.

System Information: Arch Linux with the latest driver and kernel. GPU: RTX 3090 (nouveau, 555.58) CPU: Ryzen 7 5800X RAM: 32GB DDR4 3600

EDIT: A "crash" log is now provided. From what I can discern by the log activity, the game isn't actually crashing, but the TF2 window does not display anything. It's initially black on launch and transparent after opening it every consequent time thereafter. The ability to continue using my DE after launching the game proves that TF2 isn't nuking my X server.

TF2 log 2024 October 18.txt

[SexyBird66]

Go to Prime Profiles and change it to Nvidia (Performance Mode) under your Nvidia Settings. That might fix it.

[oamost]

hey valve, can you please fix this, it's been 6 months since this issue persists, and it's really lame. same thing as above: stock install tf2 gets launched (x64 vulkan), dual monitor setup, x server freezes. thanks.

OS: Arch Linux x86_64 Host: B550M AORUS PRO Kernel: 6.11.3-arch1-1 Uptime: 1 day, 8 hours, 27 mins Packages: 956 (pacman) Shell: bash 5.2.37 Resolution: 1080x1920, 2560x1440 DE: Xfce 4.18 WM: Xfwm4 WM Theme: Default-hdpi Theme: Adwaita [GTK2/3] Icons: Papirus-Light [GTK2/3] Terminal: xfce4-terminal Terminal Font: Monospace 12 CPU: AMD Ryzen 5 3600 (12) @ 4.208GHz GPU: NVIDIA GeForce RTX 3090 Ti Memory: 6138MiB / 32000MiB

[MooZonkey]

Go to Prime Profiles and change it to Nvidia (Performance Mode) under your Nvidia Settings. That might fix it.

It did not achieve a different result than any of my other tests.

[MooZonkey]

Issues: #6370 , #6086 , #5611 , #5770 , #5634 , #5961 , #5749 , #5725 , #5704 , and #6370 all appear to be related to the same central underlying issue.

Some observations: Freq works for some users but not others. Changing the memory allocation library works for some but not others. Using -windowed works for some users but not others. This issue is effecting a population of very diverse system configurations. Regardless of distro, DE, launch options, troubleshooting methods, etc. the issue still persists.