We’ve had a few reports lately of our Steam games opening onto a blank screen on Linux devices. If this is happening to you, could you write into support@choiceofgames.com with details about your device, what’s happening, and which games it’s happening with? Thanks!
Are there any updates on this problem?
1 Like
I’m still getting this issue as of today when running it on pop!_OS on a fresh install of both OS, Steam and game.
A workaround that works for me is to use the setting “Force the use of a specific Steam Play compatibility tool” under the games properties in steam and specify any of the Proton versions available.
1 Like
For any Linux or Steam Deck user searching for a solution, if simply forcing Proton compatibility does not work (it did not for me).
The Problem
A window is created when pressing Play in Steam, but it does not have any contents. It is blank.
Games tested:
the 4 Vampire: The Masquerade games
Hardware tested with:
A PC, a Chromebook, and a Steam Deck
Linux operating systems tested with:
Ubuntu, SUSE, and SteamOS
Steps taken:
-
Go into the game properties, select compatibility, then force Proton to be enabled (I used Experimental, but any recent version of Proton should work)
-
While still inside Properties, select General, then add the below line to the launch options
PROTON_USE_WINED3D=1 PROTON_NO_D3D11=1 %command%
It should correct the issue, since it worked on three separate operating systems, on three different pieces of hardware. Same problem, and same solution. It is not a true/full solution (as it must be done manually, and it is not Linux native, as the Linux/SteamOS label on the Steam store would suggest), but it works as a temporary solution.
Edit:
Just for further clarification, although I would be surprised if it was related to the issue, this was tested with AMD and Intel graphics, but not NVIDIA.
2 Likes
Hi,
I had the same problem when launching a game on Linux (blank window).
By forcing the Proton compatibility with one of the older versions (any newer than the 4.11 one doesn’t work) every game runs very smoothly.
For some reason the most recent versions of Proton don’t work, but the older ones work like a charm.
I tested it on Ubuntu 20.04 and Mint 20 with a dozen pairs of games and no one had problems.
To reply to @NoiramSang, I confirm that NVIDIA doesn’t arise issues, so I guess it’s a problem related to the Proton version used.
Hope it helps!
2 Likes
I just tested what Graviton said… and he is correct.
The extra line I added is not required for version 4.11-13 of Proton, and is the simpler solution.
Valve’s Proton 4.11-8 Begins Bundling VKD3D
I am just going to assume it is related to that then, since around that time period is when Proton versions break, and it is specifically Vulkan settings I am disabling with the line I added, to make it work for new versions of Proton.
Edit:
just for clarification, the two lines before did the following…
PROTON_USE_WINED3D=1
(Forces Proton to use OpenGL/WINED3D instead of Vulkan/DXVK)
PROTON_NO_D3D11=1
(Disable Direct3D 11)
2 Likes
I got the Linux version of the games working!
(on all three devices/OSs, including the Steam Deck)
Preliminary conclusion below:
Alright… this was bugging me. A lot.
Even though Proton let the Windows game be run in Linux, it was very non-ideal. It was fixing the Windows version, and not the Linux one.
I had to dig around in the processes running around in the background with the game, but I found roughly what it was doing, and a command to fix it.
–disable-seccomp-filter-sandbox
Note what is being disabled:
Seccomp (Wikipedia)
I will look into this slightly further later… but the Linux version can now be run with a launch command.
Also, a request: can any Linux users verify the above launch command works for them?
1 Like
I’m happy it worked!
Probably you’re right about the article, I reckon you had modified exactly the settings that made the newer Proton versions break when you launch the game.
About seccomp, since the game is sandboxed probably the sandbox’s restrictions and the newer versions of Proton conflict with each other and you can’t launch the game. However, to be honest I wouldn’t modify seccomp’s default settings and I’d go with your other way if I had to choose (better to keep programs sandboxed).
Luckily Proton’s older versions work so we got a quick and safe way around the problem!
I agree that people are generally better off without disabling seccomp, and using proton instead, unless they cannot use Proton (for example, Chromebooks have very limited space, and Proton takes up a great deal of space).
but the default option that you see on Linux does not appear to be using Proton, so I do not see how they could be conflicting. If you look at the game’s folder (at least the one I looked at), it has an “.exe” file when Proton is enabled, and it does not when the Linux runtime is enabled.
I mainly note seccomp because it gives strong suggestions on where to look for the issue to the game developers, and unlike the average Linux user, I do not expect the average person from the new batch of Steam Deck users to find a workaround (especially if it becomes more mainline/popular). I could be wrong, but it seems to be attracting a fair number of people who are not accustomed to tinkering with their games to get them to work. So better for it to be working by default, because otherwise people purchase games they cannot play.
1 Like
You made valid points, I agree with them.
You’re right, sorry, I didn’t think about that.
Probably seccomp is indeed partly responsible for that misbehaviour.
Yeah, some games sometimes require a bit of tinkering and tipically average Linux users are the ones used to that sort of things.
Unfortunately, on protondb there is little about this type of games and essentially the only way out is the one you pointed out, that is, using OpenGL and disabling DirectX11 on Proton. That way everything works fine.
Hopefully this post will help out those who had this problem in finding an easy solution!
I think I’ve addressed the Steam Linux issue, but, for now, I’m only rolling the fix out to one game, “Jolly Good: Cakes and Ale.” Please give it a try (you can test the demo, if you don’t own the full game) and report back.
(Before you test, you might want to right-click on the game, and go to Properties → Local Files → Verify Integrity. That will ensure that you’re running the current latest version of the game.)
For the record, here’s my understanding of the problem.
Background Terminology: Electron, Chromium, CEF
ChoiceScript games are all just web pages. On desktop, to distribute a web-page game as a native app, we distribute a private copy of Google Chrome, and configure it to only be able to open our single web page.
We use an open-source framework called “Electron” to embed Google Chrome. https://www.electronjs.org/ “Build cross-platform desktop apps with JavaScript, HTML, and CSS.”
Technically, Electron doesn’t use Google Chrome, but just the open-source parts of Google Chrome, which is called “Chromium.”
In 2014, prior to using Electron, I used another framework called the “Chromium Embedded Framework” (CEF). CEF forces me to write a bunch of code that Electron handles automatically, so Electron is better and far more popular than CEF.
Upgrading Chromium is manual effort: Whether I’m using CEF or Electron, upgrading to the latest Chromium requires manual effort, and it often breaks when I do it. As a result, I never upgrade Chromium (CEF or Electron) unless I need to, to fix a bug.
In 2017, I moved the Windows build from CEF to Electron, but I’d never switched the Linux build from CEF to Electron (because it worked fine, and upgrading would be actual work). Thus, most of our apps are currently running a Windows build with a 2017 version of Chromium, and the Linux build is running a 2014 version of Chromium.
(On macOS, we embed Safari instead of Chrome, and it’s super super easy to do by hand, so we’ve never really run into trouble with it. No special upgrades are required AFAIK.)
The Blank Screen Problem Is New
On my Ubuntu 22 Jammy Jellyfish machine, I repro the bug with a blank screen. The issue doesn’t occur on Ubuntu 20 Focal Fossa.
I’ve also reproduced the blank screen issue on Manjaro Linux, (based on Arch Linux) which is the distro that Steam recommends for testing Steam Deck compatibility. Developing for Steam Deck without a Dev-Kit (Steamworks Documentation)
We Can’t Use Proton to Fix This (But You Can)
Steam Proton is a compatibility tool to allow Linux machines to run Windows apps without recompiling them for Linux. (“Proton” and “Electron” have nothing to do with each other; it’s a total coincidence that both pieces of software are named after subatomic particles.)
As an end user, you can right-click on a game, go to the Compatibility section, and turn on Proton. There are a bunch of options to fiddle with there, and, here in this thread, @NoiramSang has explained how to turn on Proton, set those settings, and get the game to work.
Unfortunately, as a Steam app developer, I’m not allowed to automatically enable Proton or set its settings. Specifically, when I use the Steam developer console (“Steamworks”), there are a bunch of configuration options I’m allowed to set and use, but there’s no “Compatibility” section; no way to enable Proton. Individual end users like you can turn on Proton, but Steam doesn’t provide a way for us to say “Just turn on Proton for all Linux users, and use the following settings: _____.”
If we’re gonna fix this, we’re going to have to fix our Linux app “the right way,” by making an app that works fresh out of the box on Ubuntu and Manjaro.
Fixing It the “Right Way” Meant Upgrading Electron and Turning Off Sandboxing
As @NoiramSang discovered, there is an another way not to use Proton, which is to pass the --disable-disable-seccomp-filter-sandbox parameter to the Linux executable as it launches. Unlike Proton, I am able to instruct Steam to pass specific command-line arguments to my launcher; when I use it, the blank-screen issue goes away.
But even though the issue went away, I still had issues running that ancient 2014 version of Chromium on modern versions of Linux. For example, I was testing on a VM on a high-resolution “retina display” MacBook Pro, and I’d configured Ubuntu/Manjaro to increase the UI font size to match, but our Linux app wasn’t honoring those settings, so the font was teeeny tiny.
Upgrading CEF would require a ton of work on my part, and I’d hate to continue running Linux on CEF and Windows on Electron, so I decided to switch the Linux build from CEF to Electron. I’d hoped that just that would fix the blank-screen bug, but it didn’t; I still had to pass --disable-seccomp-filter-sandbox to get it to work.
While I was at it, I upgraded to the latest version of Electron on Windows and Linux. On paper, there’s no pressing need to upgrade Electron for Windows. Our Windows Steam app works fine. But it seems wise to get on the latest version of things (to delay the point at which things will randomly start breaking later on).
Initially, the new app with --disable-seccomp-filter-sandbox seemed to work fine on Ubuntu 22 and Manjaro, by which I mean: I copied a zip file containing an example ChoiceScript game to those machines, extracted the zip, and double-clicked the app, and it worked great.
But I found that there was another problem that only occured when launching the game via Steam. I submitted the app to Steam as a “beta” app, and tried launching it on Ubuntu 22. I clicked Play, and Steam just sat there, doing nothing, for almost exactly 90 seconds. (The green “Play” button changed to a blue button that said “X Stop,” but no game window opened; I couldn’t even see a blank screen.) Then, 90 seconds later, the window appeared, and the game ran.
On Manjaro, it was even worse… I think the game instantly crashed on startup. I clicked the Play button, it flashed to a blue “X Stop” button, and then instantly flashed back to a Play button, again, with no window popping up.
I had no clear idea why this was happening, but, while investigating --disable-seccomp-filter-sandbox, I found this page documenting Chromium sandboxing options. It mentioned that instead of --disable-seccomp-filter-sandbox, I could use --no-sandbox, which completely turns off sandboxing. When I used that, the app launched quickly and cleanly, scaled to the correct size, on both Ubuntu and Manjaro.
It Is Safe to Disable Sandboxing, I Think
The premise of Chromium sandboxing is that Chromium may be used to access untrusted third-party code. That code could do anything. It could try to exploit a bug in the browser, and from there, they might be able to gain access to the user’s home directory. If they’re very clever, they might even be able to exploit the kernel itself by exploiting bugs in Chromium.
But, from my perspective, we’re not running untrusted third-party code. All of the code in our game process is code that I’ve written or code that I’ve tested and vetted. We never use our Chromium browser to navigate to arbitrary web sites, so the sandbox doesn’t have much/any benefit for us.
Now, from your perspective, as a player, you might not fully trust me, and you might prefer that I leave sandboxing enabled, or at least disable it as little as possible, i.e. to prefer --disable-seccomp-filter-sandbox instead of --no-sandbox.
If the sandbox were working, if it were allowing my code to run but blocking dangerous exploits, I’d be happy to leave it on. But the sad fact is that Electron isn’t very well tested on various Linux distros. As far as I can tell, I do have to completely disable the sandbox to ensure a good experience for users, and so, that’s what I’ve done here.
6 Likes
I greatly appreciate the response and the (incoming) fix, as well as the amount of detail provided.
I only ran the demo for a few minutes, but it initially seems to work better than the two Proton options with the other games I tried. There were no apparent issues.
- I did not receive a blank screen, when starting or running the game.
Clarification: with Proton ~4, I did get a blank screen a couple of times while playing a different Choice game, not while starting it; closing+starting the game fixed it.
- It started more quickly than using Proton 7+ with the other games (which is more noticeable on older hardware than newer)
I checked it, as before, with 3 pieces of hardware (including a Steam Deck), and three distros of Linux. For the sake of avoiding cluttering up this thread, I will put my minor notes related to the Steam Deck and the game(s) in a different thread.
Thank you for the exhaustive response, it really helped understanding how your apps work!
As @NoiramSang did, I tried running Jolly Good too and it had no problems. Now it works out of the box.
However, it crashes if I use Proton. I don’t know if it can help with this discussion, but in that case a window pops out and tell me that it could not connect to steam and gives me error code 77779.
Since we no longer need to find a workaround I guess that’s not a problem though.
If someone is concerned about this and doesn’t trust the game’s code, downloading the flatpak Steam app and running it through flatpack (you can use this command to run apps directly from flatpak, flatpak run application_ID) should do the trick. As far as I know flatpak applications are sandboxed by default so the games opened through it should be too.
I tried it on Ubuntu 20.04 and the games worked flawlessly.
Kindly note that I’m not an expert on the topic, so if someone has more input about this or wants to correct something, please do.
@Graviton That bit about Proton is interesting, because when I checked the game last night, it also did not work when I Forced the Linux Runtime in the Compatibility settings, even when I launched it with the line disabling sandboxing (either of them). So it seems to be when forcing anything but the default… it is not just Proton.
Having said that, I do not consider it to be an issue, so long as the default continues working. It mostly means if something were to break in the future, there either is not a workaround anymore, or it is a slightly different one now. I assume it is due to the game now, as I understand it, passing a command-line argument that the compatibility options do not like.
Oh, and just to note, I am running Steam on some devices/OSs installed directly/normally, and some via flatpak. There is no observable difference in between them when playing the game that I am aware of, except what would affect all other Steam games. The sandboxing just results in minor oddities/annoyances, such as, the button to view the local game files does not work by default. All related to the sandboxing, as far as I know.
So, yes, although I am also not an expert on flatpak, it is sandboxing, and does offer more security than installing Steam directly… and, in my experience, also makes doing non-basic/non-standard things with it slightly more annoying. Which is to be expected.
At least at first glance, Parliament of Knives and Night Road appear to have been patched on Steam, and be working now, on both Linux and the Steam Deck (no modification required).
Edit:
No, it seems like it is all four VtM games working.
Greatly appreciated.
Is this why every choice game on steam needs to be updated?
Yes, earlier today I pushed updates for every Steam game to fix Linux support.
6 Likes
Everything now works out of the box on Linux too, thank you!
As I already wrote on the new topic that they opened, kindly note that you should turn off the compatibility tool option now or the game won’t start and you have to update it again.
Edit: just out of curiosity, is it just an impression of mine or did the character font of the games on Steam change? If that’s the case, is it possible to change it/revert it back manually?
My CoG games had been working out of the box, but since this last update went out all of them are bugged and no longer think I own them, only offering demo access. This is on Steam, running Linux Mint 19.3, by the way.
The in-game ‘restore purchases’ button did not help, verifying the files did not help, and reinstalling the game did not help. Then I tried running Night Road in Proton Experimental and that actually did fix it. Or at least it goes right to the game instead of the demo versions advertisement/overview page, though I haven’t played through the first four chapters to confirm that I’m playing the full game yet.
Also, it does feel a bit laggy and the window doesn’t size itself properly, cutting off the ‘next’ button on longer pages under my scrollbar. I never had to use Proton on a CoG product before, so maybe that’s not new. Anyone know how to fix this or do I need to email support?
Does anyone else in this thread reproduce this issue?