I'm getting a hard crash that seems to happen after 30 minutes or so. Here's the log file:
https://send.firefox.com/download/945b855f1dd20e0d/#dP9yXbTc4PGFlF5mkZL1EQ

I have a RX 5700XT and am using ArchLinux with RADV.

Hello @PopeRigby, please copy your system information from Steam (Steam -> Help -> System Information) and put it in a gist, then include a link to the gist in this issue report.

As a side note, Proton logs are known to compress well, please consider throwing large logs into an archive.

Here's the system information gist: https://gist.github.com/PopeRigby/263d2b99e3998f99fdf4e0d222845843

So does ACO work on Mesa 20.1 now? Last I heard ACO was not working.

Is it still true that enabling the overlay causes performance issues?

My own experience shows the opposite:
https://forums.developer.nvidia.com/t/low-performance-in-doom-eternal/116394/30?u=silviu_c

@kisak-valve - You made a comment in the other thread about removing libvulkan1 in Ubuntu, which is a BIG NO NO as it will nuke your system. Is there a better way in having the vulkan included with Steam runtime take priority over the system one?

teg@pop-os:~$ sudo apt remove libvulkan1
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages were automatically installed and are no longer required:
  cabextract efibootmgr evolution-data-server-common filezilla-common
  firmware-manager-notify firmware-manager-shared fonts-wine fprintd fuseiso
  gir1.2-accountsservice-1.0 gir1.2-appindicator3-0.1 gir1.2-gck-1
  gir1.2-gcr-3 gir1.2-gdm-1.0 gir1.2-gnomebluetooth-1.0 gir1.2-nm-1.0
  gir1.2-nma-1.0 gir1.2-upowerglib-1.0 gkbd-capplet glade2script
  gnome-session-common gnome-shell-extension-system76-power
  gstreamer1.0-pulseaudio gtk2-engines-murrine gvfs-libs i965-va-driver
  intel-media-va-driver libaacs0 libaom0 libasound2-dev libass9 libavcodec58
  libavfilter7 libavformat58 libavresample4 libavutil56 libbdplus0
  libblkid-dev libbluray2 libbs2b0 libcamel-1.2-62 libcapi20-3 libcapnp-0.7.0
  libcdio-cdda2 libcdio-paranoia2 libcdio18 libchromaprint1 libcodec2-0.8.1
  libcue2 libdazzle-1.0-0 libdbus-1-dev libdc1394-22 libdvdnav4 libdvdread4
  libebackend-1.2-10 libebook-1.2-20 libebook-contacts-1.2-3 libecal-2.0-1
  libedata-book-1.2-26 libedata-cal-2.0-1 libedataserver-1.2-24 libexiv2-14
  libfftw3-double3 libfilezilla0 libfirmware-manager libflite1 libfontenc1
  libfprint0 libgdm1 libgexiv2-2 libgif7 libgles1 libglib2.0-dev
  libglib2.0-dev-bin libgme0 libgnome-autoar-0-0 libgnomekbd-common
  libgnomekbd8 libgsf-1-114 libgsf-1-common libgsm1 libgsoap-2.8.75
  libibus-1.0-dev libigdgmm11 libjavascriptcoregtk-4.0-18 libldb1 liblilv-0-0
  libmikmod3 libmirclient-dev libmirclient9 libmircommon-dev libmircommon7
  libmircookie-dev libmircookie2 libmircore-dev libmircore1 libmirprotobuf3
  libmount-dev libmspack0 libmtp-common libmtp-runtime libmtp9 libmysofa0
  libnfs12 libnorm1 libodbc1 libopenal1 libopengl-dev libopengl0 libopenjp2-7
  libopenmpt0 libosmesa6 libpam-fprintd libpcre16-3 libpcre2-32-0 libpcre2-dev
  libpcre2-posix0 libpcre3-dev libpcre32-3 libpgm-5.2-0 libphonenumber7
  libpop-theme-switcher libpop-upgrade-gtk libpostproc55 libprotobuf-dev
  libprotobuf-lite17 libpugixml1v5 libpulse-dev libqt5positioning5 libqt5qml5
  libqt5sensors5 libqt5webchannel5 librubberband2 librygel-core-2.6-2
  librygel-db-2.6-2 librygel-renderer-2.6-2 librygel-server-2.6-2
  libs76-hidpi-widget libsdl-net1.2 libsdl-sound1.2 libsdl1.2debian
  libselinux1-dev libsepol1-dev libserd-0-0 libshine3 libsmbclient
  libsndio-dev libsord-0-0 libsratom-0-0 libssh-gcrypt-4 libswresample3
  libswscale5 libtalloc2 libtevent0 libtracker-control-2.0-0
  libtracker-miner-2.0-0 libudev-dev libva-drm2 libva-wayland2 libva-x11-2
  libva2 libvidstab1.1 libvncserver1 libwayland-bin libwayland-dev
  libwbclient0 libwebpdemux2 libwoff1 libwxbase3.0-0v5 libx264-155 libx265-176
  libxatracker2 libxcb-glx0 libxcb-res0 libxcb-xv0 libxcursor-dev
  libxfixes-dev libxfont2 libxi-dev libxinerama-dev libxkbcommon-dev
  libxkbfile1 libxklavier16 libxrandr-dev libxv-dev libxvidcore4 libxvmc1
  libxxf86dga1 libxxf86vm-dev libzmq5 libzvbi-common libzvbi0 mesa-va-drivers
  nautilus-data pastebinit pop-fonts pop-gnome-shell-theme pop-gtk-theme
  pop-icon-theme pop-sound-theme pop-theme python3-pyxattr python3-talloc
  rtmpdump rygel samba-libs switcheroo-control syslinux-common system76-power
  tracker tracker-extract tracker-miner-fs va-driver-all virtualbox-dkms
  x11-apps x11-session-utils x11-xkb-utils x11proto-fixes-dev
  x11proto-randr-dev x11proto-xf86vidmode-dev x11proto-xinerama-dev xbitmaps
  xfonts-base xfonts-encodings xfonts-scalable xfonts-utils xinit xinput
  xserver-common xserver-xorg-legacy yelp-xsl youtube-dl zenity-common
Use 'sudo apt autoremove' to remove them.
The following additional packages will be installed:
  libqt5gui5-gles
Suggested packages:
  qt5-image-formats-plugins qtwayland5
Recommended packages:
  libqt5svg5
The following packages will be REMOVED:
  boot-repair boot-sav boot-sav-extra chrome-gnome-shell
  com.github.tkashkin.gamehub dosbox evolution-data-server ffmpeg filezilla
  gdm3 ghostwriter gir1.2-mutter-5 gnome-calendar gnome-control-center
  gnome-getting-started-docs gnome-getting-started-docs-de
  gnome-getting-started-docs-es gnome-getting-started-docs-fr
  gnome-getting-started-docs-it gnome-getting-started-docs-ja
  gnome-getting-started-docs-pt gnome-getting-started-docs-ru
  gnome-getting-started-docs-zh-hk gnome-getting-started-docs-zh-tw gnome-mpv
  gnome-online-accounts gnome-session-bin gnome-shell
  gnome-shell-extension-alt-tab-raise-first-window
  gnome-shell-extension-always-show-workspaces
  gnome-shell-extension-desktop-icons gnome-shell-extension-do-not-disturb
  gnome-shell-extension-pop-battery-icon-fix
  gnome-shell-extension-pop-shop-details
  gnome-shell-extension-pop-suspend-button gnome-startup-applications
  gnome-user-docs gnome-user-docs-de gnome-user-docs-es gnome-user-docs-fr
  gnome-user-docs-it gnome-user-docs-ja gnome-user-docs-pt gnome-user-docs-ru
  gnome-user-docs-zh-hans gstreamer1.0-clutter-3.0 gstreamer1.0-gl gvfs
  gvfs-backends gvfs-daemons gvfs-fuse libavdevice58 libcheese-gtk25
  libcheese8 libclutter-1.0-0 libclutter-gst-3.0-0 libclutter-gtk-1.0-0
  libcogl-pango20 libcogl-path20 libcogl20 libedataserverui-1.2-2 libegl-dev
  libegl1-mesa-dev libfolks-eds25 libgl-dev libgl1 libgl1-mesa-dev
  libgl1-mesa-dri libgl1-mesa-glx libgles-dev libgles2-mesa-dev libglu1-mesa
  libglu1-mesa-dev libglvnd-dev libglx-dev libglx-mesa0 libglx0
  libgoa-backend-1.0-1 libgstreamer-gl1.0-0 libmpv1 libmutter-5-0 libqt5gui5
  libqt5opengl5 libqt5printsupport5 libqt5quick5 libqt5svg5 libqt5webkit5
  libqt5widgets5 libsdl2-dev libvdpau-va-gl1 libvkd3d1 libvulkan1
  libwebkit2gtk-4.0-37 libwine libwxgtk3.0-0v5 libyelp0 mesa-vulkan-drivers
  mpv mutter nautilus phantomjs pop-default-settings pop-session qsynth
  ubuntu-docs virtualbox virtualbox-qt wine wine64 winetricks x11-utils xorg
  xserver-xephyr xserver-xorg xserver-xorg-core xserver-xorg-input-all
  xserver-xorg-input-libinput xserver-xorg-input-wacom xserver-xorg-video-all
  xserver-xorg-video-amdgpu xserver-xorg-video-ati xserver-xorg-video-fbdev
  xserver-xorg-video-intel xserver-xorg-video-nouveau xserver-xorg-video-qxl
  xserver-xorg-video-radeon xserver-xorg-video-vesa xserver-xorg-video-vmware
  xwayland yelp zenity
The following NEW packages will be installed:
  libqt5gui5-gles
0 upgraded, 1 newly installed, 131 to remove and 0 not upgraded.

@btegs, where was this comment made?

a comment in the other thread about removing libvulkan1 in Ubuntu

@btegs, you should re-read that comment. Kisak didn't say remove, he said re-add.

a comment in the other thread about removing libvulkan1 in Ubuntu

@btegs, you should re-read that comment. Kisak didn't say remove, he said re-add.

I was referencing https://github.com/ValveSoftware/Proton/issues/3654#issuecomment-613766116 where re-adding libvulkan1 on Ubuntu 19.10 via apt would just re-install v1.1.114.

So if you leave that as the main libvulkan1 at a system level and remove pinned_libs_* from the steam install, how does this automatically make your AMD drivers under MESA use the libvulkan from Steam and not your system?

@btegs, removing the pinned_libs_* folders prompts Steam to regenerate those folders the next time Steam is started (this is literally what I said previously). The folder's contents is the result of comparing the system libraries to the Steam runtime variants and pinning the Steam runtime variant if it is newer than the host system.

Steam prioritizes libraries in the following order: Pinned libraries > Host system > Steam runtime > ld.so.conf

@btegs, removing the pinned_libs_* folders prompts Steam to regenerate those folders the next time Steam is started (this is literally what I said previously). The folder's contents is the result of comparing the system libraries to the Steam runtime variants and pinning the Steam runtime variant if it is newer than the host system.

Steam prioritizes libraries in the following order: Pinned libraries > Host system > Steam runtime > ld.so.conf

Deleted those folders and were recreated once starting Steam. I checked the directory and they were symlinking to a 1.2.135 version of Vulkan. cool.

Then I load up a random game with Proton 5.0-6 with the DXVK hud set to 1 under Ubuntu 19.10. It shows up as Mesa 20.0.99 (using the bleeding edge git version from https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers for my RX 580. Shows Vulkan 1.2.128 for my Vulkan version. I obviously cannot start DOOM Eternal either.

What is going on and what steps are missing?

NOTE: I found an Ubuntu repo at https://packages.lunarg.com/ which gives me an updated libvulkan1 and libvulkan1:i386 without affecting my current Mesa. 1.2.135 is installed, but whenever I try a game on Steam or using GameHub with a GOG game, it is still at 1.2.128. I have no clue where this version of Vulkan is coming from!

"Alt-Tab may break the game rendering."
Arch Linux with KDE Plasma, can confirm Alt-Tabbing broke game rendering, but it also resulted in unresponsiveness to the close procedure by right clicking the process in the task bar and clicking the "Close" button..
sudo kill -SIGHUP 31117 did close the game though
System Information: https://pastebin.com/1z80Y7WG

My hard crash seems to be happening after about 20 minutes every time I start the game. Maybe I could time it to check.

Adding bugs (perhaps obvious/already known):

• have to skip initial intro logo (_"+in_terminal 1 +com_skipIntroVideo 1"_)
• audio is crackling a little bit sometime (have to increase pulseaudio sampling to 48 kHz)
• multiplayer doesn't work (this is bad)

This game is also seems to be affected by https://github.com/ValveSoftware/Proton/issues/2927

If you're having problems, and you have a Ryzen 3xxx processor, try the workaround there ^

Doom Eternal Monitor/Resolution fail

Issue transferred from https://github.com/ValveSoftware/Proton/issues/3797.
@Kalevr1 posted on 2020-04-24T23:18:50:

Compatibility Report

• Name of the game with compatibility issues: Doom Eternal
• Steam AppID of the game: 782330

System Information

• GPU: RTX 2060 SUPER
• Driver/LLVM version: 4.6.0 NVIDIA 440.82
• Kernel version: 5.5.6
• Link to full system information report: https://gist.github.com/Kalevr1/6f5f51d29cc2e60e370c7dda858ace34
• Proton version: 5.0-6

I confirm:

• [x] that I haven't found an existing compatibility report for this game.
• [x] that I have checked whether there are updates for my system available.

steam-782330.log.zip

Symptoms

After installing latest SteamPlay Proton 5.06 I got one perfect play session that lasted several hours. I took a break to eat and then came back to continue play. I have a 2 monitor setup. When I tried to launch the game a second time, it switched to a small window on the the secondary monitor. The lower monitor is my default screen and sits at eye level. I can see the upper left corner of the Doom Intro being rendered within the quarter-sized window on the secondary monitor. The game engine thinks it is rendering on the entire screen but I only see the portion that overlaps the window. I can see 2 buttons in the UI and I can interact with them. I Alt-F4 to exit.

Seems fixable if I can manually force the monitor and resolution for the app but I don't know if that would work. One workaround I have found is if I delete ../steamapps/compatdata/782330 the game does 'first run' again, which always runs perfectly.

I have included a screenshot of both monitors (1920x2160 pixels). Steam is fullscreen below on primary and you see the Doom Window above on the secondary.

Reproduction

@Kalevr1 commented on 2020-04-24T23:21:15:

This is my first post so I hope it is correct starting a new report rather than attaching to another. If not apologies.

I've been trying to use the 5.06 proton and 5.6 GE, the game very often crashes on both of these.

Here is the Proton GE 5.6 crash log
Here is the Proton 5.06 crash log

I've been trying to use the 5.06 proton and 5.6 GE, the game very often crashes on both of these.

Here is the Proton GE 5.6 crash log
Here is the Proton 5.06 crash log

Guess my problem is solved. I guess, this problem was caused by an AVX instability on my processor. I had overclocked my processor but hadn't checked the overclocking stability with AVX2. I had to add an AVX offset for my CPU in bios in order to pass the "Small FFTs" tests in Prime95 with AVX2 in Windows and confirm the same stability using the stress utility on my archlinux. Once I did that, I have never seen any crashes anymore. My first guess was about the RAM instability (I also overclocked it), but having turned XMP off and on, untightened timings and frequencies, I was able to confirm that it was not a ram issue.

I'm effectively in the identical scenario, same versions, cannot figure out how to get DOOM Eternal not to crash on start. :(

Did you get this figured out @btegs ?

@btegs, removing the pinned_libs_* folders prompts Steam to regenerate those folders the next time Steam is started (this is literally what I said previously). The folder's contents is the result of comparing the system libraries to the Steam runtime variants and pinning the Steam runtime variant if it is newer than the host system.
Steam prioritizes libraries in the following order: Pinned libraries > Host system > Steam runtime > ld.so.conf

Deleted those folders and were recreated once starting Steam. I checked the directory and they were symlinking to a 1.2.135 version of Vulkan. cool.

Then I load up a random game with Proton 5.0-6 with the DXVK hud set to 1 under Ubuntu 19.10. It shows up as Mesa 20.0.99 (using the bleeding edge git version from https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers for my RX 580. Shows Vulkan 1.2.128 for my Vulkan version. I obviously cannot start DOOM Eternal either.

What is going on and what steps are missing?

NOTE: I found an Ubuntu repo at https://packages.lunarg.com/ which gives me an updated libvulkan1 and libvulkan1:i386 without affecting my current Mesa. 1.2.135 is installed, but whenever I try a game on Steam or using GameHub with a GOG game, it is still at 1.2.128. I have no clue where this version of Vulkan is coming from!

On the old thread a few users reported that battlemode can't find games, and I have the same issue. Nobody on that thread either suggested a cause or reported a fix, so I'd like to bring back attention to that issue.
When trying to find a match in battlemode, on any of the three choices, I simply cannot find a game, ever. There is not crash or error, though admittedly I haven't checked any log files.

I'm effectively in the identical scenario, same versions, cannot figure out how to get DOOM Eternal not to crash on start. :(

Did you get this figured out @btegs ?

@btegs, removing the pinned_libs_* folders prompts Steam to regenerate those folders the next time Steam is started (this is literally what I said previously). The folder's contents is the result of comparing the system libraries to the Steam runtime variants and pinning the Steam runtime variant if it is newer than the host system.
Steam prioritizes libraries in the following order: Pinned libraries > Host system > Steam runtime > ld.so.conf

Deleted those folders and were recreated once starting Steam. I checked the directory and they were symlinking to a 1.2.135 version of Vulkan. cool.
Then I load up a random game with Proton 5.0-6 with the DXVK hud set to 1 under Ubuntu 19.10. It shows up as Mesa 20.0.99 (using the bleeding edge git version from https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers for my RX 580. Shows Vulkan 1.2.128 for my Vulkan version. I obviously cannot start DOOM Eternal either.
What is going on and what steps are missing?
NOTE: I found an Ubuntu repo at https://packages.lunarg.com/ which gives me an updated libvulkan1 and libvulkan1:i386 without affecting my current Mesa. 1.2.135 is installed, but whenever I try a game on Steam or using GameHub with a GOG game, it is still at 1.2.128. I have no clue where this version of Vulkan is coming from!

I upgraded to Ubuntu 20.04 with that Vulkan package from lunarg and I still am stuck with 1.2.128. I removed the pinned libs (Steam even warns me when its recreating it on launch) and cannot get that newer version to sync up.

@kisak-valve ignored my comment before, but I'm glad that there are other people having this issue.

The following is Ubuntu 20.04, latest Nvidia drivers 440 with a GTX 1080. After the game is started, a small black screen shows on the second monitor and stays like that.

Sometimes it would show the actual menu instead of the black screen like this

But if I try to make the game go fullscreen by pressing ALT+ENTER, then all hell breaks loose

Alright well DOOM Eternal is now launching for me. I'm unsure what has changed for me to do this. It might have been a recent MESA driver update that fixed it, unsure. Just blind tried it again, and I'm able to get in and play the game. If I observe further issues I'll report them.

The following is Ubuntu 20.04, latest Nvidia drivers 440 with a GTX 1080. After the game is started, a small black screen shows on the second monitor and stays like that.

Sometimes it would show the actual menu instead of the black screen like this

But if I try to make the game go fullscreen by pressing ALT+ENTER, then all hell breaks loose

Did it happen on first-run as well or only subsequent launch attempts? If it's like my situation you can do a workaround by deleting the folder under compdata as I explained in my report, so that every run is a "first" run. I had to dual boot my way through this game unfortunately. It was either that or delete that folder with every launch of the game. Until they fix the multi-monitor launch bug, there is no other way that I can see.

But if I try to make the game go fullscreen by pressing ALT+ENTER, then all hell breaks loose

@luisalvarado instead of pressing alt-enter, try going into settings, and changing 'windowed' mode to 'borderless windowed' first. If it works, change it to 'fullscreen' then. Or just play on borderless?

But if I try to make the game go fullscreen by pressing ALT+ENTER, then all hell breaks loose

@luisalvarado instead of pressing alt-enter, try going into settings, and changing 'windowed' mode to 'borderless windowed' first. If it works, change it to 'fullscreen' then. Or just play on borderless?

Let me test. Thank you

I am on Fedora 32 Workstation with Steam flatpak. NVIDIA 1080 Ti. DOOM Eternal crashes at start. I have a tiny blank wine window for a few seconds. The window then closes and the game is not started. System info attached. I do have NVIDIA 440.82 drivers.

I use Proton 5.0.7

steam-hw.txt

@vatula I'm out of the loop when it comes to doom eternal, but could you get the stdout of wine by running doom manually? I don't think we have enough info to help you.

I was having a massive FPS drop in later stages of the arenas when a lot of monsters and particles appeared on the screen. I tried r_antialiasing 0, and the experience is greatly improved. I think there's an issue with the temporal antialiasing and particles for some reason.
Now the game feels smooth even in big battles.

@vatula I have a configuration almost exactly the same as yours (Fedora 32, GTX 1080 ti, latest released Proton). The only difference is that I don't use the Flatpak Steam. How averse would you be to trying the RPMFusion packge of Steam?

I used to use Flatpak (about a year ago or so), but I would sometimes have issues with games that I didn't have with the RPMFusion version.

DOOM Eternal runs really well for me.

@MagicRB @kisak-valve I'm attaching proton logs for the crash. It's hefty (3.7 GB), has some errors in it but because it's so large I couldn't figure out which one was critical. I have uploaded zipped log to mega.nz steam-782330.zip

@nathanjackson I confirm the game launches when Steam is installed from RPMFusion. @kisak-valve could that mean there's an issue with Steam flatpak?

Hello @vatula, possibly. Since there's a difference in behavior between the host system and flatpak, it wouldn't hurt to politely mention your experience to the flathub-provided steam package maintainers over at https://github.com/flathub/com.valvesoftware.Steam/issues.

I'm running into a weird issue after updating my OS. The intro video will freeze periodically, for almost exactly 5 seconds, then run for half a second or so, then freeze again and so on. The system is unresponsive during those freezes.

Specs:

• OS: Pop!_OS 20.04, kernel 5.4.0-7626-generic
• GPU: nVidia RTX 2070 Max-Q, driver version 440.82
• Vulkan: 1.2.140, installed manually
• Proton: happens both with 5.5-GE-1 and 5.0-7

The Proton logs show several lines that seem to repeat on each freeze:

10015.302:002d:002e:trace:seh:dwarf_virtual_unwind next function rip=0000000140325af5
10015.302:002d:002e:trace:seh:dwarf_virtual_unwind   rax=00007fffffea8000 rbx=00000000075a1cb0 rcx=00000000008fd690 rdx=000000007b475166
10015.302:002d:002e:trace:seh:dwarf_virtual_unwind   rsi=0000000000000005 rdi=0000000000000001 rbp=00000000008fee60 rsp=00000000008fed60
10015.302:002d:002e:trace:seh:dwarf_virtual_unwind    r8=00000000008fe910  r9=000000007b4751a0 r10=000000007bd225a8 r11=0000000000000000
10015.302:002d:002e:trace:seh:dwarf_virtual_unwind   r12=0000000000000001 r13=0000000000000001 r14=000000014293fd90 r15=ffffffffffffffff
10015.302:002d:002e:trace:seh:RtlRestoreContext returning to 7b475166 stack 8fe9d0
10015.432:002d:003e:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\dxvk_config.dll" at 0x69040000: native
10020.444:002d:002e:warn:debugstr:OutputDebugStringA "WARNING: PumpSessionAndNetworkPackets: Not called for 5.00 seconds\n"
10020.518:002d:002e:trace:seh:raise_exception code=40010006 flags=0 addr=0x7b00fdce ip=7b00fdce tid=002e
10020.518:002d:002e:trace:seh:raise_exception  info[0]=0000000000000044
10020.518:002d:002e:trace:seh:raise_exception  info[1]=00000000008fef10
10020.518:002d:002e:trace:seh:raise_exception  rax=00000000008fe930 rbx=00007fffffea8000 rcx=00000000008fe910 rdx=0000000000000000
10020.518:002d:002e:trace:seh:raise_exception  rsi=00000000008fea10 rdi=00000000008fe940 rbp=00000000008fed50 rsp=00000000008fe8f0
10020.518:002d:002e:trace:seh:raise_exception   r8=0000000000000002  r9=00000000008fea00 r10=000000007b47aa26 r11=0000000000000000
10020.518:002d:002e:trace:seh:raise_exception  r12=0000000000000001 r13=0000000000000001 r14=000000014293fd90 r15=ffffffffffffffff
10020.518:002d:002e:trace:seh:call_vectored_handlers calling handler at 0x69060d70 code=40010006 flags=0
10020.518:002d:002e:trace:seh:call_vectored_handlers handler at 0x69060d70 returned 0
10020.518:002d:002e:trace:seh:call_vectored_handlers calling handler at 0x14094ae30 code=40010006 flags=0
10020.518:002d:002e:trace:seh:call_vectored_handlers handler at 0x14094ae30 returned 0
10020.518:002d:002e:trace:seh:RtlVirtualUnwind type 1 rip 7b00fdce rsp 8fe8f0
10020.518:002d:002e:trace:seh:dump_unwind_info **** func fd80-fe07
10020.518:002d:002e:trace:seh:dump_unwind_info unwind info at 0x7b08e344 flags 0 prolog 0x11 bytes function 0x7b00fd80-0x7b00fe07
10020.518:002d:002e:trace:seh:dump_unwind_info     0x11: subq $0xc8,%rsp
10020.518:002d:002e:trace:seh:dump_unwind_info     0xa: pushq %rsi
10020.518:002d:002e:trace:seh:dump_unwind_info     0x9: pushq %rdi
10020.518:002d:002e:trace:seh:dwarf_virtual_unwind function 7b439ca1 base 0x7b439a58 cie 0x7b490710 len 14 id 0 version 1 aug 'zR' code_align 1 data_align -8 retaddr %rip

Here's a few more extracts around some of those freezes: https://gist.github.com/thebozzcl/d443097713938069abb233dabd4bba47

I'm still checking system logs to see if I find another pattern that could give me a clue.

When attempting to play Battlemode, I have not been able to connect to any games. I noticed some Bad Requests to AcceptGroupInvitation in the console, but I have been connected to Bethesda.net with no issue.

When attempting to play Battlemode, I have not been able to connect to any games. I noticed some Bad Requests to AcceptGroupInvitation in the console, but I have been connected to Bethesda.net with no issue.

I am having the same problem, this used to work on a previous Proton version.

When attempting to play Battlemode, I have not been able to connect to any games. I noticed some Bad Requests to AcceptGroupInvitation in the console, but I have been connected to Bethesda.net with no issue.
I am having the same problem, this used to work on a previous Proton version.

@nathanjackson Really? What was the version? I was never able to play Battlemode in any Proton versions :/

Battlemode worked for me when I had the following configuration:

• Proton 5.0-6 or 5.4-GE-3 (Glorious Eggroll)
• Fedora 30
• NVIDIA 440.82

However, I've recently upgraded to Fedora 32 and Battlemode stopped working, but a few variables changed:

• Proton 5.0-7
• Fedora 32
• NVIDIA 440.82

As a test, I tried Proton 5.4-GE-3 on Fedora 32 and Battlemode still did not work. So I think something about the OS upgrade has resulted in Battlemode no longer working. Although I think Bethesda pushed an update to DOOM Eternal for the Battlemode changes, so maybe that had something to do with it? It's weird because I can connect without issue to Bethesda.

Looks like the latest DOOM update broke the game on Proton. It doesn't launch at all anymore.

steam-782330.log

Yep, not launching at all with the new update. I see the id software logo in my system tray for a brief moment, and then it's gone.

Hello @libcg, looks like a WPF issue
trace:mscoree:mono_assembly_preload_hook_fn "PresentationFramework, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
The entry point method could not be loaded due to Could not load file or assembly 'PresentationFramework, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies.

Stopped working after last update for me too, doesn't launch at all.

Doom Eternal Patch 14 May broke the Game.

Issue transferred from https://github.com/ValveSoftware/Proton/issues/3867.
@TheReaperUK posted on 2020-05-14T17:37:02:

Compatibility Report

• Name of the game with compatibility issues: Doom Eternal

• Steam AppID of the game:782330

   

  System Information

• GPU: Nvida RTX 2060

• Driver/LLVM version: Nvidia 440.82
• Kernel version: 5.6
• Link to full system information report as Gist:

• Proton version: 5.0-7

  I confirm:

• [ Y] that I haven't found an existing compatibility report for this game.

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

Symptoms

Game will no longer Load at all after a Patch today 14 May 2020, No errors are shown, click Play wait a few seconds and nothing Happens and Play button returns to normal.

Reproduction

? It does not work at all, I think it may be anti cheat denuvo problem

Since last update (I think today, May 14, 2020 -- where can I see the update history?), it also does not work at all anymore. As reported before, no errors are shown, click Play, the id Software icon appears for 1-2 seconds as a tray icon, and then disappears, and Steams say it has stopped (it also says that last play time was just right now, so it looks like it doesn't get that there was some error).

Before that (a few days ago, when I last played), it ran really flawlessly, as reported here.

I installed dotnet48 into the game's prefix using protontricks, and now I get a denuvo popup when I start the game that says the game can't start.

Yeah, same with dotnet35sp1. It's likely that the WPF error is caused by the Denuvo popup itself.

@libcg I think you're right, given that this was logged before WPF was called on my end:

139193.878:00ec:00f0:trace:mscoree:_CorExeMain L"C:\\users\\steamuser\\
Temp\\denuvo-anti-cheat-crash-report.exe" "C:\\users\\steamuser\\Temp\\
denuvo-anti-cheat-crash-report.exe" "-error" "2" "-transaction"

From https://slayersclub.bethesda.net/en/article/2zHgbzsIV8gTzFUZ75ADGx/update-1:

I might have to ask for a refund if there's no DRM-free executable available.

Edit: refund requested

Edit: aaaaand refund denied :(

Consider me absolutely livid. One of my favorite games on Steam worked just fine on Linux, and then id decides to add kernel-mode anticheat, seemingly to spite me in particular.

From https://slayersclub.bethesda.net/en/article/2zHgbzsIV8gTzFUZ75ADGx/update-1:

Maybe one need uninstall the Denuvo Anti-Cheat to run the game?

@artemyto I've read that it's possible to uninstall Denuvo, but then the game won't run.

By the looks of it, this pretty much cans Doom Eternal on Linux through Proton. Proton can't actually support DAC, like, at all.

Unless id or Bethesda permits people to launch the game without DAC and play singleplayer, there really doesn't seem to be much we can do...

I urge people affected by this to send a support ticket through Bethesda's website here. Tell them to get rid of the kernel-mode anticheat. It's invasive, and quite frankly unacceptable to add this to a game that's been out for two months already.

As satisfying as that may be, I don't think it will actually change anything. A few people crying in outrage in a periphery demographic that Bethesda and id quite frankly probably don't care about isn't going to reverse a decision that was likely made quite a while ago.

And, y'know. An outpouring of bile isn't exactly endearing...

Hopefully Bethesda will remove Denuvo like they had the decency to do with Doom 2016.

It's not that simple. DAC != Denuvo.

And they probably won't remove DAC unless they shutdown the multiplayer portion of the game.

Yeah Denuvo Anti-Cheat is different from Denuvo Anti-Tamper, I hope there is an option or command line argument to skip DAC similar to EAC's -eac-nop-loaded (at least this works for DBFighterZ).
_For now remove this game from my wishlist_.

Same problem for me...

And I just bought the game, oh F.

Consider me absolutely livid.

This could have been me, but I've been pinching my pennies lately because of job losses, as a result of covid-19. I won't buy it now.

Bad news... It's the flagship title for Denuvo's anti-cheat. The AC is never getting removed. Valve and the Mesa devs wasted their time making it compatible and performant.

If you have an update queued but haven't installed it yet, here's how you can stick to the old version:
1.) Close Steam
2.) Extract and replace the attached file into the steamapps folder (same library as where D.E is installed.) EDIT: New manifest attached by gralco
3.) Relaunch Steam.
No update will be queued as Steam now believes you are on the current version, but you will have to avoid validating the game files.
If the referenced manifest is outdated and none are available, you can edit the attached manifest and manually match the buildid and InstalledDepots+MountedDepots to their latest versions using the steamdb.
If you already performed the update, you'll have to find another source for older game files. Keep in mind that bethesda launcher versions are unfortunately not compatible with steam save files.
I did try a method involving the steam console and older manifests, but those older manifests for Doom Eternal do not appear to be available.

Hope that helps. With some luck in the future maybe we can get Bethesda to drop Denuvo AC as a launch requirement, or at the very least provide older versions through the beta tab (could be pitched as a speedrunner argument as well).

So my understanding of the problem now is that this denuvo anticheat crap uses .NET WPF for the installer, and it just so happened that Wine 5.7 introduced support for it recently

https://www.winehq.org/announce/5.7
- Wine Mono engine updated to 5.0.0, with upstream WPF support.

On paper, Proton-GE-5.8 should work, but it didn't for me. Also @TerminalJunkie5 used protontricks to install dotnet48, but the installer still looks to be failing. Even if the installer works perfectly, there's still no guarantee that the anticheat will cooperate enough with proton to launch the game.

In other words, just AAA publishers being typical AAA publishers

is there any way to undo the update?

If you have an update queued but haven't installed it yet, here's how you can stick to the old version:
1.) Close Steam
2.) Extract and replace the attached file into the steamapps folder (same library as where D.E is installed. appmanifest_782330.acf.zip
3.) Relaunch Steam.
No update will be queued as Steam now believes you are on the current version, but you will have to avoid validating the game files. When a new update comes out, a new appmanifest will be required to stick to the old version if needed.

Your way works, i can still launch the game and no update is required after placing the acf file.
One more hint; you can disable auto update under Doom Eternal -> Properties -> Updates -> Only update this game when I launch it.
This could help those who got the update auto installed by steam yesterday, but still requires the recent acf before launching.

If the update has already started and you managed to hit the "Pause" button, delete the content under $STEAM_LIBRARY_PATH/steamapps/downloading. Then place the manifest file from above. Restart steam.

The update release notes on steam says:

Denuvo Anti-Cheat can be uninstalled at any time through the "Add or remove programs" dialog
For more information, please see https://help.bethesda.net/ or refer to Denuvo's launch day blog here

Now, how can I uninstall this under Proton?

@nuku97 I guess it only states you can only uninstall Denuvo AC. The game won't start anyway with it uninstalled. That's what I understood.

It would be pretty useless as an anti-cheat system if you could just uninstall it and the game works like it did before.
Since this was added for BATTLEMODE, I hope a future update will allow the game to play the single-player campaign without Denuvo AC requirement.

Make an anti-cheat who broke the game for those who pay after releasing a free denuvo version where anybody can play without buying it. Bethesda u did t u sons of bitch

The update release notes on steam says:

Denuvo Anti-Cheat can be uninstalled at any time through the "Add or remove programs" dialog
For more information, please see https://help.bethesda.net/ or refer to Denuvo's launch day blog here

Now, how can I uninstall this under Proton?

From what I seen, you're suppose to be able to uninstall Denuvo Anti-Cheat, but the game won't run until it's installed again

The update release notes on steam says:
Denuvo Anti-Cheat can be uninstalled at any time through the "Add or remove programs" dialog
For more information, please see https://help.bethesda.net/ or refer to Denuvo's launch day blog here
Now, how can I uninstall this under Proton?

From what I seen, you're suppose to be able to uninstall Denuvo Anti-Cheat, but the game won't run until it's installed again

I will try in my dual boot Windows later if uninstalling allows at least single player games. After all, I don't care about Battlenet...

The update release notes on steam says:
Denuvo Anti-Cheat can be uninstalled at any time through the "Add or remove programs" dialog
For more information, please see https://help.bethesda.net/ or refer to Denuvo's launch day blog here
Now, how can I uninstall this under Proton?

From what I seen, you're suppose to be able to uninstall Denuvo Anti-Cheat, but the game won't run until it's installed again

I think u can unistall it with protontricks

The update release notes on steam says:
Denuvo Anti-Cheat can be uninstalled at any time through the "Add or remove programs" dialog
For more information, please see https://help.bethesda.net/ or refer to Denuvo's launch day blog here
Now, how can I uninstall this under Proton?

From what I seen, you're suppose to be able to uninstall Denuvo Anti-Cheat, but the game won't run until it's installed again

I think u can unistall it with protontricks

Don't see what the point of this is right now since Denuvo anticheat can't even be installed in the Wine prefix yet due to the .NET WPF issue

DAC doesn't run under Proton and probably never will.

It's trying to do one of several things that it's all-but impossible for Proton to support.

I think we should all send feedback for Bethesda like @serebit suggested. I send mine with logs and links, showing then that are a community of people who play their game in Linux. I not ask for support for Linux, but for the option of launching the game without the Denuvo anti-cheat, just for the single player campaign.

There are already Windows users on Reddit requesting the same.

The update release notes on steam says:

Denuvo Anti-Cheat can be uninstalled at any time through the "Add or remove programs" dialog
For more information, please see https://help.bethesda.net/ or refer to Denuvo's launch day blog here

Now, how can I uninstall this under Proton?

Set the game launch options to:
bash -c 'exec "$1" "$2" "uninstaller.exe"' -- %command%
and Proton will launch the "Add/Remove Programs" dialog.

DAC doesn't run under Proton and probably never will.

It's trying to do one of several things that it's all-but impossible for Proton to support.

Doesn't Wine support another kernel anti-cheat by running a virtual kernel, or does DAC do things that cannot be emulated?

To my understanding, this is not the case, and Wine doesn't support any kernel-mode anti-cheat.

I may be wrong.

To my understanding, this is not the case, and Wine doesn't support any kernel-mode anti-cheat.

I may be wrong.

Wine has supported kernel-mode drivers for some time now, but whether it implements whatever a particular anti-cheat requires is another thing entirely. For example, a bunch of them require Wine Bug 37355 to be resolved.

It would appear that Wine bug might be dependent on a kernel feature to be fixed?

My bad then. Perhaps one day DE will run again. (I wouldn't say soon)

I hate Kernel-mode Anti-cheat conceptually, but I'd feel a heck of a lot better about it in a Wineprefix where I can count on Wine to mediate between the AC and the rest of the system (and ensure that it's not sniffing about in places where it should not be...)

From techraptor.net interview:

TR: Linux gamers were previously able to play the game on Steam via Proton in singleplayer. Adding Denuvo Anti-Cheat there has blocked that - is there any way that Denuvo Anti-Cheat could allow the single-player to run on virtual machines while protecting multiplayer or removing it?

MG: We've been tracking the Proton issue immediately after launch and are committed to delivering a fix soon. This isn't a request coming to us from a publisher or anything like that - we genuinely respect such an enthusiast community and regret introducing this incompatibility on day 1.

This makes me feel warm and fuzzy inside, thanks for sharing @mgreshis !

From techraptor.net interview:

TR: Linux gamers were previously able to play the game on Steam via Proton in singleplayer. Adding Denuvo Anti-Cheat there has blocked that - is there any way that Denuvo Anti-Cheat could allow the single-player to run on virtual machines while protecting multiplayer or removing it?

MG: We've been tracking the Proton issue immediately after launch and are committed to delivering a fix soon. This isn't a request coming to us from a publisher or anything like that - we genuinely respect such an enthusiast community and regret introducing this incompatibility on day 1.

Can you provide a link to this interview?

https://techraptor.net/gaming/news/doom-eternals-latest-update-breaks-game

"MG" is the product owner of Denuvo Anti-Cheat for context.

https://techraptor.net/gaming/news/doom-eternals-latest-update-breaks-game

"MG" is the product owner of Denuvo Anti-Cheat for context.

Who is also, judging by the username, @mgreshis, who posted the interview excerpt and the link. So we have the product owner right here in the issue.

Imho, this kind of behaviour from the developers aren't acceptable. Even if I could get it working with all the mentioned workarounds I decided to request a refund. Even if the refund is denied it at least puts some (although minor) pressure on steam and hopefully Bethesda.

(As I wrote this I can tell you that Steam support granted my refund request and have given me my money back. I suggest people doing this as a sign of protest. Don't accept this. Show them that they will lose customers with this type of behaviour. Let the wallet speak. It is the only language they understand)

@SysGh-st how many hours did you have? My refund request was denied yesterday. I wonder if they are relaxing restrictions on refund requests for this game now? Other good action points are:

1. Leave negative steam reviews
2. Mark other negative reviews as helpeful

@lpww
I honestly can't recall the numbers of hours. I got a bit into the single-player campaign. I bought this some time ago with extra everything ( €89 or thereabout ) as a prelaunch buy.
I politely described why I requested the refund as it wasn't working under proton/Linux and I had no other computers with windows available which would turn the product completely useless for me.

I guess being polite and describe why goes a long way. The request is after all read by a human on the other end. I really hope Steam Support does relax the restrictions when there are issues like this.
Personally I don't think this will be solved any time soon. The Linux community is simply far too small to be cared for. Sad but true.

I really wish I'd opened firefox to get all the notifications about this before launching Steam today and having the game update. Now I'm screwed.

Guys, I'm pretty frustrated about this situation as well. I'm not a huge fan of Kernel level anticheat in general, and it breaking a game that was working is certainly disheartening.

We can be frustrated with Bethesda for deploying this, however, let's give Denuvo a chance to deliver, that's certainly one of the most powerful and direct statements (I've seen at least) from an anticheat development company, and it's encouraging.

Also for @kisak-valve's sake and everyone else subscribed to this issue waiting for news of how to get this game running again... Let's keep this from turning into numerous rants, and discussions of refunds. We have reddit, bethesda forums, and steam forums to discuss this broader topic in.

@mgreshis If I may ask, will your fix allow us to play the multiplayer, or will it only allow us to play singleplayer? I'm fine with either option, I'm just curious.

@serebit I would refrain from questions like that until there actually is a fix. Far too many times have we heard a game or a fix for something is coming "soon" for Linux, only for it never to materialize, and also as @DarkArc said, we should keep this thread as clean as possible for @kisak-valve's sanity, and I also apologize for my contribution to that.

That doesn't work on Linux. It requires running batch files.

On Fri, May 15, 2020 at 5:26 PM Campbell Jones notifications@github.com
wrote:

For everyone affected by this, until we get a fix from the developers,
you'll have to use the following process to downpatch the game:
https://docs.google.com/document/d/1iugtqVUuG8TsnZyRzBV-QamdbygdSEGJzOSkDFGpgJU/edit

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-629497189,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM5Y33ZWU6ERMBYYVGE2JT3RRWXP3ANCNFSM4MI6DHIA
.

That doesn't work on Linux. It requires running batch files.
…
On Fri, May 15, 2020 at 5:26 PM Campbell Jones @.*> wrote: For everyone affected by this, until we get a fix from the developers, you'll have to use the following process to downpatch the game: https://docs.google.com/document/d/1iugtqVUuG8TsnZyRzBV-QamdbygdSEGJzOSkDFGpgJU/edit — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3773 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM5Y33ZWU6ERMBYYVGE2JT3RRWXP3ANCNFSM4MI6DHIA .

You have the separate commands list at the end. They're useful I'd hope.

@SysGh-st you have to run them in depotdownloader. Which is a Windows .bat program. So again....

They're also Windows commands.

@gardotd426 I'm sure you can open a "windows" cmd from wine, how well it runs .bat files i dont know but it might be wortha try

It also requires dotnet core installed, which does have a Linux version,
but I imagine you'd need the Windows version installed in a wineprefix.

On Fri, May 15, 2020 at 5:38 PM MagicRB notifications@github.com wrote:

@gardotd426 https://github.com/gardotd426 I'm sure you can open a
"windows" cmd from wine, how well it runs .bat files i dont know but it
might be wortha try

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-629504278,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM5Y33ZO33Z32OO2UYHHGGLRRWY47ANCNFSM4MI6DHIA
.

Okay, well I figured out how to get it to work, you need the Linux version of dotnet core and after you follow the dotnet core installation instructions, you can run everything like it's a list of shell commands, like

./depotdownloader COMMAND1
./depotdownloader COMMAND2

But, it's not going to work, because as the instructions say, it'll only allow you to be able to run the .exe directly, which means none of the proton patches will be available, so it's very unlikely to actually work, and you'll have to install dxvk and all that inside the wineprefix, and again, I just really doubt it'll work. I'll ask TK-Glitch if maybe he has any ideas on getting it running once I download everything.

If the problem is steam not running the exe, im kind of lost, its not hard to make it run manually, just download the latest proton-ge build, or build wine using tk-glitch's scripts with protonification patches and install dxvk, it should work

Steam won't allow you to run the game because it will still say an update
is required, even in offline mode. And running games in Steam through
proton is not at all the same thing as running them with that same wine
build manually with none of the rest of proton. It's not likely to work,
but I'm going to try.

On Fri, May 15, 2020 at 6:04 PM MagicRB notifications@github.com wrote:

If the problem is steam not running the exe, im kind of lost, its not hard
to make it run manually, just download the latest proton-ge build, or build
wine using tk-glitch's scripts with protonification patches and install
dxvk, it should work

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-629519573,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM5Y337DUWQ7UHR4AEGIZLTRRW37DANCNFSM4MI6DHIA
.

On some games it does work, idk, i dont own doom eternal

https://steamdb.info/sub/235874/depots/
Looks like just another update got released...

@peterge1998 yeah it doesn't fix anything.

What's stupid is if you go to the game properties, and select the "DLC" tab, we all have the "Doom Eternal - Single Player Campaign" as DLC, which means they're separate entities, and we should be able to launch it, but we can't.

I think you'll just have to wait on this one, till id releases something

@MagicRB first of all, you don't own this game, so I don't know what you're really doing here commenting and just adding to the noise with literally nothing helpful. Second of all, iD isn't going to release anything, obviously they're the ones that broke it in the first place. Now "MG" from Denuvo says Denuvo MIGHT fix it, but that's completely up in the air right now, and we're all past our refund window, which is absolutely unacceptable and honestly probably criminal, since they conveniently waited until everyone was going to be past the refund window before doing this, and never gave any indication beforehand that this would happen.

That said, that's not whatsoever the point of this thread, the point of this thread is to try and get the game working under Proton, this is the Valve Proton issues page. So "you'll just have to wait," especially when you don't own the game, and have no stake or bearing on this whatsoever, is rather unhelpful. As people have already requested, this is for trying to get this game running. Not your thoughts.

Here's the steam log after the latest update (after the initial one) that just came through, if it's any different from before:
steam-782330.log

2.) Extract and replace the attached file into the steamapps folder (same library as where D.E is installed. appmanifest_782330.acf.zip

How did you generate the appmanifest file? Or did you just copy this after installing the latest version? Because yours isn't the latest version anymore...
Editing your manifest and overwriting the Depot 782332 manifest and MountedDepots with the current manifest id and replacing LastUpdated with the current time does not work for me...

They posted that before the latest update that you just mentioned, so obviously that won't be the correct manifest

You honestly SHOULD be able to keep your appmanifest file from after updating and then copy it after downpatching. But I honestly don't see how downpatching could work, except maybe trying to run it in Lutris DRM-free without launching Steam.

Now that I think of it, I don't know how that would work, because you can't dictate wine or proton versions. You can't enable vkd3d or dxvk that way either, but this game obviously shouldn't need it because it's native Vulkan.

Proton is fundamentally Wine. So if you have the DRM-free version, just setup a wineprefix and dump the game in.

Shouldn't be too hard to write a Lutris script...

This isn't about the DRM-free version, it's about the Steam version. And
the issue isn't DRM, it's Denuvo Anti Cheat, which is completely different.
The downpatching mentioned above just basically undoes the update, but it's
still the DRM version, and Steam itself won't let you launch it the normal
way without updating. And Proton has Wine in it, but it's not the same
thing. Proton has numerous fixes and other things OUTSIDE of the winebuild
contained within, and they're attached to the 7-digit AppID, which won't be
present when trying to run the game some other way, so you won't be getting
any of the Doom Eternal fixes (if necessary) from proton except what's been
patched in that build of Wine. "Proton" is a python script that combines
wine and numerous other tools, and it can only be used AS Proton with Steam
games launched in Steam.

Yes. But the downpatched version should be compatible with the leaked exe. You'd lose your saves, but it would probably be playable in normal wine.

If you really wanted you could build Proton yourself and use it independent of steam... but that's a lot of effort.

You can use a protonified wine outside steam, or you can use a custom
proton's wine build outside steam, but proton and all the non-wine things
that make it up, I mean not really. You could technically MANUALLY convert
everything from the python script into some other type of script, but at
that point it's no longer Proton and that's a complete philosophical
question.

And at any rate, it's not even relevant because no one should be forced to
use leaked cracked .exes to play a game they bought and paid for.

Obviously it's not the way things should be, but it is a way to play the game right now.

Only thing I can think of, anyways.

Here's the latest appmanifest_782330.acf

appmanifest_782330.zip

sounds there is a latest Doom Eternal update. does anyone with this latest update become better or worse. here I become even worse, after open system tray of wine then will close abruptly. before can launch the game, although will exit once really start a game

@gardotd426 There are ways to run downgraded versions of steam games that 'require' an update to play. Have you tried any of these solutions? https://steamcommunity.com/sharedfiles/filedetails/?id=885555151

I was able to downgrade the game using the method described by the Google Doc from earlier.

I just had to let steam re-download the game first (I had it uninstalled earlier). Then I followed the guide to download the old files, and copied those files into DOOM Eternal's installation directory. After that I was able to launch the game via steam.

@TheGreatMcPain are you on windows on linux? Did you have to do anything special to prevent steam from updating the game automatically? I'm currently downloading the downgrade

@lpww I'm on linux, and the only thing I needed to do that was linux specific was install dotnetcore.

Since I let steam fully download the game it thinks the game is already up-to-date, so as long as I don't verify the game's cache steam shouldn't re-download the update. Although, steam will probably re-update the game if a new update comes out. If that happens I'll probably let steam download the update, and then replace it with the old files again.

Just in case I did set the game's properties to "Only update this game when I launch it".

Is there any chance you'd be able to type up a quick step by step?

I'm trying to issue "wine ./script.bat" from the depotdownloader location and getting "0009:err:module:__wine_process_init failed to load L"Z:\home\petter\H\00e4mtningar\script.bat", error c000012f
"

@peppot you don't use wine, you install the linux version of dotnet core.
There is actually a linux version.

On Sat, May 16, 2020 at 2:52 PM peppot notifications@github.com wrote:

Is there any chance you'd be able to type up a quick step by step?

I'm trying to issue "wine ./script.bat" from the depotdownloader location
and getting "0009:err:module:__wine_process_init failed to load
L"Z:\home\petter\H\00e4mtningar\script.bat", error c000012f
"

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-629690846,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM5Y336YTCNK6V2NITXHQELRR3OIDANCNFSM4MI6DHIA
.

I'm getting the hang of it. Modifying the .bat script instructions to shell versions such as /depotdownloader -app 782330 -depot 782332 -manifest 4641765937586464647 -username $un -password $pw -dir .
(did export un=myusername, export pw=mypwd) and running the listed commands accordingly

Yep. that's what I did, although I haven't been able to test the game yet.
I'm copying the files now.

On Sat, May 16, 2020 at 2:57 PM peppot notifications@github.com wrote:

I'm getting the hang of it. Modifying the .bat script instructions to
shell versions such as /depotdownloader -app 782330 -depot 782332 -manifest
4641765937586464647 -username $un -password $pw -dir .
(did export un=myusername, export pw=mypwd) and running the listed
commands accordingly

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-629691457,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM5Y334NTYBEKS2REDWFAY3RR3O3NANCNFSM4MI6DHIA
.

Prerequisites

1. Install .NET Core. More details here. You need to add this to your path after installing. I added PATH=$PATH:~/.dotnet/tools to the end of my ~/.profile

2. Follow the directions to download and extract DepotDownloader from the Google doc

Download the downgraded files

I wrapped the download instructions in a script. You will need to make it executable and run it from the folder your extracted DepotDownloader into

#!/usr/bin/env bash

STEAM_USERNAME=xxx
STEAM_PASSWORD=xxx
DOWNLOAD_PATH=~/Downloads/doom_downpatch_files

./depotdownloader -app 782330 -depot 782332 -manifest 4641765937586464647 -username "$STEAM_USERNAME" -password "$STEAM_PASSWORD" -remember-password -dir "$DOWNLOAD_PATH"
./depotdownloader -app 782330 -depot 782333 -manifest 4686311672633195957 -username "$STEAM_USERNAME" -password "$STEAM_PASSWORD" -remember-password -dir "$DOWNLOAD_PATH"
./depotdownloader -app 782330 -depot 782334 -manifest 2624212357815850298 -username "$STEAM_USERNAME" -password "$STEAM_PASSWORD" -remember-password -dir "$DOWNLOAD_PATH"
./depotdownloader -app 782330 -depot 782335 -manifest 8671913471625122045 -username "$STEAM_USERNAME" -password "$STEAM_PASSWORD" -remember-password -dir "$DOWNLOAD_PATH"
./depotdownloader -app 782330 -depot 782336 -manifest 4248922069342282231 -username "$STEAM_USERNAME" -password "$STEAM_PASSWORD" -remember-password -dir "$DOWNLOAD_PATH"
./depotdownloader -app 782330 -depot 782339 -manifest 8937962102049582968 -username "$STEAM_USERNAME" -password "$STEAM_PASSWORD" -remember-password -dir "$DOWNLOAD_PATH"

Copy downgraded files to Steam

...coming soon when I get this far

@peppot, yeah I can also confirm it does work. It gives you a warning after launching that Online Rewards, XP, and other Online Progress can't be saved until the required update is installed, but it allows you to continue. For now.

did you move your old DOOM folder out of the way and replaced it with the downloaded contents and launched it from within Steam?

No, that's unnecessary. You just replace the files already there.

I would still back up the game folder first, before doing anything. But yeah you just copy the files over top the existing install.

To launch, did you go into offline mode to avoid update attemps?

@peppot I didn't need to, but it's probably recommended.

I tried to launch it using offline mode and Proton-5.6-GE-2 and I got an error message from DOOM itself, saying it needed to be online

Take a screenshot of the error message and post it here.

Wait nevermind, I was thinking you couldn't get it to launch in regular online mode. Yeah, you have to have Steam be online for the game to launch. All you have to do is keep all the downloaded files, and if a new update is forced, download it, then just copy the files back again just like this time.

You can't stop updates, but you can just re paste over the files after an update. Plus, you'll have to update to get the new appmanifest file, or else it won't let you launch the game period.

Also, an update might fix the game. Either way, you have to keep updating, just make sure to keep the downpatched files you downloaded, for every time you update. This is the best that can be done right now.

I tried to launch it using offline mode and Proton-5.6-GE-2 and I got an error message from DOOM itself, saying it needed to be online

I think you need to be online on first launch to make Denuvo's DRM happy.

Prerequisites

1. Install .NET Core. More details here. You need to add this to your path after installing. I added PATH=$PATH:~/.dotnet/tools to the end of my ~/.profile
2. Follow the directions to download and extract DepotDownloader from the Google doc

Download the downgraded files

I wrapped the download instructions in a script. You will need to make it executable and run it from the folder your extracted DepotDownloader into

#!/usr/bin/env bash

STEAM_USERNAME=xxx
STEAM_PASSWORD=xxx
DOWNLOAD_PATH=~/Downloads/doom_downpatch_files

./depotdownloader -app 782330 -depot 782332 -manifest 4641765937586464647 -username "$STEAM_USERNAME" -password "$STEAM_PASSWORD" -remember-password -dir "$DOWNLOAD_PATH"
./depotdownloader -app 782330 -depot 782333 -manifest 4686311672633195957 -username "$STEAM_USERNAME" -password "$STEAM_PASSWORD" -remember-password -dir "$DOWNLOAD_PATH"
./depotdownloader -app 782330 -depot 782334 -manifest 2624212357815850298 -username "$STEAM_USERNAME" -password "$STEAM_PASSWORD" -remember-password -dir "$DOWNLOAD_PATH"
./depotdownloader -app 782330 -depot 782335 -manifest 8671913471625122045 -username "$STEAM_USERNAME" -password "$STEAM_PASSWORD" -remember-password -dir "$DOWNLOAD_PATH"
./depotdownloader -app 782330 -depot 782336 -manifest 4248922069342282231 -username "$STEAM_USERNAME" -password "$STEAM_PASSWORD" -remember-password -dir "$DOWNLOAD_PATH"
./depotdownloader -app 782330 -depot 782339 -manifest 8937962102049582968 -username "$STEAM_USERNAME" -password "$STEAM_PASSWORD" -remember-password -dir "$DOWNLOAD_PATH"

Copy downgraded files to Steam

...coming soon when I get this far

I tried the commands and all I get is a fail on the authentication token

Got session token!
Got AppInfo for 782330
Using app branch: 'Public'.
Got depot key for 782332 result: OK
Downloading depot 782332 - Windows Executable
Downloading depot manifest...Got CDN auth token for ctr-10075-eu-it.steam-content-dnld-1.qwilted-cds.cqloud.com result: Fail (expires 1/1/1970 12:00:00 AM)
Disconnected from Steam

I've padded out my existing script while waiting for the files to download. It handles the DepotDownloader part but not yet the copy stage as I am not that far yet. It can be found here: https://github.com/lpww/doomgrader

@giacomo-porro I don't think my extended script would help as you already have DepotDownloader and it handles downloading in the same way. It sounds like your credentials are wrong. Do you have spaces in your password by any chance? You can test what values are being passed in by echoing the variables after they have been set. Eg

STEAM_USERNAME=xxx
STEAM_PASSWORD=xxx
DOWNLOAD_PATH=~/Downloads/doom_downpatch_files

echo $STEAM_USERNAME
echo $STEAM_PASSWORD

That would let you ensure the correct values are being passed into the depotdownloader

Is anyone else getting errors downloading?

Encountered unexpected error downloading chunk 2f324f99fb0bb102d90a2dbad1d0c5f137dc77ce: The operation was canceled.

Is anyone else getting errors downloading?

Encountered unexpected error downloading chunk 2f324f99fb0bb102d90a2dbad1d0c5f137dc77ce: The operation was canceled.

This happened many times for me, but the download continued, and finished.

@btegs, removing the pinned_libs_* folders prompts Steam to regenerate those folders the next time Steam is started (this is literally what I said previously). The folder's contents is the result of comparing the system libraries to the Steam runtime variants and pinning the Steam runtime variant if it is newer than the host system.
Steam prioritizes libraries in the following order: Pinned libraries > Host system > Steam runtime > ld.so.conf

Deleted those folders and were recreated once starting Steam. I checked the directory and they were symlinking to a 1.2.135 version of Vulkan. cool.

Then I load up a random game with Proton 5.0-6 with the DXVK hud set to 1 under Ubuntu 19.10. It shows up as Mesa 20.0.99 (using the bleeding edge git version from https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers for my RX 580. Shows Vulkan 1.2.128 for my Vulkan version. I obviously cannot start DOOM Eternal either.

What is going on and what steps are missing?

NOTE: I found an Ubuntu repo at https://packages.lunarg.com/ which gives me an updated libvulkan1 and libvulkan1:i386 without affecting my current Mesa. 1.2.135 is installed, but whenever I try a game on Steam or using GameHub with a GOG game, it is still at 1.2.128. I have no clue where this version of Vulkan is coming from!

@btegs could you help to be more specific about your issue, here I also meet can not launch Doom Eternal under Ubuntu 20.04. after the latest update of game, when launch the game, opens the system tray of wine, then closes abruptly. but I remember it can launch before the latest update.

@btegs, the vulkan version on the HUD is just what's reported in /usr/share/vulkan/icd.d/radeon_icd.x86_64.json. It has nothing to do with launching the game, and the game doesn't check that file. If you have the latest libvulkan, or you're using the Steam runtime, you have 1.2.135. Look for yourself, open /usr/share/vulkan/icd.d/radeon_icd_x86_64.json in nano or vim or whatever, and you'll see 1.2.128, change it to 135 and launch some game with it, you'll see it says 1.2.135. It has no bearing whatsoever on being able to launch the game.

I've padded out my existing script while waiting for the files to download. It handles the DepotDownloader part but not yet the copy stage as I am not that far yet. It can be found here: https://github.com/lpww/doomgrader

@giacomo-porro I don't think my extended script would help as you already have DepotDownloader and it handles downloading in the same way. It sounds like your credentials are wrong. Do you have spaces in your password by any chance? You can test what values are being passed in by echoing the variables after they have been set. Eg

STEAM_USERNAME=xxx
STEAM_PASSWORD=xxx
DOWNLOAD_PATH=~/Downloads/doom_downpatch_files

echo $STEAM_USERNAME
echo $STEAM_PASSWORD

That would let you ensure the correct values are being passed into the depotdownloader

Thanks for the reply, but no, there are no spaces in my password and the credentials are right since the out put of the command states that it did succeeded in logging in before giving me the error...this is the complete output

Connecting to Steam3... Done!
Logging 'myusername' into Steam3... Done!
Using Steam3 suggested CellID: 184
Got 163 licenses for account!
Got session token!
Accepted new login key for account myusername
Got AppInfo for 782330
Using app branch: 'Public'.
Got depot key for 782332 result: OK
Downloading depot 782332 - Windows Executable
Downloading depot manifest...Got CDN auth token for ctr-10075-eu-it.steam-content-dnld-1.qwilted-cds.cqloud.com result: Fail (expires 1/1/1970 12:00:00 AM)
Disconnected from Steam

I guess I'm just unlucky at this point :D

That 1/1/1970 expiration looks like the Unix Epoch bug.... what?? That
expiration date is obviously related to the issue, because mine would say
an actual correct date and time, like "expires 5/17/2020 something
something AM/PM"

@giacomo-porro I'm guessing you replaced your actual username with 'myusername' in those logs?

If so, I still think this could be an issue with your password. Does it have any other special characters? Things like ', ", {, }, \, |, $, #, etc could be causing issues with the code. You could try wrapping your password in single quotes eg STEAM_PASSWORD='xxx'. If that doesn't work you could try temporarily changing your password to remove the special characters.

Another idea I had was that it doesn't look like you have Steam Guard enabled (you didn't get prompted for a second factor in the logs). I'm not sure but it may be required for DepotDownloader. It's definitely a good idea to enable it, especially as you seem to have a lot of games in your Steam library.

Another possibility is that the issue is the server you are connecting to. If you have access to a VPN, you could try connecting to a different country. This would increase the download time. This seems less likely so if you don't have access to a VPN then don't worry about it.

Update: I just had another thought, you should probably try to debug this issue by directly calling DepotDownloader first, to simplify things and rule out any issues from the script. Eg

./depotdownloader -app 782330 -depot 782332 -manifest 4641765937586464647 -username "steam-user" -password "steam-password" -remember-password -dir "path/to/downloads"

The download took forever (6-7 hours) but I was able to get the downgraded game up and running last night! I've updated my script to also copy the downgraded games files to the steam directory, so it's now a complete solution for downgrading: https://github.com/lpww/doomgrader

@lpww I don't think it's a password issue, because I typed my password wrong the first time I tried, and it said "incorrect password," not a failure with the token. But I guess it's possible.

Ah, ok. I'm not sure then :(

@giacomo-porro I'm guessing you replaced your actual username with 'myusername' in those logs?
Yes, exactly

If so, I still think this could be an issue with your password. Does it have any other special characters? Things like ', ", {, }, \, |, $, #, etc could be causing issues with the code. You could try wrapping your password in single quotes eg STEAM_PASSWORD='xxx'. If that doesn't work you could try temporarily changing your password to remove the special characters.

I tried and the issue persisted

Another idea I had was that it doesn't look like you have Steam Guard enabled (you didn't get prompted for a second factor in the logs). I'm not sure but it may be required for DepotDownloader. It's definitely a good idea to enable it, especially as you seem to have a lot of games in your Steam library.

I actually have it enabled, it asked for the verification code only the first time though, the log I posted was for a subsequent request I tried

Another possibility is that the issue is the server you are connecting to. If you have access to a VPN, you could try connecting to a different country. This would increase the download time. This seems less likely so if you don't have access to a VPN then don't worry about it.

Update: I just had another thought, you should probably try to debug this issue by directly calling DepotDownloader first, to simplify things and rule out any issues from the script. Eg

./depotdownloader -app 782330 -depot 782332 -manifest 4641765937586464647 -username "steam-user" -password "steam-password" -remember-password -dir "path/to/downloads"

I already tried also this and I still get the same error, I guess I'll have to wait then

Prerequisites

1. Install .NET Core. More details here. You need to add this to your path after installing. I added PATH=$PATH:~/.dotnet/tools to the end of my ~/.profile
2. Follow the directions to download and extract DepotDownloader from the Google doc

Download the downgraded files

I wrapped the download instructions in a script. You will need to make it executable and run it from the folder your extracted DepotDownloader into

#!/usr/bin/env bash

STEAM_USERNAME=xxx
STEAM_PASSWORD=xxx
DOWNLOAD_PATH=~/Downloads/doom_downpatch_files

./depotdownloader -app 782330 -depot 782332 -manifest 4641765937586464647 -username "$STEAM_USERNAME" -password "$STEAM_PASSWORD" -remember-password -dir "$DOWNLOAD_PATH"
./depotdownloader -app 782330 -depot 782333 -manifest 4686311672633195957 -username "$STEAM_USERNAME" -password "$STEAM_PASSWORD" -remember-password -dir "$DOWNLOAD_PATH"
./depotdownloader -app 782330 -depot 782334 -manifest 2624212357815850298 -username "$STEAM_USERNAME" -password "$STEAM_PASSWORD" -remember-password -dir "$DOWNLOAD_PATH"
./depotdownloader -app 782330 -depot 782335 -manifest 8671913471625122045 -username "$STEAM_USERNAME" -password "$STEAM_PASSWORD" -remember-password -dir "$DOWNLOAD_PATH"
./depotdownloader -app 782330 -depot 782336 -manifest 4248922069342282231 -username "$STEAM_USERNAME" -password "$STEAM_PASSWORD" -remember-password -dir "$DOWNLOAD_PATH"
./depotdownloader -app 782330 -depot 782339 -manifest 8937962102049582968 -username "$STEAM_USERNAME" -password "$STEAM_PASSWORD" -remember-password -dir "$DOWNLOAD_PATH"

Copy downgraded files to Steam

...coming soon when I get this far

I tried the commands and all I get is a fail on the authentication token

Got session token!
Got AppInfo for 782330
Using app branch: 'Public'.
Got depot key for 782332 result: OK
Downloading depot 782332 - Windows Executable
Downloading depot manifest...Got CDN auth token for ctr-10075-eu-it.steam-content-dnld-1.qwilted-cds.cqloud.com result: Fail (expires 1/1/1970 12:00:00 AM)
Disconnected from Steam

Archive: depotdownloader_2.3.4.zip
replace depotdownloader? [y]es, [n]o, [A]ll, [N]one, [r]ename: A
extracting: depotdownloader
extracting: depotdownloader.bat
inflating: DepotDownloader.deps.json
inflating: DepotDownloader.dll
inflating: DepotDownloader.dll.config
inflating: DepotDownloader.pdb
inflating: DepotDownloader.runtimeconfig.json
inflating: LICENSE
inflating: protobuf-net.dll
inflating: README.md
inflating: SteamKit2.dll
inflating: SteamKit2.pdb
inflating: System.Reflection.DispatchProxy.dll
inflating: System.Security.Principal.Windows.dll
inflating: System.ServiceModel.dll
inflating: System.ServiceModel.Primitives.dll
No usable version of the libssl was found
./depotdownloader: riga 1: 6171 Annullato dotnet DepotDownloader.dll "$@"

I got this problem ... in my gentoo box there is only openssl ... :(
I'm scared... why I have updated the game :(

I suspect Steam simply won't allow downloading of older files. If one thinks about it it's understandable. The publisher don't want "cheatable" versions of the game to be out there.

Unless they changed something overnight, they do allow it. Multiple people in this thread have downloaded the old games files from Steam and are running the game on Linux. I downloaded them yesterday and have been playing the game today

Hello everybody, friendly note that using a third party depot downloader, older versions of the game, and the troubleshooting involved in using that tool is off topic here, however, given the current state of the game I'm not going to step in right now.

Just be aware that the troubleshooting should probably be done on some other medium and the entirety of the current digression will be hidden as off-topic if/when the situation improves.

I hope that proton will by pass this proton issue soon as possible...

From techraptor.net interview:
MG: We've been tracking the Proton issue immediately after launch and are committed to delivering a fix soon. This isn't a request coming to us from a publisher or anything like that - we genuinely respect such an enthusiast community and regret introducing this incompatibility on day 1.

@mgreshis is there any link for a progress update or anything like that? How would we know if it's ready to test? If you'll need betatesters, I'm sure lots of people will be keen to try

From techraptor.net interview:
MG: We've been tracking the Proton issue immediately after launch and are committed to delivering a fix soon. This isn't a request coming to us from a publisher or anything like that - we genuinely respect such an enthusiast community and regret introducing this incompatibility on day 1.

@mgreshis is there any link for a progress update or anything like that? How would we know if it's ready to test? If you'll need betatesters, I'm sure lots of people will be keen to try

Further to this - is anything about a fix likely to come from denuvo's side? Or are you expecting heavy lifting from wine/proton to simply implement missing features that you need?

Call me sceptical, but its rare for a company to modify their product for an unsupported use case

From techraptor.net interview:
MG: We've been tracking the Proton issue immediately after launch and are committed to delivering a fix soon. This isn't a request coming to us from a publisher or anything like that - we genuinely respect such an enthusiast community and regret introducing this incompatibility on day 1.

@mgreshis is there any link for a progress update or anything like that? How would we know if it's ready to test? If you'll need betatesters, I'm sure lots of people will be keen to try

@mgreshis me either, if need some betatesters

From techraptor.net interview:
MG: We've been tracking the Proton issue immediately after launch and are committed to delivering a fix soon. This isn't a request coming to us from a publisher or anything like that - we genuinely respect such an enthusiast community and regret introducing this incompatibility on day 1.

@mgreshis is there any link for a progress update or anything like that? How would we know if it's ready to test? If you'll need betatesters, I'm sure lots of people will be keen to try

@mgreshis me either, if need some betatesters

From techraptor.net interview:
MG: We've been tracking the Proton issue immediately after launch and are committed to delivering a fix soon. This isn't a request coming to us from a publisher or anything like that - we genuinely respect such an enthusiast community and regret introducing this incompatibility on day 1.

@mgreshis is there any link for a progress update or anything like that? How would we know if it's ready to test? If you'll need betatesters, I'm sure lots of people will be keen to try

@mgreshis me either, if need some betatesters

Guys, stop tagging @mgreshis and asking questions. That article used initials instead of actual names for a reason, and there's not even any confirmation that they're the same person, at any rate, this is all a completely brand new and unforeseen issue, and asking "Denuvo" employees questions about beta testing fixes from them is objectively not what this thread is for. @kisak-valve has already said as much even for comments about ACTUALLY getting the game to run, but still outside the scope of this page, let alone begging someone who MIGHT work for Denuvo to beta-test something that doesn't exist. Seriously, it has no place here, and numerous people have done it. There's no reason to post "+1 me too!" over and over again, if they need us they'll surely ask, so stop.

Guys, stop tagging @mgreshis and asking questions. That article used initials instead of actual names for a reason, and there's not even any confirmation that they're the same person...

@gardotd426 sorry, but I disagree - the interview actually mentioned the name directly - "_Before we published this article, we emailed both Bethesda and Iredeto for their comments. Michail Greshishchev, Product Owner at Denuvo Anti-Cheat, has responded. Here is their response in full_".

The quote was posted from a github account with identical first and family names and with the same photo as in the linkedin profile, so it's either the man himself, or a very weird coincidence.

In any case, they have mentioned that they monitor the problem, that means they might be reading this exact issue. This is the issue where Doom Eternal compatibility with Proton is being discussed, so I think it's OK to ask for a progress update or to offer help with beta testing.

Also, please stop self-moderating the issue, you're not a Valve employee or a contributor to this repository, I don't think you have any ground to tell others what to do.

@mtb-xt Valve employees have asked numerous times for you to keep these discussions off of this thread. But I guess if you all refuse to listen to them, you're not going to listen to me either.

Valve employees have asked numerous times for you to keep these discussions off of this thread.

I only saw them mentioning downgrading will be considered off-topic. But anti-cheat is responsible for breaking current version of the game. So I, myself, would consider all info about the anti-cheat getting a Linux compatibility to be relevant. Maybe I missed something?

Valve employees have asked numerous times for you to keep these discussions off of this thread.

I only saw them mentioning _downgrading_ will be considered off-topic. But anti-cheat is responsible for breaking current version of the game. So I, myself, would consider all info about the anti-cheat getting a Linux compatibility to be relevant. Maybe I missed something?

I guess, they will add an option like -no-dac which disables DAC, multiplayer and invasions together. Compatibility of the kernel-level anti-cheat on Linux looks like a joke. Steam on Linux runs in userspace without root privileges, so it would be a big security hole to install a proprietary kernel-level driver for user telemetry.

Has anybody else noticed some weird graphical artifacts in game? With the Heavy Cannon + Micro Missiles, I get an absolute ton of green bars showing up on my display (to the point where it's unplayable). It's definitely NOT my GPU, as it's only with this certain weapon, and it doesn't happen on Windows.

I had a similar but not identical issue. However, that was on other things, not just heavy canon/micro missiles. And it was absolutely an graphics driver issue: Switching my Vulkan implementation fixed it.

@jjbarr Out of curiosity, are you talking about AMD's Vulkan implem/loader? I wasn't super clear about it but I'm using the proprietary NVIDIA driver on Void (440.82)

The loader is the same across implementations, but I'm using AMD, yeah.

You might be experiencing a different issue, but if it is a driver problem that's not great.

Archive: depotdownloader_2.3.4.zip
replace depotdownloader? [y]es, [n]o, [A]ll, [N]one, [r]ename: A
extracting: depotdownloader
extracting: depotdownloader.bat
inflating: DepotDownloader.deps.json
inflating: DepotDownloader.dll
inflating: DepotDownloader.dll.config
inflating: DepotDownloader.pdb
inflating: DepotDownloader.runtimeconfig.json
inflating: LICENSE
inflating: protobuf-net.dll
inflating: README.md
inflating: SteamKit2.dll
inflating: SteamKit2.pdb
inflating: System.Reflection.DispatchProxy.dll
inflating: System.Security.Principal.Windows.dll
inflating: System.ServiceModel.dll
inflating: System.ServiceModel.Primitives.dll
No usable version of the libssl was found
./depotdownloader: riga 1: 6171 Annullato dotnet DepotDownloader.dll "$@"

I got this problem ... in my gentoo box there is only openssl ... :(
I'm scared... why I have updated the game :(

@dylanmc1975 doomgrader has switched from dotnet to mono: https://github.com/lpww/doomgrader/pull/2 It seems mono doesn't require libssl. You can try the script again.

@hatf0 I had artifacts in strange colors for blood and other particles. The problem went away for me after resetting the ingame graphics settings. I'm guessing the artifacts I was seeing were caused by a certain combination of custom settings.

Compatibility of the kernel-level anti-cheat on Linux looks like a joke. Steam on Linux runs in userspace without root privileges, so it would be a big security hole to install a proprietary kernel-level driver for user telemetry.

I didn't know about this until recently, but it seems there is some compatibility with kernel-drivers in Wine already (I think it's emulated and doesn't have same access as real Linux kernel stuff, but I am not sure) and some might be worked on in the future when/if some feature will get added into Linux kernel. Or at least that seems to me from https://bugs.winehq.org/show_bug.cgi?id=37355. But I know almost nothing about Wine, win32 nor Linux kernel, so I may have misunderstood. (Note: That bug report is not specifically about DAC, just about kernel drivers for other anti-cheats in Wine.)

On 5/15/20 12:31 AM, Joshua Barrett wrote:
>

As satisfying as that may be, I don't think it will actually /change/
anything. A few people crying in outrage in a periphery demographic
that Bethesda and id quite frankly probably don't /care/ about isn't
going to reverse a decision that was likely made quite a while ago.

And, y'know. An outpouring of bile isn't exactly endearing...

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-628919829,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AEMFAGPQXMRWMBBKYTPS45DRRRWM5ANCNFSM4MI6DHIA.

I would like to amplify this quote, "An outpouring of bile isn't exactly
endearing..."

Especially for those who were not around 20+ years ago, right around the release
of the original Doom II, John Carmack of Id Software was the face of the
"always release Linux binaries" policy of Id Software back then. Their
policy was that you bought the game at retail and then downloaded the
official Linux UI wrapper directly from their website.

We loved it. But a handful of trolls and troublemakers decided that
making us download binaries for a 'large game for its day' via 56k
modems was an insult they couldn't tolerate. So they worked themselves
into a self-righteous frenzy on a forum just like this (which I read in
dismay in real-time since I was a member), and then they posted links
for Carmack and Id Support asking for everyone to "email bomb" them to
express their outrage, which they did.

The result was a few days later, Carmack gave an interview to either PC
Magazine or one of the tech mags of the time where he said to
paraphrase, 'I thought I was doing a good thing supporting Linux. Now my
inbox is full of flame from crybabies. Never again. It's not worth the
grief.'

All these years later, Proton is the best we will do with Doom because
of that incident. Flaming Bethesda will probably get nothing more than a
"I told you so" somewhere in their headquarters. So please, if you
contact them be polite.

On 5/15/20 12:31 AM, Joshua Barrett wrote: As satisfying as that may be, I don't think it will actually /change/ anything. A few people crying in outrage in a periphery demographic that Bethesda and id quite frankly probably don't /care/ about isn't going to reverse a decision that was likely made quite a while ago. And, y'know. An outpouring of bile isn't exactly endearing... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3773 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEMFAGPQXMRWMBBKYTPS45DRRRWM5ANCNFSM4MI6DHIA.
I would like to amplify this quote, "An outpouring of bile isn't exactly endearing..." Especially for those not around 20+ years ago, right around the release of the original Doom II, John Carmack of Id Software was the face of the "always release Linux binaries" policy of Id Software back then. Their policy was that you bought the game at retail and then downloaded the official Linux UI wrapper directly from their website. We loved it. But a handful of trolls and troublemakers decided that making us download binaries for a 'large game for its day' via 56k modems was an insult they couldn't tolerate. So they worked themselves into a self-righteous frenzy on a forum just like this (which I read in dismay in real-time since I was a member), and then they posted links for Carmack and Id Support asking for everyone to "email bomb" them to express their outrage, which they did. The result was a few days later, Carmack gave an interview to either PC Magazine or one of the tech mags of the time where he said to paraphrase, 'I thought I was doing a good thing supporting Linux. Now my inbox is full of flame from crybabies. Never again. It's not worth the grief.' All these years later, Proton is the best we will do with Doom because of that incident. Flaming Bethesda will probably get nothing more than a "I told you so" somewhere in their headquarters. So please, if you contact them be polite.

Unfortunately, this community seems absolutely dead-set on the type of behavior you describe as the defualt first response every single time anything like this happens. It happened with Rocket League, it's happening now. And no matter what anyone tries to tell them, it's all "we can't allow them to get away with this stuff, I say we file a class action lawsuit!" or other similarly ridiculous things, and then what happens? Nothing, "they" (publisher/whomever) DO get away with whatever they've done, only now there are a few hundred more people in the industry that absolutely DESPISE the Linux community and will refuse to ever go out of their way to help us ever again.

We absolutely do not have the market share to be acting like that. It will guarantee this kind of stuff continues more than it'll help anything.

Unfortunately, this community seems absolutely dead-set on the type of behavior you describe as the defualt first response every single time anything like this happens. It happened with Rocket League, it's happening now. And no matter what anyone tries to tell them, it's all "we can't allow them to get away with this stuff, I say we file a class action lawsuit!" or other similarly ridiculous things, and then what happens? Nothing, "they" (publisher/whomever) DO get away with whatever they've done, only now there are a few hundred more people in the industry that absolutely DESPISE the Linux community and will refuse to ever go out of their way to help us ever again.

We absolutely do not have the market share to be acting like that. It will guarantee this kind of stuff continues more than it'll help anything.

Indeed. In fact I read a Q & A article on a gaming site a few months ago with the CEO of Epic Games about the prospects of bringing Fortnite to Linux. He never referenced market share as I recall but did talk in vague terms about the challenges inherent to that user space. What could he have meant I wonder? Then he said basically, 'We are considering but currently have no plans...etcetera, etcetera.'

The Linux community must basically gush with praise for any large company willing to take the risk, especially for those who do it well. And for god's sake, DO NOT EVER express disrespectful rage at a developer or especially the developer's boss! As you can see, that might affect the community for decades.

Yeah, but developers don't owe you anything, and starting a bug report with "how DARE you break this game under Linux" rather than "I'm a linux user, I understand that my system configuration isn't supported, but if you could provide any help I would be thankful" won't get you far.

We're off topic. Sorry Kisak.

It's OT, sure. But I think it needs to be said from time to time that having a keyboard in front of you doesn't give you the right to be abusive to creators. If only a couple of folks that read this consider for the first time the negative impact they might have, I would think that every developer would support it being said once in a blue moon. Most of these guys have never even heard of John Carmack.

I hope this is relevant. The executive producer Marty Stratton tells that the anti-cheat requirement will be removed in an upcoming update:
https://www.reddit.com/r/Doom/comments/gnjlo7/latest_information_on_update_1_anticheat/

I hope that means the update means there's a chance of this working with proton once again without too many workarounds.

I hope this is relevant. The executive producer Marty Stratton tells that the anti-cheat requirement will be removed in an upcoming update:
https://www.reddit.com/r/Doom/comments/gnjlo7/latest_information_on_update_1_anticheat/

I hope that means the update means there's a chance of this working with proton once again without too many workarounds.

Denuvo Anti-Cheat will have Proton support out-of-the-box for releases beyond DOOM: Eternal. Feel free to @ me directly with feedback once you had a chance to try it. I'm happy access is restored for you guys.

Awesome news overall. Can't wait to get back to playing (and finishing) the game.

@mgreshis

Denuvo Anti-Cheat will have Proton support out-of-the-box for releases beyond DOOM: Eternal. Feel free to @ me directly with feedback once you had a chance to try it.

Can you link to the relevant upstream patches to _wine_ that relate to this please?

@mgreshis does this mean the anti-cheat will automatically be disabled or did you implement compatibility for Wine?

looks promising, maybe even battlemode and invasion may work. Fingers crossed, and shotgun
cocked)

@mgreshis, I hope this is true. I don't know if you mean that there will also be a Ring 0 AC for Proton use, or whether it will just make an exception for Proton, but either way if this is true, it's monumental. This would be the first real client-side anti-cheat to work on Linux through Proton, and that's the biggest hurdle left for Linux gaming. This is huge, if it's true.

I hope this is relevant. The executive producer Marty Stratton tells that the anti-cheat requirement will be removed in an upcoming update:
https://www.reddit.com/r/Doom/comments/gnjlo7/latest_information_on_update_1_anticheat/
I hope that means the update means there's a chance of this working with proton once again without too many workarounds.

Denuvo Anti-Cheat will have Proton support out-of-the-box for releases beyond DOOM: Eternal. Feel free to @ me directly with feedback once you had a chance to try it. I'm happy access is restored for you guys.

@mgreshis That's fantastic news and I would love to know more about what this means or how it would work with Proton? Either way that's awesome, I'm sure many Linux gamers will appreciate it and take note, and will be hoping future Windows-only games protected by anticheat are protected by Denuvo Anti-Cheat.

If you wouldn't mind, could Denuvo make an announcement and let us know when the next Denuvo Anti-Cheat protected game comes out which includes this Proton support OOTB? I'd love to hear about it when it happens, I'd be keen to try it out and test it personally.

@mgreshis thanks for thinking about us.

If I could just provide some feedback - and this is applicable for Windows users as well - please do not provide anti-cheat solutions which run as _kernel 0_ level.
This precise reason is what triggered the whole community (Linux + Windows) and I'm not sure adding support for the former (Linux) would mitigate any of the feedback received so far.

Thanks again for supporting us.

@mgreshis would definitely like to see it cleared up if you mean DAT will work with Proton + Online or if you mean it will auto-detect to disable for offline play

@LiamDawe, it would seem that either he's mispeaking (or misleading), or it will include actual Proton support. Because Denuvo Anti Cheat won't just be for games that include a single player campaign. Most games with these types of anti-cheat are multiplayer only (Fortnite, Apex, Warzone, Valorant, Siege, etc.) So for the AC to support Proton it would have to mean actually supporting Proton. So either he misspoke, is misleading us, or he actually means what he says, which would by definition mean that it will actually support us. Any of which could be true, hopefully it's the latter.

EDIT: Typo.

@mgreshis This would be the first real client-side anti-cheat to work on Linux through Proton

Not true, you can run VAC and Warden Anticheat through proton no problem, the issue is this AC having a kernel driver, wine is written to handle usermode applications, not drivers, so if it's a usermode anticheat, supporting it is within the reach of the wine developers.

I hope this is relevant. The executive producer Marty Stratton tells that the anti-cheat requirement will be removed in an upcoming update:
https://www.reddit.com/r/Doom/comments/gnjlo7/latest_information_on_update_1_anticheat/
I hope that means the update means there's a chance of this working with proton once again without too many workarounds.

Denuvo Anti-Cheat will have Proton support out-of-the-box for releases beyond DOOM: Eternal. Feel free to @ me directly with feedback once you had a chance to try it. I'm happy access is restored for you guys.

How do you know exactly?

@BloodyIron the dude is literally a Denuvo employee, the same one that gave the interview posted earlier in the thread when all this first went down, and said that they were working on Proton support for DE and that it would come eventually (before iD decided to remove DAC completely).

@BloodyIron the dude is literally a Denuvo employee, the same one that gave the interview posted earlier in the thread when all this first went down, and said that they were working on Proton support for DE and that it would come eventually (before iD decided to remove DAC completely).

Ahh, well I just wanted to make sure it was a credible source is all. Thanks for clarifying! :)

@BloodyIron the dude is literally a Denuvo employee, the same one that gave the interview posted earlier in the thread when all this first went down, and said that they were working on Proton support for DE and that it would come eventually (before iD decided to remove DAC completely).

Don't get too excited, the EAC dev team originally said they were working on wine compatibility and went radio silent about it for a year and a half now.

@BloodyIron here's the article https://techraptor.net/gaming/news/doom-eternals-latest-update-breaks-game

Of course that's all now out of date, but just to provide the context.

@databoose EAC responding to requests by saying "we're working on it" is a completely different situation than a Denuvo employee literally volunteering to come here and say that ALL future DAC releases WILL support Proton OOTB on day one. Those aren't even remotely comparable.

@databoose EAC responding to requests by saying "we're working on it" is a completely different situation than a Denuvo employee literally volunteering to come here and say that ALL future DAC releases WILL support Proton OOTB on day one. Those aren't even remotely comparable.

I'm pretty sure "we're working on it" implies wine compatibility is planned, stop being disingenuous for the sake of argument, doesn't make you look credible.

@databoose what are you talking about.

Denuvo Anti-Cheat will have Proton support out-of-the-box for releases beyond DOOM: Eternal. Feel free to @ me directly with feedback once you had a chance to try it. I'm happy access is restored for you guys.

Where is that "we're working on it"? That's guarantee of support OOTB on day one, not "we're working on it."

I'm literally quoting his most recent statement, that's not disingenuous, you should read all facts of the matter before accusing others of being disingenuous when you're the one operating on outdated and since modified information.

@databoose what are you talking about.

Denuvo Anti-Cheat will have Proton support out-of-the-box for releases beyond DOOM: Eternal. Feel free to @ me directly with feedback once you had a chance to try it. I'm happy access is restored for you guys.

Where is that "we're working on it"? That's guarantee of support OOTB on day one, not "we're working on it."

One employee's words != the priorities of the entire company, it may be planned and worked on now but could be thrown out the window tommorow, don't be naive and think that just because one employee says it will happen that it will.

@databoose I'm not, obviously it's not 100 percent certain, because nothing is, especially in this industry. But that's not what you said. You were going off the original interview not even aware of the new statement, and now you're trying to twist it to also fit the new statement. I literally quoted him, and you're the one being disingenuous now.

Also, he's the Project Owner, he's not just some random. Still not a 100 percent certainty, but also more than just some rando saying it for the hell of it.

You claimed that this was the same as an EAC employee responding to requests by saying they were "working on" wine compatibility without a single actual definitive statement (no "WILL happen," no "ALL future releases," no "day one," nothing like that. Just "we're working on it). That's not even remotely the same thing as what we're getting here, and just because "nothing is certain" doesn't mean that these two situations are even kind of similar or that you can use one to judge the other. Right now, we have a guarantee that all future DAC releases will support Proton on day one. Until the first DAC release comes and that doesn't happen, or until we get a new statement that hedges on the original (or completely reverses it), that's the current situation. And I honestly find it hard to believe that the Project Owner for DAC would volunteer to come here and make such an unequivocal statement just for the hell of it without any concrete plans, proprietary software companies don't generally do such things, they're normally quite the opposite.

Also, there is a precedent with Denuvo the company, in that their DRM works perfectly fine with Proton now. There's a bug or two, like detecting tweaked configs as new launch attempts from different machines, and potentially kicking in the 24-hour waiting period, but it does work.

Hello @gardotd426, @databoose, regardless of intent, you're mostly arguing for the sake of argument.

What's needed right now is time and results. Please try to avoid filling this compatibility report with what's effectively noise and bickering.

Sure thing. This thread's gone to hell the last week (I even said what
you're saying right now, only to get responses of effectively "shut up"),
so I figured what the hay. But you're right.

>

You claimed that this was the same as an EAC employee responding to requests by saying they were "working on" wine compatibility without a single actual definitive statement

Multiple people have emailed EAC to receive the response that work was being done on it and can easily be searched online, at no point did they say it was a possibility or that it wasn't going to happen, they simply changed their minds and went radio silent.

If you consider an EAC employee saying it's being worked on to not be credible than it's kind of weird for you to also say that you think a DAC employee saying it's being worked on is credible.

Also, there is a precedent with Denuvo the company, in that their DRM works perfectly fine with Proton now.

At this point it's becoming pretty obvious that you have no idea what you're talking about, the denuvo DRM is an entirely seperate project from DAC.

If you want to be naive and get hyped for something that has only been said by one single employee go for it, but stop acting like this is anything more than an EAC employee saying they'd provide wine compatibility as well (even though multiple EAC employees have said it was going to happen).

Since this is an issue page i'll stop here but i'm tired of people regurgitating "wine eac compatibility is being worked on!!!" when it was abandoned a long time ago.

Hello @gardotd426, @databoose, regardless of intent, you're mostly arguing for the sake of argument.

What's needed right now is time and results. Please try to avoid filling this compatibility report with what's effectively noise and bickering.

proton_patches.zip

The attached work in progress patchset (on top of Proton 5.0.7) allowed me to start the game. I did not test it beyond the start screen yet. I hope that the game should work though, while that is unlikely for multiplayer.

Also, the chances are it will break on any DAC update.

Does this Proton patch allow installing and running the DAC driver or is it a bit more of a workaround to make the usermode side happy enough to start up in singleplayer?

@gofman, there won't be any more DAC updates, DAC is being removed from the game, so this patch won't be needed upon the next update. Apparently it's supposed to come within a week, and the game will work on Linux as it did before.

Does this Proton patch allow installing and running the DAC driver or is it a bit more of a workaround to make the usermode side happy enough to start up in singleplayer?

This is the former and it is confirmed working for now for single player. But it allows the driver to merely start and proceed through initial handshake sequence. The support for some facilities which are probably required to work in the "active" anticheat phase is just stubbed. I could not yet test multiplayer in DAC due to unrelated preexisting problem with multiplayer (which still fires now), but it doesn't look likely to me that it would work now.

There were some modifications of the patchset, so if anyone is interested in building and trying this I can provide an updated one.

Proton does have the framework for running kernel model drivers, and some anti-cheat drivers do work under it. The patchset adds some missing bits and pieces, stubs for some kernel API functions which are very hard to implement and other workarounds as well. However, drivers in Proton run in user mode on Linux, and certain things which kernel drivers do are just emulated. There are (and will always be) the ways the driver (or normal user space program as well) can detect that it is running under Proton and not under genuine Windows. So ultimately in the end the possibility to support for the given anti-cheat solution in Proton depends on whether the anti-cheat is willing (or can tolerate) running this way, or instead denies that.

@gofman That sounds great. Can you provide the updated patchset? Or maybe you have an updated GitHub fork with your updates?
(If possible, can you maybe provide some very brief instructions of how I would install it? I never did it. I would just git clone Proton 5.0.7, then apply your patches, then make install, and that's all, then it should work?)

(If possible, can you maybe provide some very brief instructions of how I would install it? I never did it. I would just git clone Proton 5.0.7, then apply your patches, then make install, and that's all, then it should work?)

Building Proton make take some time if you are doing that for the first time. I guess the easiest way is to follow the instructions here:
https://github.com/ValveSoftware/Proton

Basically you need to clone the sources, switch to correct branch (proton_5.0-next), apply my patches in 'wine' submodule' (you will need to make sure everything is applied cleanly) and follow the instructions in 'Building' section of Proton github page. If your build VM (see 'Set up the build environment') gets configured right, building and installing Proton to your local steam installation is as easy as 'make install' in Proton source tree root.

proton_patches.zip

@albertz, I wouldn't do it that way. It's far, far too complicated if you've never done it before. There is a much easier way, and that's using @tk-glitch's tkg build.

Just clone his repo, https://github.com/frogging-family/wine-tkg-git (it contains both wine and proton directories) and cd into wine-tkg-git/proton-tkg/. Then you'll just want to edit the configuration options to your liking (stuff like enabling certain fixes, tkg's proton builds include a ton of patches and workarounds, he was the first one to get a custom proton to get Doom Eternal up and running in the first place, his builds are very similar to Glorious Eggroll's, and they're what Lutris bases their wine builds on). Once you edit that, you just need to copy the patch into the proton-tkg directory and give it the .mypatch extension, and then run ./proton-tkg.sh. You'll get prompted during the build asking if you want to apply the patch, hit y, and that's it. His script automatically installs the proton build into the compatibilitytools.d/ directory and everything. It's far, far easier than building proton the traditional way.

That said, building proton requires a lot of dependencies you might not be aware of, regardless of which method you choose. So make sure you have everything you need.

That said again, I wouldn't even bother. It's much easier to just downpatch the game like most of the people here have done (including me), especially when DAC is being removed in a matter of days anyway.

@albertz, I wouldn't do it that way. It's far, far too complicated if you've never done it before. There is a much easier way, and that's using @Tk-Glitch's tkg build.

Just clone his repo, https://github.com/frogging-family/wine-tkg-git (it contains both wine and proton directories) and cd into wine-tkg-git/proton-tkg/. Then you'll just want to edit the configuration options to your liking (stuff like enabling certain fixes, tkg's proton builds include a ton of patches and workarounds, he was the first one to get a custom proton to get Doom Eternal up and running in the first place, his builds are very similar to Glorious Eggroll's, and they're what Lutris bases their wine builds on). Once you edit that, you just need to copy the patch into the proton-tkg directory and give it the .mypatch extension, and then run ./proton-tkg.sh. You'll get prompted during the build asking if you want to apply the patch, hit y, and that's it. His script automatically installs the proton build into the compatibilitytools.d/ directory and everything. It's far, far easier than building proton the traditional way.

That said, building proton requires a lot of dependencies you might not be aware of, regardless of which method you choose. So make sure you have everything you need.

That said again, I wouldn't even bother. It's much easier to just downpatch the game like most of the people here have done (including me), especially when DAC is being removed in a matter of days anyway.

I have done as you said, but I'm not able to get this work.
Compile was ok, but the game don't start.
I placed the proton patches into the proton-tkg directory, the only thing that I have not done is give the mypatch exension, but during the command I've seen that the patches were applied

Folks, you are wasting your time trying to do it with Tkg version. My patchset is based upon proton5.0.7-next, it won't even apply correctly on top of Tkg version. I have another version upon Wine-Staging, but I am not up to rebasing that for every custom build, that is not exactly trivial. Also, building with mainstream Proton is easier regardless if you use recommended way with Vagrant and Steam runtime.

Folks, you are wasting your time trying to do it with Tkg version. My patchset is based upon proton5.0.7-next, it won't even apply correctly on top of Tkg version. I have another version upon Wine-Staging, but I am not up to rebasing that for every custom build, that is not exactly trivial. Also, building with mainstream Proton is easier regardless if you use recommended way with Vagrant and Steam runtime.

Can you tell me how I have to apply the patches?

I was about to say, upstream/staging won't cut it. You can build stock proton with the -tkg build system but you need to enable a couple options to do it, it's not the default behavior.

@gofman I would definitely add an option to enable a 5.9-staging version of the patchset if that's something you'd be okay with. Any needed adjustment would be on me, of course.

I've read how to build proton.
Too difficult for me, I have to wait Id's denuvo remove :)

patches_staging.zip

@Tk-Glitch Sure, why not if you are up for that. Those patches are not in Staging itself, it is rather long patchset and given the Doom's rollback is expected I don't think maintaining it in Staging worth it. I am hoping to upstream most of that sooner or later though. Just in case you would like to make your build with those patches, I am attaching the version based on top on latest (5.9 release) Staging, it was working for me today.

I was about to say, upstream/staging won't cut it. You can build stock proton with the -tkg build system but you need to enable a couple options to do it, it's not the default behavior.

@gofman I would definitely add an option to enable a 5.9-staging version of the patchset if that's something you'd be okay with. Any needed adjustment would be on me, of course.

Can you tell us the options to enable ?
I've built a proton version with @Tk-Glitch ... maybe with the right options the game may will work for me..

@gofman Thanks! I'll add the patchset to the "community-patches" with all due credits. It'll be fully optional/non-default so folks who want it will have to mean it.

Edit: the patchset you sent contains multiple patches already mainlined/staged in 5.9. Is it expected? It also doesn't apply cleanly to staging outside of the already merged patches.
Edit2: Yeah the patchset is clearly outdated and looks more like a 5.8 version :D

@dylanmc1975 Considering what you said earlier, I can tell the patches weren't applied if you didn't switch the extension to .mypatch. You probably saw the staging patches getting applied. That being said, I'll add Paul's patchset as an option (please give me a few minutes to do that and review) so you can enable it by adding gofman_dac.mypatch to the _community_patches array in your proton-tkg.cfg.

Edit: Since I have to do a cleanup pass and rebase the patchset, it might will take me a while :frog:

I have renamed the patches, but nothing seems to work :(
But I get the error with the DRM free binary, with the original downloaded binary no errors but it doesen't start.

I have moved the renamed patches in myhome/wine-tkg-git-master/proton-tkg/proton-tkg-userpatches/
I've launch proton-tkg.sh but I'm not able to see if the patches were applied..

@dylanmc yes you are able. You will be prompted if you want to run the patches during build time. The build process starts, all of the automatic (non-user) patches get applied, and then you will get a yes or no prompt asking whether you really want to apply whichever userpatches you've selected, and it will display the name of the patch files.

And it seems the patches aren't working at the moment, because there are some already-upstreamed patches included, which the build won't allow for, if it detects that or if a patch fails to apply for any other reason, the build immediately aborts as failed. You'll have to wait until they get the patches sorted out to apply correctly, but even then, no one's really going to be able to help you if you don't post logs. You're just telling us "Well i don't know if it worked" when the log clearly shows whether it worked or whether you even have the patch in the right place with the right extension name, etc.

How I can enable logs?

What? You don't, I'm talking about the output of the build. Like the terminal output when you run the proton-tkg.sh script.

I have fount the way to use the patches, the script ask me to apply them.
But I got errors

`` -> Applying your own plain-wine patch /home/luca/Scaricati/wine-tkg-git-master/wine-tkg-git/0001-ntdll-Fill-NumberOfPhysicalPages-field-in-user-share.mypatch
->
-> ######################################################
patching file dlls/ntdll/tests/virtual.c
Reversed (or previously applied) patch detected! Skipping patch.
4 out of 4 hunks ignored -- saving rejects to file dlls/ntdll/tests/virtual.c.rej
patching file dlls/ntdll/thread.c
Hunk #1 succeeded at 357 (offset 131 lines).
Hunk #2 FAILED at 326.
1 out of 2 hunks FAILED -- saving rejects to file dlls/ntdll/thread.c.rej
-> Removed BIG_UGLY_FROGMINER - Ribbit
-> Removed Proton-tkg token - Valve Ribbit
-> exit cleanup done

And it seems the patches aren't working at the moment, because there are some already-upstreamed patches included, which the build won't allow for, if it detects that or if a patch fails to apply for any other reason, the build immediately aborts as failed. You'll have to wait until they get the patches sorted out to apply correctly, but even then, no one's really going to be able to help you if you don't post logs. You're just telling us "Well i don't know if it worked" when the log clearly shows whether it worked or whether you even have the patch in the right place with the right extension name, etc.

I've read this.. I have to wait now.

@Tk-Glitch

Edit: the patchset you sent contains multiple patches already mainlined/staged in 5.9. Is it expected? It also doesn't apply cleanly to staging outside of the already merged patches.
Edit2: Yeah the patchset is clearly outdated and looks more like a 5.8 version :D

Are you sure you took the patches_staging.zip from my latest comment (https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-633114122) and not the earlier one for proton 5.0.7-next? I redownloaded what I posted and I see clearly the patches which which I have applied and working on Staging 5.9. In case I am missing something obvious and screwed up something badly can you please link some patch from patches_staging.zip which is outdated or already upstreamed?

@gofman I redownloaded the file, and noticed the content was very different than what I had in my output folder from yesterday. It looks like I mistakenly merged both dirs, giving me huge headaches in the process. The patchset is, indeed, applying fine on 5.9-staging. I apologize for the noise, and thank you again for the patchset and all your work!

The patches is applying fine, but the games still don't start at all :(
With the downloaded steam binary, and also with the drm free version :(

There were reasons I suggested to use Proton 5.0.7-next as a base. While it can definitely work in different builds I am afraid it might be a more involved process. But since here a people who seem to know better how this should be done I am sure they can provide required troubleshooting.

@dylanmc1975 again, we can't help if you don't provide logs.

Add PROTON_LOG=1 to the launch options for the game in Steam. When it crashes, you'll get a steam-782330.log file in your home directory. Upload it.

Also, you need to tell us what launch options you're using in the first place.

I mean, the game is going to work any day now anyway, but still....

steam-782330.log

@dylanmc1975 please don't delete comments. The fact that you're not using any launch options might be the issue. Are you using an AMD or NVidia GPU? Set the launch options thus:

PROTON_LOG=1 PROTON_NO_ESYNC=1 %command% +in_terminal 1 +com_skipIntroVideo 1 +com_skipKeyPressOnLoadScreens 1 +com_skipSignInManager 1

If that doesn't help, if you're using AMD I would suggest using the AMDVLK driver instead of RADV, so you'd need to have AMDVLK installed and add it to the launch options, so your launch options would look like this:

VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/amd_icd64.json:/usr/share/vulkan/icd.d/amd_icd32.json PROTON_LOG=1 PROTON_NO_ESYNC=1 %command% +in_terminal 1 +com_skipIntroVideo 1 +com_skipKeyPressOnLoadScreens 1 +com_skipSignInManager 1

@dylanmc1975 also, is there some reason you're so insistent on using these patches instead of just downpatching the game like everyone else has done in order to play? That method is known to work, so I'm confused why you insist on trying to do it this way, which absolutely isn't guaranteed to work at all.

@dylanmc1975 also, is there some reason you're so insistent on using these patches instead of just downpatching the game like everyone else has done in order to play? That method is known to work, so I'm confused why you insist on trying to do it this way, which absolutely isn't guaranteed to work at all.

The only reason Is that I wad not able ti downgrade the game.
Later I try your Launch options and maybe I try Again downgrade

PROTON_LOG=1 PROTON_NO_ESYNC=1 %command% +in_terminal 1 +com_skipIntroVideo 1 +com_skipKeyPressOnLoadScreens 1 +com_skipSignInManager 1

With this launch options, the game launches, but crash on loading slot game cause denuvo.
I will re-try to downgrade the game.

Just FYI you'll probably always need those launch options, I always have.

On Sun, May 24, 2020 at 2:37 PM dylanmc1975 notifications@github.com
wrote:

PROTON_LOG=1 PROTON_NO_ESYNC=1 %command% +in_terminal 1
+com_skipIntroVideo 1 +com_skipKeyPressOnLoadScreens 1
+com_skipSignInManager 1

With this launch options, the game launches, but crash on loading slot
game cause denuvo.
I will re-try to downgrade the game.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-633274350,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM5Y332RLB2TJXTLVBXUQ23RTFSQFANCNFSM4MI6DHIA
.

I've tryed to start another game.
The games works, but not the slot I have allways used to play.

How important is +com_skipSignInManager 1? What exactly does it do? @dylanmc1975 Maybe that causes that saved games are not compatible?

Earlier I just used +com_skipIntroVideo 1 and nothing else, and that was fine. I had a Bethesda.net account and using that (logging in) just work fine.

@albertz Maybe.
But I hope not .. I will see when Id's will remove denuvo..

@albertz it's nothing to do with signing in with Bethesda account. I have always used that flag because that's what literally everyone said was needed, and I was always able to sign in with my Bethesda account. I don't know what sign-in manager it skips, but it's not that one.

And it doesn't do anything with saved games, at least it didn't before Denuvo (and doesn't now with the downpatched game), saved games are able to be loaded for me.

And it doesn't do anything with saved games, at least it didn't before Denuvo (and doesn't now with the downpatched game), saved games are able to be loaded for me.

I hope it's only a denuvo thing

@dylanmc1975 I remember a few people said their save slots got wiped post update, so I wonder if what you experienced is just a bug that was introduced in the update.

WTF.
I was close to finish the game..

Il dom 24 mag 2020, 23:22 James McClain notifications@github.com ha
scritto:

@dylanmc1975 https://github.com/dylanmc1975 I remember a few people
said their save slots got wiped post update, so I wonder if what you
experienced is just a bug that was introduced in the update.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-633302709,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIQDG5LRYZ6GQT2LFZ6MO3DRTGF2JANCNFSM4MI6DHIA
.

There might be an issue with saved games.
I lost my saved slots once when I changed from proton 5.6-GE-2 to native proton 5.0.6 and then again when I switched to 5.8-GE-1.

Game now runs perfectly after Update 1.1. No more Denuvo.

I'm seeing very low performance on RADV: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3054

@libcg just use one of the AMD vulkan drivers. vulkan-amdgpu-pro has the best performance, but if you don't want to use a proprietary driver then AMDVLK is almost as good (and much better than RADV), is open-source, and can live alongside RADV.

The Doom Eternal performance issue with RADV is a known issue. We are working on.

EDIT: removed the tag

@hakzsam Yeah, I know. I think you meant to tag @libcg. Makes zero sense for that to be a reply to me, since my comment is telling him to use AMDVLK and his was about RADV's poor performance.

Hi, my game crashes every time, a "loading screen" appears whenever and crashes at that point. This are my launch commands: PROTON_LOG=1 PROTON_NO_ESYNC=1 %command% +in_terminal 1 +com_skipIntroVideo 1 +com_skipKeyPressOnLoadScreens 1 +com_skipSignInManager 1
My steam.log is too big to upload here, and im new to github, so i dont know how to shrae it.
I wish you can help me and thanks!

Update: it only crashes during cutscenes, it gets stuck in a sudden loading screen, but i was able to play the first level without trouble.

@libcg just use one of the AMD vulkan drivers. vulkan-amdgpu-pro has the best performance, but if you don't want to use a proprietary driver then AMDVLK is almost as good (and much better than RADV), is open-source, and can live alongside RADV.

For me here on an RX480, radv+aco is better than both amdvlk and the closed-source amdvlk in the amdgpu-pro package. Both the min and max fps are higher and it's a serious difference. Using radv+llvm seems similar performance as amdvlk, so I'm thinking aco is what's causing the difference.

The difference in fps is seriously large. I just tried switching between the open amdvlk and radv with the same savegame and got this:

area | amdvlk | radv+aco
-|-|-
main menu | 77 fps | 105 fps
in-game | 56 fps | 67 fps

This is with mesa 20.2 and llvm 10.0.0 and amdvlk 2020.Q2.4. About the pro version of amdvlk, I remember it wasn't as good as radv when I tried it. I don't have it installed right now. Screenshots showing what those fps numbers are about are here:

https://imgur.com/a/9jFhO7P

Only problem I found with radv is that it needs RADV_DEBUG=zerovram to fix artifact issues that sometimes show up in particles.

Hi all,

New day, new bug. Whenever I play the game at a non-native resolution. I see weird square flickering artifacts in place of special effects. This doesn't happen at all when playing the game at my monitor's native resolution (either my laptop at 1080p or my external monitor at 4K).

Here's an example, the Archvile in the Battlemode training level. Look at the right hand: https://imgur.com/zI2kGxM . It almost looks like the flame textures are not mapped correctly to the quads that hold them.

System specs:

• Pop!_OS 20.04 (5.4.0-7634-generic)
• nVidia RTX 2070 Max-Q, driver version 440.82
• Vulkan version 1.2.140 (though I think Proton bundles its own version?)

I haven't been able to find this exact problem anywhere else.

Doom Eternal appears to freeze repeatedly when on a Paperspace V100 VM with everything on Ultra. It lets me play longer before it freezes on Ultra than it does on Nightmare. I used to be able to play through level 1 with everything on Nightmare, and it was working pretty well before the 1.1 Update after Doomgradering. I updated the nvidia drivers on the VM pretty recently but I'll try it again. Are there any instrucitons on a way to get crash logs from a frozen screen? So far I've had to manually kill the Steam process and restart it everytime.

I'll try to start Proton with PROTON_LOGS=1

Issue appears to be intermittent. I'll try to turn logging back on and catch it next time it happens.

Hello all, I have been trying to get this working on Linux Mint 19.3 since release day with no luck. Initially, on the main default Proton versions (5.0-4 to 5.0-7) it would seemingly install, then when loading it would pop up the id logo in the taskbar and then immediately crash. When using the Glorious Eggroll Proton versions (5.4-GE-3, 5.5-GE-1, 5.6-GE-2, 5.8-GE-2-MF) it puts up "processing vulkan shaders" and then "GPU driver error" dialog and list an older driver (337.88) that I wasn't actually running. Pressing play to bypass results in immediate crash (in older protons) or keeps the game listed as playing but doesn't load anything and has to be 'end process'ed. In both cases I used all the various launch options listed here and in the ProtonDB. (all my reports there are listed under taibhsear_1 in case you would like to see the exact details) I have updated both my nvidia drivers (through the nvidia ppa, to 440.82 for my GTX 1070) as well as updated vulkan drivers from the lunarg website since it wasn't included in the 440.82 driver for some reason. Steam info and vulkaninfo shows vulkan versions as 1.2.135 except for NVidia Optimus Layer as vulkan version 1.1.119 and Steam Pipeline Caching Layer and Steam Overlay Layer as vulkan version 1.1.73. Could this be a reason for it not starting? Steam info also shows "wrong ELF class" errors for steamoverlayvulkanlayer.so (listing vulkan version 1.1.119, driver 440.328.0) and libEGL.so.1. I've attempted a "steam --reset", deleting the pinned_libs, and deleting and reinstalling the game, as well as installing in a different partition, with no results. I have a 170MB steam log file with PROTON_LOGS=1 and can also share my steam info text if needed. Anyone have an idea of what to try next? Thanks!

Hi, I'm having problems running Doom Eternal post 1.1 Update Patch. For reference, this is my current Hardware setup for my Linux PC:

OS: Pop!_OS 20.04 LTS x86_64
Host: MS-7B89 1.0
Kernel : 5.4.0-7634-generic
CPU: AMD Ryzen 7 3700X
GPU: NVIDIA GeForce RTX 2070 SUPER

Here is the timeline of the problem as I've encountered them so far:

A. Mid-May (right after the 1.1 Update Patch for PC)
Initially there were problems running the game, specifically the following:

1. During the Introduction chapters of the game (basically Chapter 1 & 2), the game noticeably experienced random crashes here and there when I was playing. So essentially I could be in the middle of clearing an arena with a few enemies left, but then suddenly the screen would freeze onto a 'Loading' screen and stop working entirely.
2. The freeze would still weirdly allow the game's audio to continue (basically having a 'Loading' screen, with continuous play of the BGM), but all types of game logic (be it enemies movement, spawns, mouse/keyboard inputs, etc.) seem to stop functioning in the background.
3. The worst part of this is that every time this happens I'm not able to stop the game via pressing the 'Stop' button on Steam, and instead needed to resort to Killing the DOOMEternalx64 PID Process from my 'System Monitor'.

However, the weird thing is that after clearing reaching levels 3 and beyond, this freezing issue seem to have stopped and I was able to finish my first 'fast' Nightmare run around a few weeks ago (sometime around end of May or early June if I recall).

B. Today (June 14, 2020):
I was trying to do a new 100% completion Nightmare run today, starting in a New Game Slot. However, to my surprise these exact same freezing issues re-surfaced during these first introductionary levels, causing me to re-try from the latest checkpoint everytime the Freeze happens. The weird part is that this time the freeze issue seems to happen more frequently (on average around the time to clear one 'arena' between each freeze instances), which made me suspect that there are some compatibility issues caused even by the 1.1 Patch (though I'm not sure whether it's connected with Denuvo or not). I've tried to run all the suggested flags in this thread as well (NO_ESYNC, skipIntroVideo, skipSignInLauncher, etc.), but to no avail.

Seeing this, I then tried different versions of Proton instead, notably the 'GE' versions of Proton, which seem to provide several additions to Proton itself. Unfortunately installing the 5.6 and 5.9 GE version of Proton didn't seem to fix the issue and instead made the Wine System Tray to throw out a GPU Driver error, saying that I have outdated NVIDIA driver version.

I've confirmed through 'nvidia-smi' command that I have the latest driver-440 version from NVIDIA. Weirdly enough, the Wine System Tray instead says my NVIDIA driver is of the driver-378 version, and asking me to update to the driver-445 version, which last time I checked, hasn't even been released for the RTX 2070 Super that I'm using.

What's worse now is that after several re-tries and even a re-installation in Steam, the Wine system now is unable to launch the game at all, stating that 'Something went wrong, and please visit https://support.codefusion.technology/de_d90127jd781/?e=88500006&l=english'. Visiting the error link seem to state that "Currently your game purchase cannot be re-validated successfully, please wait 24 hours and try again." I've then tried several suggestions on Steam on similar issues from other games, most notably this page. However, re-validating my Local Game Files seem to have not solved the issue, which brings me essentially back to pre-1.1 Patch version of the game. I'll wait for 24 hours after this, however that same page stated that waiting 24 hours didn't fix the issue for them, so I'll be updating if it somehow fixes mine.

Has anyone else over here have similar issues on the Linux version of Doom Eternal post 1.1 update so far? And For those who know how Steam's Proton works in detail, may I know what could be the main cause of such issue, and whether there is some solutions that could help me fix/alleviate some of these issues?

Any kind of replies/help is highly appreciated, and thanks for all replies in advance!

Same issues with random crashing and audio keeps playing but you have to force quit the game. Used to work fine before the updates 1.0 (anti cheat broke this completely)and 1.1 (said issues)

From: NickSadjoli notifications@github.com
Sent: Sunday, June 14, 2020, 8:35 AM
To: ValveSoftware/Proton
Cc: oogetyboogety; Comment
Subject: Re: [ValveSoftware/Proton] Doom Eternal (782330) (#3773)

Hi, I'm having problems running Doom Eternal post 1.1 Update Patch. For reference, this is my current Hardware setup for my Linux PC:

OS: Pop!_OS 20.04 LTS x86_64
Host: MS-7B89 1.0
Kernel : 5.4.0-7634-generic
CPU: AMD Ryzen 7 3700X
GPU: NVIDIA GeForce RTX 2070 SUPER

Here is the timeline of the problem as I've encountered them so far:

A. Mid-May (right after the 1.1 Update Patch for PC)
Initially there were problems running the game, specifically the following:

1. During the Introduction chapters of the game (basically Chapter 1 & 2), the game noticeably experienced random crashes here and there when I was playing. So essentially I could be in the middle of clearing an arena with a few enemies left, but then suddenly the screen would freeze onto a 'Loading' screen and stop working entirely.
2. The freeze would still weirdly allow the game's audio to continue (basically having a 'Loading' screen, with continuous play of the BGM), but all types of game logic (be it enemies movement, spawns, mouse/keyboard inputs, etc.) seem to stop functioning in the background.
3. The worst part of this is that every time this happens I'm not able to stop the game via pressing the 'Stop' button on Steam, and instead needed to resort to Killing the DOOMEternalx64 PID Process from my 'System Monitor'.

However, the weird thing is that after clearing reaching levels 3 and beyond, this freezing issue seem to have stopped and I was able to finish my first 'fast' Nightmare run around a few weeks ago (sometime around end of May or early June if I recall).

B. Today (June 14, 2020):
I was trying to do a new 100% completion Nightmare run today, starting in a New Game Slot. However, to my surprise these exact same freezing issues re-surfaced during these first introductionary levels, causing me to re-try from the latest checkpoint everytime the Freeze happens. The weird part is that this time the freeze issue seems to happen more frequently (on average around the time to clear one 'arena' between each freeze instances), which made me suspect that there are some compatibility issues caused even by the 1.1 Patch (though I'm not sure whether it's connected with Denuvo or not). I've tried to run all the suggested flags in this thread as well (NO_ESYNC, skipIntroVideo, skipSignInLauncher, etc.), but to no avail.

Seeing this, I then tried different versions of Proton instead, notably the 'GE' versionshttps://github.com/GloriousEggroll/proton-ge-custom of Proton, which seem to provide several additions to Proton itself. Unfortunately installing the 5.6 and 5.9 GE version of Proton didn't seem to fix the issue and instead made the Wine System Tray to throw out a GPU Driver error, saying that I have outdated NVIDIA driver version.

I've confirmed through 'nvidia-smi' command that I have the latest driver-440 version from NVIDIA. Weirdly enough, the Wine System Tray instead says my NVIDIA driver is of the driver-378 version, and asking me to update to the driver-445 version, which last time I checkedhttps://www.nvidia.com/Download/driverResults.aspx/159360/en-us, hasn't even been released for the RTX 2070 Super that I'm using.

What's worse now is that after several re-tries and even a re-installation in Steam, the Wine system now is unable to launch the game at all, stating that 'Something went wrong, and please visit https://support.codefusion.technology/de_d90127jd781/?e=88500006&l=english'. Visiting the error linkhttps://support.codefusion.technology/de_d90127jd781/?e=88500006&l=english seem to state that "Currently your game purchase cannot be re-validated successfully, please wait 24 hours and try again." I've then tried several suggestions on Steam on similar issues from other games, most notably this pagehttps://steamcommunity.com/app/582010/discussions/0/1734339624803551854. However, re-validating my Local Game Files seem to have not solved the issue, which brings me essentially back to pre-1.1 Patch version of the game. I'll wait for 24 hours after this, however that same page stated that waiting 24 hours didn't fix the issue for them, so I'll be updating if it somehow fixes mine.

Has anyone else over here have similar issues on the Linux version of Doom Eternal post 1.1 update so far? And For those who know how Steam's Proton works in detail, may I know what could be the main cause of such issue, and whether there is some solutions that could help me fix/alleviate some of these issues?

Any kind of replies/help is highly appreciated, and thanks for all replies in advance!

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://github.com/ValveSoftware/Proton/issues/3773#issuecomment-643760832, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAZKLVQXB44S3CACP3QPQE3RWS7ZPANCNFSM4MI6DHIA.

The 24 hour message is from trying to launch it too many times, it's the
DRM kicking in. It's nothing to do with verifying files. You just have to
wait 24 hours.

On Sun, Jun 14, 2020 at 12:58 PM oogetyboogety notifications@github.com
wrote:

Same issues with random crashing and audio keeps playing but you have to
force quit the game. Used to work fine before the updates 1.0 (anti cheat
broke this completely)and 1.1 (said issues)

---

From: NickSadjoli notifications@github.com
Sent: Sunday, June 14, 2020, 8:35 AM
To: ValveSoftware/Proton
Cc: oogetyboogety; Comment
Subject: Re: [ValveSoftware/Proton] Doom Eternal (782330) (#3773)

Hi, I'm having problems running Doom Eternal post 1.1 Update Patch. For
reference, this is my current Hardware setup for my Linux PC:

OS: Pop!_OS 20.04 LTS x86_64
Host: MS-7B89 1.0
Kernel : 5.4.0-7634-generic
CPU: AMD Ryzen 7 3700X
GPU: NVIDIA GeForce RTX 2070 SUPER

Here is the timeline of the problem as I've encountered them so far:

A. Mid-May (right after the 1.1 Update Patch for PC)
Initially there were problems running the game, specifically the following:

1. During the Introduction chapters of the game (basically Chapter 1 & 2),
   the game noticeably experienced random crashes here and there when I was
   playing. So essentially I could be in the middle of clearing an arena with
   a few enemies left, but then suddenly the screen would freeze onto a
   'Loading' screen and stop working entirely.
2. The freeze would still weirdly allow the game's audio to continue
   (basically having a 'Loading' screen, with continuous play of the BGM), but
   all types of game logic (be it enemies movement, spawns, mouse/keyboard
   inputs, etc.) seem to stop functioning in the background.
3. The worst part of this is that every time this happens I'm not able to
   stop the game via pressing the 'Stop' button on Steam, and instead needed
   to resort to Killing the DOOMEternalx64 PID Process from my 'System
   Monitor'.

However, the weird thing is that after clearing reaching levels 3 and
beyond, this freezing issue seem to have stopped and I was able to finish
my first 'fast' Nightmare run around a few weeks ago (sometime around end
of May or early June if I recall).

B. Today (June 14, 2020):
I was trying to do a new 100% completion Nightmare run today, starting in
a New Game Slot. However, to my surprise these exact same freezing issues
re-surfaced during these first introductionary levels, causing me to re-try
from the latest checkpoint everytime the Freeze happens. The weird part is
that this time the freeze issue seems to happen more frequently (on average
around the time to clear one 'arena' between each freeze instances), which
made me suspect that there are some compatibility issues caused even by the
1.1 Patch (though I'm not sure whether it's connected with Denuvo or not).
I've tried to run all the suggested flags in this thread as well (NO_ESYNC,
skipIntroVideo, skipSignInLauncher, etc.), but to no avail.

Seeing this, I then tried different versions of Proton instead, notably
the 'GE' versionshttps://github.com/GloriousEggroll/proton-ge-custom of
Proton, which seem to provide several additions to Proton itself.
Unfortunately installing the 5.6 and 5.9 GE version of Proton didn't seem
to fix the issue and instead made the Wine System Tray to throw out a GPU
Driver error, saying that I have outdated NVIDIA driver version.

I've confirmed through 'nvidia-smi' command that I have the latest
driver-440 version from NVIDIA. Weirdly enough, the Wine System Tray
instead says my NVIDIA driver is of the driver-378 version, and asking me
to update to the driver-445 version, which last time I checked<
https://www.nvidia.com/Download/driverResults.aspx/159360/en-us>, hasn't
even been released for the RTX 2070 Super that I'm using.

What's worse now is that after several re-tries and even a re-installation
in Steam, the Wine system now is unable to launch the game at all, stating
that 'Something went wrong, and please visit
https://support.codefusion.technology/de_d90127jd781/?e=88500006&l=english'.
Visiting the error link<
https://support.codefusion.technology/de_d90127jd781/?e=88500006&l=english>
seem to state that "Currently your game purchase cannot be re-validated
successfully, please wait 24 hours and try again." I've then tried several
suggestions on Steam on similar issues from other games, most notably this
page<
https://steamcommunity.com/app/582010/discussions/0/1734339624803551854>.
However, re-validating my Local Game Files seem to have not solved the
issue, which brings me essentially back to pre-1.1 Patch version of the
game. I'll wait for 24 hours after this, however that same page stated that
waiting 24 hours didn't fix the issue for them, so I'll be updating if it
somehow fixes mine.

Has anyone else over here have similar issues on the Linux version of Doom
Eternal post 1.1 update so far? And For those who know how Steam's Proton
works in detail, may I know what could be the main cause of such issue, and
whether there is some solutions that could help me fix/alleviate some of
these issues?

Any kind of replies/help is highly appreciated, and thanks for all replies
in advance!

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-643760832>,
or unsubscribe<
https://github.com/notifications/unsubscribe-auth/AAZKLVQXB44S3CACP3QPQE3RWS7ZPANCNFSM4MI6DHIA

.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-643793392,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM5Y336KMEDIXCK2T5N63ZDRWT6SVANCNFSM4MI6DHIA
.

Update regarding my freezing problem:

The 24 hours restriction was indeed apparently a Denuvo thingy. Please ignore my issue regarding that one.

After getting the restriction resolved, I then tried to play more of Doom Eternal. However, the freezing issues still persist. What's most annoying is how this also happens on Ultra-Nightmare (The freezing that happened right after the 1.1 patch didn't extend to Ultra-Nightmare iirc). Tweaking some graphics settings didn't seem to help either, so I'm basically stuck right now.

9118.055:00c4:00c8:trace:seh:dwarf_virtual_unwind fde 0x7b4a8280 len 8c personality (nil) lsda (nil) code 7b439968-7b439e60
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b439968: DW_CFA_advance_loc 1
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b439969: DW_CFA_def_cfa_offset 16
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b439969: DW_CFA_offset %rbp, -16
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b439969: DW_CFA_advance_loc 10
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b439973: DW_CFA_def_cfa_register %rbp
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b439973: DW_CFA_advance_loc 39
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_expression %xmm6 7b4a829c-7b4a829f
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_offset %r15, -24
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_offset %r14, -32
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_offset %r13, -40
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_offset %r12, -48
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_offset %rdi, -56
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_offset %rsi, -64
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_offset %rbx, -72
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_advance_loc 11
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399a5: DW_CFA_expression %xmm7 7b4a82b1-7b4a82b4
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399a5: DW_CFA_advance_loc 8
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399ad: DW_CFA_expression %xmm8 7b4a82b8-7b4a82bb
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399ad: DW_CFA_advance_loc 8
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399b5: DW_CFA_expression %xmm9 7b4a82bf-7b4a82c2
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399b5: DW_CFA_advance_loc 8
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399bd: DW_CFA_expression %xmm10 7b4a82c6-7b4a82c9
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399bd: DW_CFA_advance_loc 8
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399c5: DW_CFA_expression %xmm11 7b4a82cd-7b4a82d0
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399c5: DW_CFA_advance_loc 5
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399ca: DW_CFA_expression %xmm12 7b4a82d4-7b4a82d7
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399ca: DW_CFA_advance_loc 5
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399cf: DW_CFA_expression %xmm13 7b4a82db-7b4a82de
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399cf: DW_CFA_advance_loc 5
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399d4: DW_CFA_expression %xmm14 7b4a82e2-7b4a82e5
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399d4: DW_CFA_advance_loc 5
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399d9: DW_CFA_expression %xmm15 7b4a82e9-7b4a82ec
9118.055:00c4:00c8:trace:seh:execute_cfa_instructions 7b4399d9: DW_CFA_advance_loc2 553
9118.055:00c4:00c8:trace:seh:dwarf_virtual_unwind next function rip=0000000140329405
9118.055:00c4:00c8:trace:seh:dwarf_virtual_unwind   rax=00007fffffd9c000 rbx=00000000150ad710 rcx=00000000008eb8f0 rdx=000000007b475c96
9118.055:00c4:00c8:trace:seh:dwarf_virtual_unwind   rsi=0000000000000001 rdi=00000000fffffffd rbp=00000000008ed0c0 rsp=00000000008ecfc0
9118.055:00c4:00c8:trace:seh:dwarf_virtual_unwind    r8=00000000008ecb70  r9=000000007b475cd0 r10=000000007bd1d388 r11=0000000000000000
9118.055:00c4:00c8:trace:seh:dwarf_virtual_unwind   r12=0000000000000001 r13=0000000000000001 r14=000000014269b2f8 r15=00000000008f5208
9118.055:00c4:00c8:trace:seh:RtlRestoreContext returning to 7b475c96 stack 8ecc30
9136.848:00b8:00bc:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\api-ms-win-appmodel-runtime-l1-1-2.dll" at 0x6c100000: PE builtin
9136.849:00b8:00bc:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFFFFFFFFFA, 000000000091FA90
9137.895:0058:0068:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\drivers\\winehid.sys" : builtin
9137.895:0058:0068:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\hidclass.sys" : builtin
9137.896:0058:0068:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\drivers\\winebus.sys" : builtin
pid 127348 != 127347, skipping destruction (fork without exec?)
from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.

These error messages leads me to believe that there might be something wrong with my Wine installation, though I'm not completely sure. Do note that the pid message might have been produced from my 'Killing' of the DoomEternal.exe process from the System Monitor though, so it might not be related to the game's crash entirely.

Any help with this would be very appreciated, and thanks in advance!

@NickSadjoli I think you're maybe a bit confused about how Steam/Proton work.
Proton doesn't use any of your system wine whatsoever. It includes its own build of wine, you could uninstall wine with sudo apt remove wine or sudo apt remove wine-staging or whatever version of wine you have installed, and the game would still run. It has nothing to do with it.
And unless you built the version of Proton you're using yourself, if you're using a prebuilt version, then it's unlikely to be a "broken" wine/proton issue.

Actually, now I see where you said you were using GE's build of Proton, which is precompiled. So yeah, this has nothing to do with anything on your system as far as WINE is concerned. You've tried multiple versions of Proton (which again, don't even remotely interact with the wine you have installed system-wide).

It could definitely be an Nvidia driver or vulkan-icd-loader issue, though.

Maybe it is this problem that when the Steam app overlays some notification (e.g. new achievement), then it freezes (audio still continues to play, but graphics stop, and it does not respond to inputs anymore). This is the same when you Ctrl+Tab out of the game, or have any other overlayed notification from any other app in the game.

I already disabled the Steam Overlay while in-game (in Steam properties) but still I sometimes get these Steam notifications for new achievements. Maybe when you are playing Nightmare mode for the first time, you would get a couple of these Steam achievements, and that will always make it freeze?

@gardotd426 I see, thanks for the correction. I was indeed under the impression that Proton uses the Wine package that is installed into my machine (I thought it would've been installed as a separate package that was installed simultaneously with Steam), so that's why I thought that something was probably wrong with my Wine installation. Apologies for this assumption, and guess I do need to read more of the documentation of Proton again.

I'm not sure whether it's a vulkan-icd-loader issue, though now that I recall, I did install the Vulkan driver packages (via apt-get install) libvulkan1 and mesa-vulkan-drivers during either the periods that Doom Eternal was bricked (prior 1.1 patch), or sometime during my initial Nightmare complete run (just after 1.11 patch). Prior to the Update 1 fiasco I recalled the game never having any issues without these packages being installed, though I was under the impression that the Proton/Wine package already has Vulkan drivers support (since I'm able to click the 'use Vulkan' option in the Doom Eternal's Graphic setting). Could the installation of these 'separate' drivers possibly be the source of issue?

Just now I tried to perform some extra tests of the game between 9 pm and 10 pm local time. I initially tried out the suggestion given by @albertz to disable the Steam Overlay (cause I was actually experiencing the same issues that he described with regards to Ctrl + Tab or Alt + Tab crashing the game), but unfortunately no luck and still experiencing the exact same freezes. I then tried to Force the BPM overlay to off as well, but no dice as well. What's weird was that this change of setting seemed to have caused the game's save system to glitch out and seemingly 'wiped out' all the Save Files I have locally on my PC (similar to peoples' reports on Save File getting removed after Update 1 earlier in this thread), recognizing all Save Slots as a "New Slot". You can see this in the traces of the first log file output that I'll be posting below for more details.

After this weird issue, my PC then somehow froze outside the game, so I then proceeded to restart my PC. Weirdly enough once I boot into the game (after the 9:13 pm crash), the game seem to have recovered all my previous Save files, and recorded whatever progress I had in the previous session (before the 9:13pm freeze) to the designated slot I chose.

I then decided to give it some try and played the game with this latest state. It seemed to have been going well (didn't experience any freeze for quite a noticeably good period of time), but alas 15 - 20 minutes in the crashes happened again (9:46 pm crash). This was notably with only some of the recommended flags turned on (only Proton Logs, skipIntro, skipKeyPressLoadingScene flags were on) though.

As a final try, I then tried to turn on all the flags that has been recommended in this thread so far (NO_ESYNC and also skipSignInManager), but unfortunately the crash still happened (see 10.03 pm crash log).

I've recorded the last few ms traces of the log files captured for these crashed sessions, however they're quite long so I'll be posting these in subsequent comments one-by-one, limiting them to only the last few hundred lines (Github cannot seem to support all of these lines at once). I've also added the timestamp of the crash logs for reference.

EDIT: Added some comments regarding the log file recordings.

12804.774:00c4:00dc:warn:debugstr:OutputDebugStringA "WARNING: Invalid checkpoint name for target layer visibility_target_change_layer_28: checkpoint save aborted!!\n"
...
12993.870:00c4:0108:trace:seh:RtlRestoreContext returning to 7b475c96 stack 9b72bb0
12993.870:00c4:0108:warn:debugstr:OutputDebugStringA "WARNING: Destructible destructible/imp/leg_severed_left piece (mesh_1) has linear velocity greater than 30.0 m/s.  Please fix decl.\n"
12993.870:00c4:0108:trace:seh:raise_exception code=40010006 flags=0 addr=0x7b00fc3e ip=7b00fc3e tid=0108
12993.870:00c4:0108:trace:seh:raise_exception  info[0]=0000000000000085
12993.870:00c4:0108:trace:seh:raise_exception  info[1]=0000000009b730f0
12993.870:00c4:0108:trace:seh:raise_exception  rax=0000000009b72b10 rbx=00007fffffc9c000 rcx=0000000009b72af0 rdx=0000000000000000
12993.870:00c4:0108:trace:seh:raise_exception  rsi=0000000009b72bf0 rdi=0000000009b72b20 rbp=0000000009b72f30 rsp=0000000009b72ad0
12993.870:00c4:0108:trace:seh:raise_exception   r8=0000000000000002  r9=0000000009b72be0 r10=000000007b47b4e6 r11=0000000000000000
12993.870:00c4:0108:trace:seh:raise_exception  r12=0000000000000001 r13=0000000000000001 r14=00000001427349d0 r15=ffffffffffffffff
...
13016.476:00c4:00fc:trace:seh:execute_cfa_instructions 7b4399d4: DW_CFA_advance_loc 5
13016.476:00c4:00fc:trace:seh:execute_cfa_instructions 7b4399d9: DW_CFA_expression %xmm15 7b4a82e9-7b4a82ec
13016.476:00c4:00fc:trace:seh:execute_cfa_instructions 7b4399d9: DW_CFA_advance_loc2 553
13016.476:00c4:00fc:trace:seh:dwarf_virtual_unwind next function rip=0000000140329405
13016.476:00c4:00fc:trace:seh:dwarf_virtual_unwind   rax=00007fffffccc000 rbx=00000000150ad5a0 rcx=00000000083462b0 rdx=000000007b475c96
13016.476:00c4:00fc:trace:seh:dwarf_virtual_unwind   rsi=0000000000000001 rdi=00000000fffffffd rbp=0000000008347a80 rsp=0000000008347980
13016.476:00c4:00fc:trace:seh:dwarf_virtual_unwind    r8=0000000008347530  r9=000000007b475cd0 r10=000000007bd1d388 r11=0000000000000000
13016.476:00c4:00fc:trace:seh:dwarf_virtual_unwind   r12=0000000000000001 r13=0000000000000000 r14=000000014266ac50 r15=000000000834fbc8
13016.476:00c4:00fc:trace:seh:RtlRestoreContext returning to 7b475c96 stack 83475f0
13027.739:00b8:00bc:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\api-ms-win-appmodel-runtime-l1-1-2.dll" at 0x6c100000: PE builtin
13027.740:00b8:00bc:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFFFFFFFFFA, 000000000091FA90
13028.781:0058:0068:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\drivers\\winehid.sys" : builtin
13028.781:0058:0068:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\hidclass.sys" : builtin
13028.782:0058:0068:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\drivers\\winebus.sys" : builtin
pid 156633 != 156632, skipping destruction (fork without exec?)

I'd like to highlight the first recorded line of this log trace in particular, since this is the crash where the save files were somehow not recognized (almost gave me the impression that previous save files were wiped). This was noticeably happening after I adjusted the Steam Overlay option.

EDIT: Trimmed log file to avoid unnecessary cluttering

...
1458.379:00c4:00f0:trace:seh:dwarf_virtual_unwind   r12=0000000000000001 r13=0000000000000001 r14=00000001426d1cb0 r15=0000000006b1c408
1458.379:00c4:00f0:trace:seh:call_stack_handlers found wine frame 0x6b13fa0 rsp 6b141c0 handler 0x7b475d00
1458.379:00c4:00f0:trace:seh:call_teb_handler calling TEB handler 0x7b475d00 (rec=0x6b13d70, frame=0x6b13fa0 context=0x6b13210, dispatch=0x6b130e0)
1458.379:00c4:00f0:trace:seh:RtlUnwindEx code=40010006 flags=2 end_frame=0x6b13fa0 target_ip=0x7b475c96 rip=000000007bcdb792
1458.379:00c4:00f0:trace:seh:RtlUnwindEx  info[0]=000000000000002f
1458.379:00c4:00f0:trace:seh:RtlUnwindEx  info[1]=0000000006b14370
1458.379:00c4:00f0:trace:seh:RtlUnwindEx  rax=00007fffffcfc000 rbx=0000000006b13fa0 rcx=0000000006b12af0 rdx=000000007b475c96
1458.379:00c4:00f0:trace:seh:RtlUnwindEx  rsi=0000000006b13d70 rdi=0000000006b12500 rbp=0000000006b12ab0 rsp=0000000006b12380
1458.379:00c4:00f0:trace:seh:RtlUnwindEx   r8=0000000006b13d70  r9=000000007b475cd0 r10=000000007bd1d388 r11=0000000000000000
1458.379:00c4:00f0:trace:seh:RtlUnwindEx  r12=0000000006b13d70 r13=0000000006b13210 r14=0000000006b130e0 r15=0000000006b12500
... 
1460.262:00c4:00fc:trace:seh:execute_cfa_instructions 7b4399d4: DW_CFA_advance_loc 5
1460.262:00c4:00fc:trace:seh:execute_cfa_instructions 7b4399d9: DW_CFA_expression %xmm15 7b4a82e9-7b4a82ec
1460.262:00c4:00fc:trace:seh:execute_cfa_instructions 7b4399d9: DW_CFA_advance_loc2 553
1460.262:00c4:00fc:trace:seh:dwarf_virtual_unwind next function rip=0000000140329405
1460.262:00c4:00fc:trace:seh:dwarf_virtual_unwind   rax=00007fffffccc000 rbx=00000000150ad620 rcx=00000000083462b0 rdx=000000007b475c96
1460.262:00c4:00fc:trace:seh:dwarf_virtual_unwind   rsi=0000000000000001 rdi=00000000fffffffd rbp=0000000008347a80 rsp=0000000008347980
1460.262:00c4:00fc:trace:seh:dwarf_virtual_unwind    r8=0000000008347530  r9=000000007b475cd0 r10=000000007bd1d388 r11=0000000000000000
1460.262:00c4:00fc:trace:seh:dwarf_virtual_unwind   r12=0000000000000001 r13=0000000000000000 r14=000000014266ac50 r15=000000000834fbc8
1460.262:00c4:00fc:trace:seh:RtlRestoreContext returning to 7b475c96 stack 83475f0
1477.637:00b8:00bc:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\api-ms-win-appmodel-runtime-l1-1-2.dll" at 0x6c100000: PE builtin
1477.637:00b8:00bc:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFFFFFFFFFA, 000000000091FA90
1478.689:0058:0068:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\drivers\\winehid.sys" : builtin
1478.689:0058:0068:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\hidclass.sys" : builtin
1478.690:0058:0068:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\drivers\\winebus.sys" : builtin
pid 14108 != 14107, skipping destruction (fork without exec?)

EDIT: Trimmed log file output to avoid unnecessary cluttering.

...
--------------SAVEGAME----------- time: 2219839
2355.307:00c4:00d4:warn:debugstr:OutputDebugStringA "Game saved.\n"
2355.307:00c4:00d4:trace:seh:raise_exception code=40010006 flags=0 addr=0x7b00fc3e ip=7b00fc3e tid=00d4
2355.307:00c4:00d4:trace:seh:raise_exception  info[0]=000000000000000d
2355.307:00c4:00d4:trace:seh:raise_exception  info[1]=00000000032a4140
2355.307:00c4:00d4:trace:seh:raise_exception  rax=00000000032a3b60 rbx=00007fffffd6c000 rcx=00000000032a3b40 rdx=0000000000000000
2355.307:00c4:00d4:trace:seh:raise_exception  rsi=00000000032a3c40 rdi=00000000032a3b70 rbp=00000000032a3f80 rsp=00000000032a3b20
2355.307:00c4:00d4:trace:seh:raise_exception   r8=0000000000000002  r9=00000000032a3c30 r10=000000007b47b4e6 r11=0000000000000000
2355.307:00c4:00d4:trace:seh:raise_exception  r12=0000000000000001 r13=0000000000000001 r14=00000001429ff1f8 r15=00000000032ac1d8
2355.307:00c4:00d4:trace:seh:call_vectored_handlers calling handler at 0x69060a20 code=40010006 flags=0
2355.307:00c4:00d4:trace:seh:call_vectored_handlers handler at 0x69060a20 returned 0
2355.307:00c4:00d4:trace:seh:call_vectored_handlers calling handler at 0x140952400 code=40010006 flags=0
2355.307:00c4:00d4:trace:seh:call_vectored_handlers handler at 0x140952400 returned 0
2355.307:00c4:00d4:trace:seh:RtlVirtualUnwind type 1 rip 7b00fc3e rsp 32a3b20
...
...
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7bcdb2bb: DW_CFA_expression %xmm12 7bec89a8-7bec89ab
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7bcdb2bb: DW_CFA_advance_loc 5
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7bcdb2c0: DW_CFA_expression %xmm13 7bec89af-7bec89b2
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7bcdb2c0: DW_CFA_advance_loc 5
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7bcdb2c5: DW_CFA_expression %xmm14 7bec89b6-7bec89b8
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7bcdb2c5: DW_CFA_advance_loc 5
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7bcdb2ca: DW_CFA_expression %xmm15 7bec89bc-7bec89be
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7bcdb2ca: DW_CFA_advance_loc1 116
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind next function rip=000000007bcd45f9
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind   rax=00007fffffc9c000 rbx=00007fffffc9c000 rcx=0000000009b762b0 rdx=000000007b475c96
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind   rsi=0000000009b77630 rdi=0000000009b77560 rbp=0000000009b77970 rsp=0000000009b77010
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind    r8=0000000009b77530  r9=000000007b475cd0 r10=000000007bd1d388 r11=0000000000000000
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind   r12=0000000000000001 r13=0000000000000000 r14=000000014266ac50 r15=0000000009b7fbc8
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind function 7bcd45f9 base 0x7bcd45a4 cie 0x7bea6ce0 len 14 id 0 version 1 aug 'zR' code_align 1 data_align -8 retaddr %rip
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7bcd45a4: DW_CFA_def_cfa %rsp, 8
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7bcd45a4: DW_CFA_offset %rip, -8
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind fde 0x7bec7c90 len 14 personality (nil) lsda (nil) code 7bcd45a4-7bcd4601
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7bcd45a4: DW_CFA_advance_loc 7
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7bcd45ab: DW_CFA_def_cfa_offset 1280
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind next function rip=000000007b00fc3e
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind   rax=00007fffffc9c000 rbx=00007fffffc9c000 rcx=0000000009b762b0 rdx=000000007b475c96
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind   rsi=0000000009b77630 rdi=0000000009b77560 rbp=0000000009b77970 rsp=0000000009b77510
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind    r8=0000000009b77530  r9=000000007b475cd0 r10=000000007bd1d388 r11=0000000000000000
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind   r12=0000000000000001 r13=0000000000000000 r14=000000014266ac50 r15=0000000009b7fbc8
2360.129:00c4:0108:trace:seh:RtlVirtualUnwind type 2 rip 7b00fc3e rsp 9b77510
2360.129:00c4:0108:trace:seh:dump_unwind_info **** func fbf0-fc77
2360.129:00c4:0108:trace:seh:dump_unwind_info unwind info at 0x7b09a340 flags 0 prolog 0x11 bytes function 0x7b00fbf0-0x7b00fc77
2360.129:00c4:0108:trace:seh:dump_unwind_info     0x11: subq $0xc8,%rsp
2360.129:00c4:0108:trace:seh:dump_unwind_info     0xa: pushq %rsi
2360.129:00c4:0108:trace:seh:dump_unwind_info     0x9: pushq %rdi
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind function 7b439bb1 base 0x7b439968 cie 0x7b496a90 len 14 id 0 version 1 aug 'zR' code_align 1 data_align -8 retaddr %rip
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b439968: DW_CFA_def_cfa %rsp, 8
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b439968: DW_CFA_offset %rip, -8
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind fde 0x7b4a8280 len 8c personality (nil) lsda (nil) code 7b439968-7b439e60
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b439968: DW_CFA_advance_loc 1
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b439969: DW_CFA_def_cfa_offset 16
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b439969: DW_CFA_offset %rbp, -16
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b439969: DW_CFA_advance_loc 10
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b439973: DW_CFA_def_cfa_register %rbp
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b439973: DW_CFA_advance_loc 39
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_expression %xmm6 7b4a829c-7b4a829f
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_offset %r15, -24
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_offset %r14, -32
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_offset %r13, -40
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_offset %r12, -48
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_offset %rdi, -56
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_offset %rsi, -64
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_offset %rbx, -72
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b43999a: DW_CFA_advance_loc 11
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399a5: DW_CFA_expression %xmm7 7b4a82b1-7b4a82b4
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399a5: DW_CFA_advance_loc 8
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399ad: DW_CFA_expression %xmm8 7b4a82b8-7b4a82bb
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399ad: DW_CFA_advance_loc 8
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399b5: DW_CFA_expression %xmm9 7b4a82bf-7b4a82c2
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399b5: DW_CFA_advance_loc 8
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399bd: DW_CFA_expression %xmm10 7b4a82c6-7b4a82c9
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399bd: DW_CFA_advance_loc 8
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399c5: DW_CFA_expression %xmm11 7b4a82cd-7b4a82d0
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399c5: DW_CFA_advance_loc 5
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399ca: DW_CFA_expression %xmm12 7b4a82d4-7b4a82d7
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399ca: DW_CFA_advance_loc 5
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399cf: DW_CFA_expression %xmm13 7b4a82db-7b4a82de
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399cf: DW_CFA_advance_loc 5
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399d4: DW_CFA_expression %xmm14 7b4a82e2-7b4a82e5
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399d4: DW_CFA_advance_loc 5
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399d9: DW_CFA_expression %xmm15 7b4a82e9-7b4a82ec
2360.129:00c4:0108:trace:seh:execute_cfa_instructions 7b4399d9: DW_CFA_advance_loc2 553
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind next function rip=0000000140329405
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind   rax=00007fffffc9c000 rbx=00000000150ad400 rcx=0000000009b762b0 rdx=000000007b475c96
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind   rsi=0000000000000001 rdi=00000000fffffffd rbp=0000000009b77a80 rsp=0000000009b77980
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind    r8=0000000009b77530  r9=000000007b475cd0 r10=000000007bd1d388 r11=0000000000000000
2360.129:00c4:0108:trace:seh:dwarf_virtual_unwind   r12=0000000000000001 r13=0000000000000000 r14=000000014266ac50 r15=0000000009b7fbc8
2360.129:00c4:0108:trace:seh:RtlRestoreContext returning to 7b475c96 stack 9b775f0
Flushing device resizeSwapChain: true, resizeViewDest: false, resizeImageNeedsFlush: false
2371.848:00b8:00bc:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\api-ms-win-appmodel-runtime-l1-1-2.dll" at 0x6c100000: PE builtin
2371.848:00b8:00bc:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFFFFFFFFFA, 000000000091FA90
2372.862:0058:0068:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\drivers\\winehid.sys" : builtin
2372.862:0058:0068:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\hidclass.sys" : builtin
2372.862:0058:0068:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\drivers\\winebus.sys" : builtin
pid 20758 != 20757, skipping destruction (fork without exec?)

I'm not completely sure which of the lines could've caused the freeze (since none of the debug lines in the last ms seem to show any kind of fatal graphics error), however I do note that the RtlRestoreContext and loaddll traces seem to be the most common lines to occur prior to the process termination (which I initiated manually). Additionally, this line Flushing device resizeSwapChain: true, resizeViewDest: false, resizeImageNeedsFlush: false seem to appear quite often. I'm not so familiar with this, however, may I assume that the RtlRestoreContext and loaddll lines were indicating the game engine's attempts to load in the necessary dll packages to restore context of game scene, with the 'Flushing device' line containing the flags of actions required to be performed by the 'device' (which I'm assuming is the GPU or other resources used to render the current game scene?)

Thanks in advance for any additional help/explanations!

EDIT: Created gists containing more detailed outputs from the log files, as per recommendation of @kisak-valve . Unfortunately only gists containing the detailed output for the first (9.13 pm) and latest (I did further testing as noted in the next comment) test logs (11.18pm). However, further testing could be done and added as another gist if required.

Hello @NickSadjoli, in the future, please attach logs as a file or use a gist.

Oh apologies for that @kisak-valve! I didn't realize that the formatting of the code could be done in such a way as well.

I've provided the gists containing more detailed outputs for the first and latest instance of crashes. Unfortunately the 1MB size limit of the Gists prevented me from uploading the whole log files as well, so I just put in the log outputs right after the game has saved in the latest Checkpoint (marked by END SAVEGAME it seems).

Thanks in advance!

@NickSadjoli Check dmesg after the freeze. I've experienced similar issues that seem to be a result of issues with the AMD kernel drivers.

@jjbarr he's using the proprietary Nvidia drivers, he's not using kernel graphics drivers.

@NickSadjoli you definitely need to remove one of those packages you installed. Those are for AMD and Intel GPUs. You have an Nvidia GPU. You don't use Mesa vulkan drivers, you use the Nvidia drivers. I don't know if that's causing your problem, but it isn't helping. Remove the mesa-vulkan-drivers package. You actually do need libvulkan1 though. Not for Doom Eternal I don't believe, but definitely for any non-steam game you ever end up wanting to play that uses Vulkan or DX. Again, mesa-vulkan-drivers probably isn't causing your issue, but it's not helping either.

Also, just to make sure you have everything you need I'd install libvulkan1:i386 as well. Doom Eternal is all 64-bit, I believe, but still. Other things aren't.

After this, find a KNOWN GOOD proton configuration (whichever version of Proton you were using when it worked fine), switch to it in the game's properties on Steam, and then delete the games pfx. It'll be rm -r ~/path/to/library/steamapps/compatdata/782330/pfx.

@gardotd426 Noted. Unfortunately it seems that I cannot really un-install the mesa-vulkan-drivers directly right now since the pop-desktop environment used by PopOS seems to rely on this package. I do still recall apt-get mentioning that installing the libvulkan and mesa-vulkan-drivers did install new packages however, so what might have happened is that by default some of the sub-packages required for mesa-vulkan-drivers were already included in PopOS by default, but then additional, more optional pacakges, were installed when I asked for subsequent apt-get as well.

Also, with regards on reverting to the previously used version of Proton: I'm currently using Proton v5.0.9. The last Proton with a stable performance (pre-Update 1 and Update 1.1) that I recalled were either v5.0.7, or v5.0.8. Unfortunately it seems that Steam would automatically update the Proton 5.0 to include the latest version of Proton, and discarded the previously used ones in this case. Does the Proton Github keep a log of all previously used version of Proton that I could download and use (similar to the GE version)?

That said, I've tried further testing with the game today. For these tests, I also recorded my syslog to see what could've happened outside of the Proton/game interaction as well. I'll be providing the gists for both Proton and syslog outputs for each of these test sessions as follows:

1. First session, recorded at 11.24 - 11.27 a.m. [syslog_gist ]
   Unfortunately no Proton logs were recorded for this session (forgot to turn the flag on)
2. Game state results: Froze after a few minutes of gameplay. Noticeably right around a Checkpoint save.
3. Flags used: set 1 to all recommended non-proton related flags. no Proton flags were used

4. Game Video settings: Disabled 'Present from Compute' options, which specifically stated to be turned off if having problems with external overlay softwares (which was suggested previously by @albertz)

5. Second session, recorded at 11.30 - 11.32 a.m. [syslog_gist]
   Unfortunately no Proton logs were recorded for this session (forgot to turn the flag on)

6. Game state results: Froze after around < 1 minutes of gameplay. Noticeably right after changing theh 'Present from Compute' settings
7. Flags used: set 1 to all recommended non-proton related flags. no Proton flags were used

8. Game Video settings: Tried to enable 'Present from Compute' options. This time around the game froze a lot faster after enabling this option, with the freeze screen noticeably showing the 'Main Menu settings' screen, right when option was enabled.

9. Third session, recorded at 11.32 a.m. - 11.37 a.m [syslog_gist] [Proton_log_gist]

10. Game state results: Froze after a few minutes of gameplay. Noticeably right around a Checkpoint save.
11. Flags used: set 1 to all recommended non-proton related flags. Only PROTON_LOG was enabled

12. Game Video settings: Kept same settings from previous session ('Present from Compute' Enabled, no other changes)

13. Last session, recorded at 11.42 - 11.46 a.m [syslog_gist] [Proton_log_gist]

14. Game state results: Froze after a noticeably longer than last previous sessions of gameplay. Noticeably right around a Checkpoint save as well.
15. Flags used: set 1 to all recommended non-proton related flags. Only PROTON_LOG was enabled
16. Game Video settings: Kept same settings from previous session ('Present from Compute' Enabled, no other changes)

From all these log files there are a few things that I'd like to note and highlight:

• The line 'Window manager warning: Window 0xa000001 sets an MWM hint indicating it isn't resizable, but sets min size 1 x 1 and max size 2147483647 x 2147483647; this doesn't make much sense.' seems to constantly occur around the time the game froze. Is this an indication that it's a GNOME overlay issue with the game?
• The Proton log from the third session gave an interesting new type of trace error, namely '7370.996:0094:009c:err:clipboard:convert_selection Timed out waiting for SelectionNotify event'. Does this mean that the game was waiting for some sort of event, but then timed-out and causing an error (game freeze)?

Another thing to note is that I am running several background tasks when running the game (though these are mainly open Firefox tabs in the background). I believe these shouldn't really cause any kind of issue with the Game Freeze, however just a note for those who might be able to point out a possible conflict.

To ensure that the engine itself wasn't having an issue with my machine, I then tried to play Doom 2016 for a bit (which uses the previous version of the IdTech engine: IdTech 6), to see whether the current Proton version has caused any kind of problems with this title as well.

Interestingly enough, there were notably two extremely short (around 1 to 2 ms) 'screen blackout' occurences that happened during the Doom 2016 run (which for a splitsecond I thought would cause the freeze similar to Doom Eternal), however the game was able to recover from it and resume the entire gameplay smoothly. Here are the syslog and Proton Log files for the Doom 2016 testing, with a note that the 'blackout'-s seem to occur at around the similar line of 'Window manager MWM hint' warning (for the syslog file), or - in the case of the Proton Log - the 'Setting breakpad minidump' messages. Unfortunately since the Proton Log message seems to differ quite a lot from the Doom Eternal's Proton Log messages, this might not be very helpful, but nonetheless some extra information I was able to observe.

If anyone requires more testing or more information please do let me know and I'll see whether I could provide them as well.

EDIT: Unfinished comment
EDIT2: Formatting

I receiving "Unable to find any avaiable BATTLEMODE matches. Please try again later" and "Launch server failed" messages. On Win 10 everything works fine. Can anyone confirm this issue?

I wouldn't be surprised if they implemented some sort of anticheat that blocks Linux with the latest update (they always said they were bringing anticheat back but just wouldn't block the campaign for it). Obviously there probably aren't any matches going on right now because of the time in the Americas and Europe, but tomorrow (later today, technically) I'll try and see if I can reproduce the issue.

BTW @gardotd426

After this, find a KNOWN GOOD proton configuration (whichever version of Proton you were using when it worked fine).

Regarding your suggestion for this, may I know whether a pre-built version of Proton 5.0.7 or 5.0.8 is available? I understand that I could build a working version of these proton packages locally via Proton's build-guide, however I'd like to know if an already working and pre-compiled version of these could already be downloaded and put into the compatibilitytools.d/ directory for a much faster setup.

Thanks in advance!

@NickSadjoli you might also try to reset the pinned libs.
remove the pinned_libs* folders. they should be in a path like this: ~/.steam/steam/ubuntu12_32/steam-runtime
At next steam start, it'll re-add them.
I haven't tried it, but I think running steam --reset will do that too.

Hi everyone, apologies that this is quite late, however I have seem to have somehow resolved the issue on my end (for now), and managed to get Doom Eternal running smoothly from the second half of 2nd level all the way to currently 6th level without crashing once. There were some noticeable graphical glitches, but I believe that is something has sometimes happened previously as well, which I attribute more to that Proton drivers hasn't been fully optimized for some games yet (perhaps, but that isn't really bugging me too much, since it happens so rare)

TL;DR: the GNOME Extension Backslide seem to have caused some conflict with Doom Eternal. I'm not completely sure why this is happening, however there have been previous instances of GNOME having issues with games running already documented/discussed. So this could be a potential issue for other Proton users as well.

I initially tried @AllKind's suggestion to reset Steam last night. It initially seemed to have worked as I was able to get through a significant portion of the 2nd level without crashing, only to it to unfortunately crash during the transition area between the 2nd and 3rd level though. Another crash occurred when I tried running the game after that, so I think it only alleviated the issue for some time.

This morning I then looked up the syslog errors which I posted again, and noticed that the GNOME desktop apparently had previously been known to cause issues with some games before. With this, I then thought that perhaps some of the GNOME extensions on my PC that modified display-related behavior could've caused a similar conflict with the game's window when it's running.

From all extensions that were active, Backslide and Window Animations are the only extensions which stood out to me to be display-modifying extensions, so I turned off those and ran Doom Eternal again with these off.

Amazingly, the game then run smooth ever since, with only instances of crashing being when I got an incoming Steam message (which seems to relate back to the 'Alt+Tab' or 'Ctrl+Tab' issues that has been reported previously). I then managed to go through the entire 3rd level of the game this morning without any freeze or crashes in this setting, something that wasn't even possible just yesterday.

The question for me then became which extension of the 2 (Window Animation or Backslide) could've specifically caused the issue. To determine this, I then tried turning on Backslide, and ran the game again with it on.

Turned out the game froze just a few minutes after it ran with this configuration, which made me more ensured that Backslide is indeed the problem. I then turned it off, and after that managed to play the game all the way to Level 6 without any more freezes recorded.

Seeing this and the GNOME conflict thread that I linked here, has there been any other potential GNOME and Proton conflicts occurring for other games? Also, has any kind of debugging previously done on Proton to check any potential conflicts with any GNOME specific extensions (especially the ones that alter Desktop's views?). If there turns out to be multiple instances of Proton and GNOME extension conflict, a look into this would be appreciated.

For now, based on my experience I highly suggest turning off any display-modifying GNOME extension with the current state (i.e. post Update 1.1) of Doom Eternal, in the case that similar issues pop-up for anyone else I guess. If others have somehow solved similar issues with a similar kind of solution (turning off some GNOME extension), please do confirm and share it here.

EDIT: Accidentally posted before finishing comment.

I'm glad you got it fixed, but unfortunately even if it were looked into,
and discovered that a huge amount of GNOME extensions cause issues with
Proton, like you're asking about, there's nothing anyone could do. Valve
and Proton have no bearing or ability to fix that whatsoever (on the
whole). And GNOME itself doesn't even create extensions or sanction them at
all, really. They're all "unsupported." So there's nothing really that can
be done, outside of make people aware of it.

On Thu, Jun 18, 2020 at 10:49 AM NickSadjoli notifications@github.com
wrote:

Hi everyone, apologies that this is quite late, however I have seem to
have somehow resolved the issue on my end (for now), and managed to get
Doom Eternal running smoothly from the second half of 2nd level all the way
to currently 6th level without crashing once. There were some noticeable
graphical glitches, but I believe that is something has sometimes happened
previously as well, which I attribute more to that Proton drivers hasn't
been fully optimized for some games yet (perhaps, but that isn't really
bugging me too much, since it happens so rare)

TL;DR: the GNOME Extension Backslide seem to have caused some conflict
with Doom Eternal. I'm not completely sure why this is happening, however
there have been previous instances of GNOME having issues with games
running already documented/discussed. So this could be a potential issue
for other Proton users as well.

I initially tried @AllKind https://github.com/AllKind's suggestion to
reset Steam last night. It initially seemed to have worked as I was able to
get through a significant portion of the 2nd level without crashing, only
to it to unfortunately crash during the transition area between the 2nd and
3rd level though. Another crash occurred when I tried running the game
after that, so I think it only alleviated the issue for some time.

This morning I then looked up the syslog errors which I posted again, and
noticed that the GNOME desktop apparently had previously been known to
cause issues with some games
https://gitlab.gnome.org/GNOME/mutter/-/issues/361 before. With this, I
then thought that perhaps some of the GNOME extensions on my PC that
modified display-related behavior could've caused a similar conflict with
the game's window when it's running.

From all extensions that were active, Backslide and Window Animations are
the only extensions which stood out to me to be display-modifying
extensions, so I turned off those and ran Doom Eternal again with these off.

Amazingly, the game then run smooth ever since, with only instances of
crashing being when I got an incoming Steam message (which seems to relate
back to the 'Alt+Tab' or 'Ctrl+Tab' issues that has been reported
previously). I then managed to go through the entire 3rd level of the game
this morning without any freeze or crashes in this setting, something that
wasn't even possible just yesterday.

The question for me then became which extension of the 2 (Window Animation
or Backslide) could've specifically caused the issue. To determine this, I
then tried turning on Backslide, and ran the game again with it on.

Turned out the game froze just a few minutes after it ran with this
configuration, which made me more ensured that Backslide is indeed the
problem. I then turned it off, and after that managed to play the game all
the way to Level 6 without any more freezes recorded.

Seeing this and the GNOME conflict thread that I linked here, has there
been any other potential GNOME and Proton conflicts occurring for other
games? Also, has any kind of debugging previously done on Proton to check
any potential conflicts with any GNOME specific extensions (especially the
ones that alter Desktop's views?). If there turns out to be multiple
instances of Proton and GNOME extension conflict, a look into this would be
appreciated, and

t using some additional GNOME extensions which I suspected might have
caused some conflict with the game's windows (based on the Windows
management error that I got from syslog), and tried to turn off the
extensions that was tweaking the display/appearance of the desktop - namely
turning off Animations and the Backslide extension. Turning off Backslide
specifically seemed to have worked for me, as when I tried running Doom
Eternal again this morning with Backslide turned on caused the Freeze to
happen again.

So the details of how I managed to do it was as follows:
Yesterday night I tried out @AllKind https://github.com/AllKind's
suggestion to reset Steam. To my surprise, this seemed to have worked
initially as the game didn't crash for a significant amount of time, only
to then crash just as I was about to transition into the 3rd level (iirc).
Unfortunately this crash me

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-646068897,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM5Y33ZKKR2JEZYALJZQSADRXISQPANCNFSM4MI6DHIA
.

@gardotd426 is there a way proton could behave well with overlays? I encounter these issues even without gnome (I use enlightenment on gentoo with openrc instead of systemd), so I don't think the problem can be isolated there

What do you mean by "overlays." That word has numerous definitions when it
comes to computing/gaming/etc.

On Fri, Jun 19, 2020 at 1:00 AM oogetyboogety notifications@github.com
wrote:

@gardotd426 https://github.com/gardotd426 is there a way proton could
behave well with overlays? I encounter these issues even without gnome (I
use enlightenment on gentoo with openrc instead of systemd), so I don't
think the problem can be isolated there

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-646435630,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM5Y3346RUIEP3W2QM6QPW3RXLWGHANCNFSM4MI6DHIA
.

Referring back to this part of the previous post, where the issue appears to be correlated with some functionality where applications try to interrupt the game and the game crashes.

Amazingly, the game then run smooth ever since, with only instances of crashing being when I got an incoming Steam message (which seems to relate back to the 'Alt+Tab' or 'Ctrl+Tab' issues that has been reported previously). I then managed to go through the entire 3rd level of the game this morning without any freeze or crashes in this setting, something that wasn't even possible just yesterday.

Maybe i could dig further into what the root cause is in X or try it in Wayland. I havent looked into using proton with wayland but i thought i disabled "overlays" in terms of the one Proton shows related to the post above. Using wayland might force a different notification mechanism or something mitigating the root cause of this issue which would allow me to play continuously without crashes.

The notification popup you get from Steam while playing steam games is from
Steam itself. It's the Steam overlay. Some games have issues with it, but
not many. Using Wayland is unlikely to change anything, Steam will still be
using the same Steam overlay and even then I'm pretty sure Steam would be
running in XWayland. You could just try disabling the Steam overlay for any
games that seem to have trouble with it.

On Fri, Jun 19, 2020 at 1:08 AM oogetyboogety notifications@github.com
wrote:

Referring back to this part of the previous poat, where the issue appears
to be correlated with some functionality where applications try to
interrupt the game and the game crashes.

Amazingly, the game then run smooth ever since, with only instances of crashing being when I got an incoming Steam message (which seems to relate back to the 'Alt+Tab' or 'Ctrl+Tab' issues that has been reported previously). I then managed to go through the entire 3rd level of the game this morning without any freeze or crashes in this setting, something that wasn't even possible just yesterday.

Maybe i could dig further into what the root cause is in X or try it in
Wayland. I havent looked into using proton with wayland but i thought i
disabled "overlays" in terms of the one Proton shows related to the post
above, but using wayland might force a different notification mechanism orm
something mitigating the root cause of this issue which would allow me to
play continuously without crashes.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-646437725,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM5Y334BPA7PDJVTDHLXON3RXLXF7ANCNFSM4MI6DHIA
.

OK I disabled it but am still getting the same error. I'll try to collect some logs and see if I notice a trend.

EDIT:
Appears to work again for a while. No crashes yet

They're all "unsupported." So there's nothing really that can be done, outside of make people aware of it.

@gardotd426 Darn, that's quite unfortunate then. Glad I performed the tests and helped highlighted this issue then. Hopefully this helps people at least, and hope that this issue could be one of the focus over at the GNOME development team to work on with Valve/Proton.

EDIT: Formatting

They seem to have no real interest in anything like that. And are
absolutely barreling toward the Wayland of the future, regardless of
whether it's ready or not. Which it objectively isn't. That's just my
opinion though I guess. You could still file a bug report with GNOME, but I
don't know how far you'll get. But I mean it technically is an issue on
GNOME, if not an issue with GNOME. They'll probably just tell you not to
use the extension because they didn't write the extensions and don't
support them, though.

On Sat, Jun 20, 2020 at 11:57 AM NickSadjoli notifications@github.com
wrote:

They're all "unsupported." So there's nothing really that can be done,
outside of make people aware of it.
@gardotd426 https://github.com/gardotd426 Darn, that's quite
unfortunate then. Glad I performed the tests and helped highlighted this
issue then. Hopefully this helps people at least, and hope that this issue
could be one of the focus over at the GNOME development team to work on
with Valve/Proton.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-647013133,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM5Y336AOGCCKSZKJIXOMP3RXTL7RANCNFSM4MI6DHIA
.

Hello @PopeRigby, are you still experiencing the hard crash you described in https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-614309204? Additionally, while testing please use oibaf PPA or kisak-mesa PPA and RADV/ACO and let us know if you can reproduce the crash with that.

[782330] - Doom eternal - blinking screen after launching

Issue transferred from https://github.com/ValveSoftware/Proton/issues/4023.
@bobaxxx posted on 2020-06-26T14:01:37:

Compatibility Report

• Name of the game with compatibility issues: Doom eternal
• Steam AppID of the game: 782330

System Information

• GPU: GTX 1060 (mobile)
• Driver/LLVM version: NVIDIA 440
• Kernel version: Linux version 5.3.0-61-generic
• Link to full system information report : https://gist.github.com/bobaxxx/e453840a627188f57f4cb20851b5b0fc
• Proton version: 5.0.9

I confirm:

• [X that I haven't found an existing compatibility report for this game.
• [X] that I have checked whether there are updates for my system available.

Symptoms

Game install is OK, but when i start, i can reach the menu, but screen is blinking like hell.

Reproduction

• Install
• Launch the game (linux mint tricia)

Here is the log :

log.txt

Hello @PopeRigby, are you still experiencing the hard crash you described in #3773 (comment)? Additionally, while testing please use oibaf PPA or kisak-mesa PPA and RADV/ACO and let us know if you can reproduce the crash with that.

I no longer have Doom Eternal installed, but I'll report back when I re-install it. Probably when the first DLC comes out.

It is still pretty annoying that the game does not respond anymore once there will be some notification popup by some other app (maybe Steam itself), or when you accidently hit Alt+Tab or so.

Is this a problem which can be fixed in Wine? I guess this does not happen on Windows, right? It would be nice if this could be fixed. Otherwise it runs very well for me now (with Nvidia 2070). It seems to be even more smooth since Update 2.

Hello @albertz, possibly related: "Fixed a visual glitch of Vulkan applications when they stop flipping due to a window change, such as when alt-tab is used to change window focus." in nVidia 450.51.

@albertz In the game's graphics settings, are you using "fullscreen"? Try changing to the borderless windowed setting.

Game install is OK, but when i start, i can reach the menu, but screen is blinking like hell.

I've had that multiple times. I think when changing Proton versions and when installing a new video driver.
Had to reset video defaults (by keyboard shortcuts) and restart the game.

Hello @albertz, possibly related: "Fixed a visual glitch of Vulkan applications when they stop flipping due to a window change, such as when alt-tab is used to change window focus." in nVidia 450.51.

I have that one installed now, but Alt+Tab is still not working.

Also I've lost my saved games again, after switching from Proton-GE to native 5.0.9. And after Doom Eternal update 2.
Because of that I don't play it on linux any more. Lost my games too many times.

gist

I am also experiencing the same bug as @albertz, but in my case it also happens when the game shows steam progress awards. Is there a way to turn these off?

nvidia 2060S with nvidia 440.100
ubuntu 20.04 (5.4.0-39-generic)

edit: updating the drivers to 450.51 did not solve the issues mentioned above.

anyone play this with an intel gpu? i have a laptop with a uhd 620 and it won't start. first a window appears saying "not supported", then when i click play, the game supposedly loads for 10 or so minutes, but it never starts

P.S. I almost beat DOOM on this laptop, never had issues

Any updates on alt-tab? It's really annoying!

@Rush: Are you using "fullscreen" in the graphics settings of the game? Try setting the game to "borderless windowed" instead. That fixes the Alt-Tab crash problem here for me.

Been trying it with "borderless window". Still doesnt work, crashes on steam achievements aswell. Alt-Tab doesnt work. Im using nvidia-450.57.

Hello,

I've just tried the "borderless window" option on Fedora 32 with a GTX 1070 (driver 450.57). Game window still freezes as soon as Alt+Tab or Windows key is pressed on the Gnome desktop

Im getting a crash with the latest version of doom eternal and not sure whats going on:

Nvidia Driver: 450.57
CPU: AMD 3970x
Ubuntu: 20.04
Kernel: 5.4.0-40-generic
Proton: 5.0-9

Launch Options:
PROTON_LOG=1 %command% +com_skipIntroVideo 1

10121.137:00d0:00d4:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\api-ms-win-core-synch-l1-2-0.dll" at 0x6e340000: PE builtin
10121.138:00d0:00d4:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\api-ms-win-core-fibers-l1-1-1.dll" at 0x6b880000: PE builtin
10121.142:00d0:00d4:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\api-ms-win-core-localization-l1-2-1.dll" at 0x6e6c0000: PE builtin
10121.145:00d0:00d4:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\setupapi.dll" at 0x6a700000: PE builtin
10121.145:00d0:00d4:trace:loaddll:load_so_dll Loaded L"C:\\windows\\system32\\winex11.drv" at 0x7f35416f0000: builtin
10121.177:00d0:00d4:fixme:font:get_outline_text_metrics failed to read full_nameW for font L"Ani"!
10121.192:00d0:00d4:fixme:heap:RtlSetHeapInformation 0x10000 0 0x91c860 4 stub
10121.194:00d0:00d4:warn:debugstr:OutputDebugStringA "Winsock Initialized\n"
10121.194:00d0:00d4:trace:seh:raise_exception code=40010006 flags=0 addr=0x7b00fc3e ip=7b00fc3e tid=00d4
10121.194:00d0:00d4:trace:seh:raise_exception  info[0]=0000000000000015
10121.194:00d0:00d4:trace:seh:raise_exception  info[1]=0000000000914770
10121.194:00d0:00d4:trace:seh:raise_exception  rax=0000000000914190 rbx=00007fffffd9c000 rcx=0000000000914170 rdx=0000000000000000
10121.194:00d0:00d4:trace:seh:raise_exception  rsi=0000000000914270 rdi=00000000009141a0 rbp=00000000009145b0 rsp=0000000000914150
10121.194:00d0:00d4:trace:seh:raise_exception   r8=0000000000000002  r9=0000000000914260 r10=000000007b47b4e6 r11=0000000000000246
10121.194:00d0:00d4:trace:seh:raise_exception  r12=0000000000000001 r13=0000000000000001 r14=0000000140994838 r15=000000000091c808
10121.195:00d0:00d4:trace:seh:RtlVirtualUnwind type 1 rip 7b00fc3e rsp 914150
10121.195:00d0:00d4:trace:seh:dump_unwind_info **** func fbf0-fc77
10121.195:00d0:00d4:trace:seh:dump_unwind_info unwind info at 0x7b09a340 flags 0 prolog 0x11 bytes function 0x7b00fbf0-0x7b00fc77
10121.195:00d0:00d4:trace:seh:dump_unwind_info     0x11: subq $0xc8,%rsp
10121.195:00d0:00d4:trace:seh:dump_unwind_info     0xa: pushq %rsi
10121.195:00d0:00d4:trace:seh:dump_unwind_info     0x9: pushq %rdi
10121.195:00d0:00d4:trace:seh:dwarf_virtual_unwind function 7b439bb1 base 0x7b439968 cie 0x7b496a90 len 14 id 0 version 1 aug 'zR' code_align 1 data_align -8 retaddr %rip

10140.669:00dc:00e0:trace:seh:call_teb_handler handler at 0x7b475d00 returned 1
10140.669:00dc:00e0:warn:seh:virtual_unwind exception data not found in L"DOOMEternalx64vk.exe"
Unhandled exception: page fault on read access to 0x00000060 in 64-bit code (0x00007fd7eb4b08e3).
10140.675:0204:0208:fixme:dbghelp:elf_search_auxv can't find symbol in module
Register dump:
 rip:00007fd7eb4b08e3 rsp:00000000008d05f0 rbp:000000007f16d3c0 eflags:00010206 (  R- --  I   - -P- )
 rax:3fffffffffffffff rbx:000000007f16dd90 rcx:0000000000000009 rdx:0000000000000000
 rsi:0000000000000001 rdi:00000000008d0390  r8:0000000000000010  r9:00000000008d03a8 r10:00000000008d03a4
 r11:0000000000000001 r12:0000000000000000 r13:00000000008d0890 r14:0000000000000000 r15:0000000000000000
Stack dump:
0x00000000008d05f0:  0000000000000001 5c5c5c5c00000091
0x00000000008d0600:  000000007f16d448 8686868600000000
0x00000000008d0610:  9292929200000000 9696969600000000
0x00000000008d0620:  000000007f16d448 000000007ffffffa
0x00000000008d0630:  02b0b0b000000001 ffffffff00000001
0x00000000008d0640:  000000007dc58380 0000000000000000
0x00000000008d0650:  0000000200000002 00000367fffffc98
0x00000000008d0660:  000000007f16d301 00007fd7fab3e780
0x00000000008d0670:  0000000000000400 0000000000001000
0x00000000008d0680:  000000007fa4fb40 0000000000000000
0x00000000008d0690:  00000000000000a0 00007fd7fb391b80
0x00000000008d06a0:  000000007dc4e170 00000000008d0890
Backtrace:
=>0 0x00007fd7eb4b08e3 _nv018glcore+0xffffffffffffffff() in libnvidia-glcore.so.450.57 (0x000000007f16d3c0)
0x00007fd7eb4b08e3 _nv018glcore+0xffffffffffffffff in libnvidia-glcore.so.450.57: andq  0x0000000000000060(%rdx),%rax

Has anyone run into this ?

Been trying it with "borderless window". Still doesnt work, crashes on steam achievements aswell. Alt-Tab doesnt work. Im using nvidia-450.57.

After some more testing I have found out, alt tab seems to work on lower resolution but as soon I change it to native on borderless window it seems to freeze/black screen the game. I dunno if that helps.

nvidia 450.57-6 GTX 1060 6GB
kernel 5.7.12-arch1-1

Game is freezing whenever there is a Steam overlay popup. Now, I don't understand why because I disabled Steam overlay, yet it still shows something like achievement and freezes the game. Afterwards, game won't start anymore (black screen) and I have to reboot the PC in order to be able to play again. Also Alt+Tabbing freezes it to black screen as well, but that can be workarounded by not Alt+Tabbing.
Side-note: I play in offline mode.
EDIT: restarting X allows me to play again. Still annoying, but less so.

nvidia 450.57-6 GTX 1060 6GB
kernel 5.7.12-arch1-1

Game is freezing whenever there is a Steam overlay popup. Now, I don't understand why because I disabled Steam overlay, yet it still shows something like achievement and freezes the game. Afterwards, game won't start anymore (black screen) and I have to reboot the PC in order to be able to play again. Also Alt+Tabbing freezes it to black screen as well, but that can be workarounded by not Alt+Tabbing.
Side-note: I play in offline mode.
EDIT: restarting X allows me to play again. Still annoying, but less so.

Same here, nvidia 450.57-5 / GTX1070, linux 5.7.11.arch1-1

Steam overlay cannot be disabled on Linux (which would solve the problem):
https://github.com/ValveSoftware/steam-for-linux/issues/3239

However, I don't need to restart X. $ kill $(pgrep DOOM) is enough and I can simply restart the game from steam.

You guys need to definitely bring this to Nvidia's attention. Despite their reputation, they actually do seem to do a decent job with fixing stuff like that with an update.

Because it definitely seems like this is an Nvidia-specific issue, I have an AMD GPU and I don't see this at all. I do use a custom version of Proton with fshack re-enabled, I don't know if it's disabled on vanilla Proton or not (I know it's disabled on the recent versions of GE's Proton). Maybe that's part of it, too. But that can be solved by determining whether the proton builds you all are using contains the fshack patches or not.

But yeah, I played for about 5 hours last night and got a few achievements and they all worked exactly as they were supposed to. And unless it's a big coincidence that it seems to just affect Nvidia users (at least as of late), it sounds like a driver issue. Either that, or it is the fshack thing, or potentially a desktop environment thing.

In the ProtonDB about Rage 2, I read about very similar reports that tab/overlay freezes the game. Rage 2 is based on an older idTech engine. The solution seems to be to set AsyncComputeDisable to 1 in the settings.ini. Maybe there is something equivalent in Doom Eternal?

nvidia 450.57-6 GTX 1060 6GB
kernel 5.7.12-arch1-1

Game is freezing whenever there is a Steam overlay popup. Now, I don't understand why because I disabled Steam overlay, yet it still shows something like achievement and freezes the game. Afterwards, game won't start anymore (black screen) and I have to reboot the PC in order to be able to play again. Also Alt+Tabbing freezes it to black screen as well, but that can be workarounded by not Alt+Tabbing.
Side-note: I play in offline mode.
EDIT: restarting X allows me to play again. Still annoying, but less so.

Same here, kernel is 5.7.12-24-tkg-pds, Nvidia RTX 2060, any ideas how to fix alt+tab issue?
Game is literally unplayable, because any achievement will bring up steam overlay thus making game freeze. I am also using bordered window, but actually no diff between fullscreen and bordered window, freezing on both modes.

In the ProtonDB about Rage 2, I read about very similar reports that tab/overlay freezes the game. Rage 2 is based on an older idTech engine. The solution seems to be to set AsyncComputeDisable to 1 in the settings.ini. Maybe there is something equivalent in Doom Eternal?

There is similar option in doom, i have it disabled, so this is not the case =(

nvidia 450.57-6 GTX 1060 6GB
kernel 5.7.12-arch1-1
Game is freezing whenever there is a Steam overlay popup. Now, I don't understand why because I disabled Steam overlay, yet it still shows something like achievement and freezes the game. Afterwards, game won't start anymore (black screen) and I have to reboot the PC in order to be able to play again. Also Alt+Tabbing freezes it to black screen as well, but that can be workarounded by not Alt+Tabbing.
Side-note: I play in offline mode.
EDIT: restarting X allows me to play again. Still annoying, but less so.

Same here, kernel is 5.7.12-24-tkg-pds, Nvidia RTX 2060, any ideas how to fix alt+tab issue?
Game is literally unplayable, because any achievement will bring up steam overlay thus making game freeze. I am also using bordered window, but actually no diff between fullscreen and bordered window, freezing on both modes.

Would you be kind to attempt the workaround below to disable steam overlay notifications and see how that affects Doom Eternal, I have unfortunately almost all single player achievements and cannot check if the workaround fixes anything.

https://steamcommunity.com/discussions/forum/1/617329920710103124/

Workarounds are great (if they work) for actually getting through a game,
but this is a CLEAR case of a driver issue that needs to be reported. Has
anyone reported this to Nvidia?

Would you be kind to attempt the workaround below to disable steam overlay notifications and see how that affects Doom Eternal, I have unfortunately almost all single player achievements and cannot check if the workaround fixes anything.

https://steamcommunity.com/discussions/forum/1/617329920710103124/

As I already wrote, disabling steam overlay on Linux is not possible due to this six years old bug:
https://github.com/ValveSoftware/steam-for-linux/issues/3239

This would be the easiest solution but no...

Would you be kind to attempt the workaround below to disable steam overlay notifications and see how that affects Doom Eternal, I have unfortunately almost all single player achievements and cannot check if the workaround fixes anything.
https://steamcommunity.com/discussions/forum/1/617329920710103124/

As I already wrote, disabling steam overlay on Linux is not possible due to this six years old bug:
ValveSoftware/steam-for-linux#3239

This would be the easiest solution but no...

It is not the overlay that's the problem, it's the notifications. The workaround above should remove the notifications from displaying, at least in theory, thus making DE at least playable for nvidia users in the meantime. However, I cannot test the effect this has on DE because I have most of the achievements anyway.

Would you be kind to attempt the workaround below to disable steam overlay notifications and see how that affects Doom Eternal, I have unfortunately almost all single player achievements and cannot check if the workaround fixes anything.
https://steamcommunity.com/discussions/forum/1/617329920710103124/

As I already wrote, disabling steam overlay on Linux is not possible due to this six years old bug:
ValveSoftware/steam-for-linux#3239
This would be the easiest solution but no...

It is not the overlay that's the problem, it's the notifications. The workaround above should remove the notifications from displaying, at least in theory, thus making DE at least playable for nvidia users in the meantime. However, I cannot test the effect this has on DE because I have most of the achievements anyway.

Sorry, I didn't read through your link and thought it just explains how to disable the overlay in the menu options.

I just tried it and it really works! Thank you!

Would you be kind to attempt the workaround below to disable steam overlay notifications and see how that affects Doom Eternal, I have unfortunately almost all single player achievements and cannot check if the workaround fixes anything.
https://steamcommunity.com/discussions/forum/1/617329920710103124/

As I already wrote, disabling steam overlay on Linux is not possible due to this six years old bug:
ValveSoftware/steam-for-linux#3239
This would be the easiest solution but no...

It is not the overlay that's the problem, it's the notifications. The workaround above should remove the notifications from displaying, at least in theory, thus making DE at least playable for nvidia users in the meantime. However, I cannot test the effect this has on DE because I have most of the achievements anyway.

Sorry, I didn't read through your link and thought it just explains how to disable the overlay in the menu options.

I just tried it and it really works! Thank you!

Now please report this to Nvidia so there's actually a chance of something being done about it.

nvidia 450.57-6 GTX 1060 6GB
kernel 5.7.12-arch1-1
Game is freezing whenever there is a Steam overlay popup. Now, I don't understand why because I disabled Steam overlay, yet it still shows something like achievement and freezes the game. Afterwards, game won't start anymore (black screen) and I have to reboot the PC in order to be able to play again. Also Alt+Tabbing freezes it to black screen as well, but that can be workarounded by not Alt+Tabbing.
Side-note: I play in offline mode.
EDIT: restarting X allows me to play again. Still annoying, but less so.

Same here, kernel is 5.7.12-24-tkg-pds, Nvidia RTX 2060, any ideas how to fix alt+tab issue?
Game is literally unplayable, because any achievement will bring up steam overlay thus making game freeze. I am also using bordered window, but actually no diff between fullscreen and bordered window, freezing on both modes.

Would you be kind to attempt the workaround below to disable steam overlay notifications and see how that affects Doom Eternal, I have unfortunately almost all single player achievements and cannot check if the workaround fixes anything.

https://steamcommunity.com/discussions/forum/1/617329920710103124/

Thank you, I can confirm that this workaround worked for me.

@roman-bronis & @Sha1rath

it might be wise to leave a review in protondb for DE and mention the steam notifications workaround with the link to the guide. I've already done this in hopes that it would be useful to more Linux users with nvidia gpus.

Thanks for your patience.

@roman-bronis & @Sha1rath

it might be wise to leave a review in protondb for DE and mention the steam notifications workaround with the link to the guide. I've already done this in hopes that it would be useful to more Linux users with nvidia gpus.

Thanks for your patience.

Great idea, done!

About reporting this to NVidia, I personally am not in the position to give them a proper description of the problem. It would need detailed logs or traces rather than saying "someone said it doesn't happen on his AMD".

nvidia 450.57-6 GTX 1060 6GB
kernel 5.7.12-arch1-1
Game is freezing whenever there is a Steam overlay popup. Now, I don't understand why because I disabled Steam overlay, yet it still shows something like achievement and freezes the game. Afterwards, game won't start anymore (black screen) and I have to reboot the PC in order to be able to play again. Also Alt+Tabbing freezes it to black screen as well, but that can be workarounded by not Alt+Tabbing.
Side-note: I play in offline mode.
EDIT: restarting X allows me to play again. Still annoying, but less so.

Same here, kernel is 5.7.12-24-tkg-pds, Nvidia RTX 2060, any ideas how to fix alt+tab issue?
Game is literally unplayable, because any achievement will bring up steam overlay thus making game freeze. I am also using bordered window, but actually no diff between fullscreen and bordered window, freezing on both modes.

Would you be kind to attempt the workaround below to disable steam overlay notifications and see how that affects Doom Eternal, I have unfortunately almost all single player achievements and cannot check if the workaround fixes anything.
https://steamcommunity.com/discussions/forum/1/617329920710103124/

Thank you, I can confirm that this workaround worked for me.

U can now alt+tab out of the game? Or this just fixed the notification issue only ?

nvidia 450.57-6 GTX 1060 6GB
kernel 5.7.12-arch1-1
Game is freezing whenever there is a Steam overlay popup. Now, I don't understand why because I disabled Steam overlay, yet it still shows something like achievement and freezes the game. Afterwards, game won't start anymore (black screen) and I have to reboot the PC in order to be able to play again. Also Alt+Tabbing freezes it to black screen as well, but that can be workarounded by not Alt+Tabbing.
Side-note: I play in offline mode.
EDIT: restarting X allows me to play again. Still annoying, but less so.

Same here, kernel is 5.7.12-24-tkg-pds, Nvidia RTX 2060, any ideas how to fix alt+tab issue?
Game is literally unplayable, because any achievement will bring up steam overlay thus making game freeze. I am also using bordered window, but actually no diff between fullscreen and bordered window, freezing on both modes.

Would you be kind to attempt the workaround below to disable steam overlay notifications and see how that affects Doom Eternal, I have unfortunately almost all single player achievements and cannot check if the workaround fixes anything.
https://steamcommunity.com/discussions/forum/1/617329920710103124/

Thank you, I can confirm that this workaround worked for me.

U can now alt+tab out of the game? Or this just fixed the notification issue only ?

I just checked the notification issue, already that was fun because I had all the "easy" achievements. I don't think this is solving Alt+Tab issue but you will need to check on your own (sorry, I'm not going to install this huge game for 3rd time ;) ).

nvidia 450.57-6 GTX 1060 6GB
kernel 5.7.12-arch1-1
Game is freezing whenever there is a Steam overlay popup. Now, I don't understand why because I disabled Steam overlay, yet it still shows something like achievement and freezes the game. Afterwards, game won't start anymore (black screen) and I have to reboot the PC in order to be able to play again. Also Alt+Tabbing freezes it to black screen as well, but that can be workarounded by not Alt+Tabbing.
Side-note: I play in offline mode.
EDIT: restarting X allows me to play again. Still annoying, but less so.

Same here, kernel is 5.7.12-24-tkg-pds, Nvidia RTX 2060, any ideas how to fix alt+tab issue?
Game is literally unplayable, because any achievement will bring up steam overlay thus making game freeze. I am also using bordered window, but actually no diff between fullscreen and bordered window, freezing on both modes.

Would you be kind to attempt the workaround below to disable steam overlay notifications and see how that affects Doom Eternal, I have unfortunately almost all single player achievements and cannot check if the workaround fixes anything.
https://steamcommunity.com/discussions/forum/1/617329920710103124/

Thank you, I can confirm that this workaround worked for me.

U can now alt+tab out of the game? Or this just fixed the notification issue only ?

It only temporarily fixes the notification issue by removing all steam notifications in-game until nvidia deals with the bug in the drivers, assuming that it even is a driver bug. I managed to check this on my game yesterday and it works.

Hello there! Just got back into playing DOOM Eternal again and I'm facing some performance issues.

On a RX 5700 XT with Mesa 20.1.4 and ACO enabled on the launch settings, I get 70 - 120FPS playing on max settings with V-Sync on and Freesync activated.

With the same card, using the latest AMDGPU-PRO drivers and Freesync also activated I get consistent 144FPS when playing the game with V-Sync set to Triple Buffering (On and AUTO caps the frame rate at 72FPS outside of menus for some reason). But the PRO drivers makes blood looks like it have some kind of metallic rainbow effect.

From what I could found, the major performance issues with DOOM Eternal are already fixed on Mesa at least since 20.1.1, could the issue be somewhere else?

Don't know if it is worth mentioning, but I noticed that when using the PRO drivers, the Vulkan version reported by both DOOM and MangoHud is 1.2.139, while with Mesa 20.1.4, it reports 1.2.131 (my system have the latest available at Solus repos, version 1.2.141.0). Corectrl also reports the Vulkan API Version as being 1.2.131.

Hi, I've been having trouble with getting Doom Eternal to launch, after what feels like an age of it saying "Running", it eventually gives up and closes. I checked the log file from PROTON_LOG=1 %command%, was presently surprised when it said it was 3GB in size.

Looks like some script at startup is looping infinitely, eventually terminating with a StackOverflowException, so maybe recursion?

With some expert grepping for the term "exception", I found a repeating pattern of the following snippet in the log:

10394444:15734.269:002b:002c:trace:seh:NtRaiseException code=c0000005 flags=0 addr=0x7bc8ffc0 ip=7bc8ffc0 tid=002c
10394445:15734.269:002b:002c:trace:seh:NtRaiseException  info[0]=0000000000000000
10394446:15734.269:002b:002c:trace:seh:NtRaiseException  info[1]=ffffffffffffffff
10394447:15734.269:002b:002c:trace:seh:NtRaiseException  rax=000000007bc8ffc0 rbx=0000000000579aa0 rcx=fffffffffffc1bbc rdx=0010988c683ffff0
10394448:15734.269:002b:002c:trace:seh:NtRaiseException  rsi=0000000000000004 rdi=00000000005793d0 rbp=0000000000000005 rsp=0000000000577148
10394449:15734.269:002b:002c:trace:seh:NtRaiseException   r8=0000000000000000  r9=0000000000576d90 r10=0000000000000020 r11=0000000000000246
10394450:15734.269:002b:002c:trace:seh:NtRaiseException  r12=00000000005793d0 r13=0010988c68400010 r14=0000000000577198 r15=00000000005771a0

The number 10394444 is the line number, if you're wondering.

Running the command grep code=c0000005 steam-782330.log | wc -l gave me the number of times this loop happened, which was 290 (290 times too many).

System Info:

• Debian 10 Buster
• Nvidia Driver v450.66, RTX 2070
• Proton 5.0.9

I have played Doom Eternal successfully before on Linux, and then have not played in since a while (at least a month, probably longer). In the meantime, I think there were couple of updates of Doom, but also on my Ubuntu system, including new Nvidia drivers, etc.

Now I just wanted to play again, and it does not start. I see the id logo in systray, then screen gets black, and then I get back to the desktop, without any error.

This is with Proton 5.0, what I used before (just the standard installation, but with "PROTON_NO_ESYNC": "1" in the user_settings.py file).

I also tried with the new Proton 5.13, as I read some reports here that it runs even better now, and also the alt-tab issue is resolved. However, I get the same behavior, i.e. I see the id logo in systray, then black screen, then back to desktop.

======================
Proton: 1602709129 proton-5.13-1b
SteamGameId: 782330
Command: ['/mnt/zfs/SteamLibrary/steamapps/common/DOOMEternal/idTechLauncher.exe', '+com_skipIntroVideo', '1', '+in_terminal', '1']
Options: {'noesync', 'seccomp', 'forcelgadd'}
======================
ERROR: ld.so: object '/home/az/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/az/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
ERROR: ld.so: object '/home/az/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
ERROR: ld.so: object '/home/az/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
wineserver: using server-side synchronization.
ERROR: ld.so: object '/home/az/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
133049.882:0028:002c:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\ntdll.dll" at 000000007BC00000: builtin
133049.883:0028:002c:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\kernelbase.dll" at 000000007B000000: builtin
...
133050.864:00c4:00c8:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\winex11.drv" at 00007FB7A2120000: builtin
133050.878:00c4:00c8:fixme:heap:RtlSetHeapInformation 0000000000010000 0 000000000091C710 4 stub
133050.879:00c4:00c8:warn:debugstr:OutputDebugStringA "Winsock Initialized\n"
133050.879:00c4:00c8:trace:seh:dispatch_exception code=40010006 flags=0 addr=000000007B010E0E ip=7b010e0e tid=00c8
133050.879:00c4:00c8:trace:seh:dispatch_exception  info[0]=0000000000000015
133050.879:00c4:00c8:trace:seh:dispatch_exception  info[1]=0000000000914640
133050.879:00c4:00c8:trace:seh:dispatch_exception  rax=0000000000914060 rbx=000000003fff8000 rcx=0000000000914040 rdx=0000000000000000
133050.879:00c4:00c8:trace:seh:dispatch_exception  rsi=0000000000914140 rdi=0000000000914070 rbp=0000000000914480 rsp=0000000000914020
133050.879:00c4:00c8:trace:seh:dispatch_exception   r8=0000000000000002  r9=0000000000914130 r10=000000007b666fb4 r11=0000000000000246
133050.879:00c4:00c8:trace:seh:dispatch_exception  r12=0000000000000001 r13=0000000000000001 r14=0000000000006e5c r15=000000000091c6d8
133050.879:00c4:00c8:trace:seh:call_vectored_handlers calling handler at 000000007B636150 code=40010006 flags=0
133050.879:00c4:00c8:trace:seh:call_vectored_handlers handler at 000000007B636150 returned 0
133050.879:00c4:00c8:trace:seh:RtlVirtualUnwind type 1 rip 7b010e0e rsp 914020
133050.879:00c4:00c8:trace:seh:dump_unwind_info **** func 10dc0-10e47
133050.879:00c4:00c8:trace:seh:dump_unwind_info unwind info at 000000007B0A1394 flags 0 prolog 0x11 bytes function 000000007B010DC0-000000007B010E47
133050.879:00c4:00c8:trace:seh:dump_unwind_info     0x11: subq $0xc8,%rsp
133050.879:00c4:00c8:trace:seh:dump_unwind_info     0xa: pushq %rsi
133050.879:00c4:00c8:trace:seh:dump_unwind_info     0x9: pushq %rdi
133050.879:00c4:00c8:trace:seh:dwarf_virtual_unwind function 7b638140 base 0x7b637e28 cie 0x7b67c810 len 14 id 0 version 1 aug 'zR' code_align 1 data_align -8 retaddr %rip
...
133057.159:00d0:00d4:trace:seh:RtlRestoreContext returning to 7b661c46 stack 8e88a0
resource invalid:image:models/customization/characters/doomslayer/set56/doomslayer_arm_left_set56_sss.tga$streamed$mtlkind=sssmask:NONE is stale: defaulting
133057.160:00d0:00d4:warn:debugstr:OutputDebugStringA "resource generated:image:models/customization/characters/doomslayer/set56/doomslayer_arm_right_set56_sss.tga$streamed$mtlkind=sssmask:NONE is stale: entry(s) not found\n"
133057.160:00d0:00d4:trace:seh:dispatch_exception code=40010006 flags=0 addr=000000007B010E0E ip=7b010e0e tid=00d4
133057.160:00d0:00d4:trace:seh:dispatch_exception  info[0]=00000000000000a9
...
WARNING: idBroadcastManager::ReleaseBroadcastEvent called with out of range system ID [65535]
Fossilize ERROR: Error: pNext in VkSamplerCreateInfo not supported. (pNext->sType chain: [1000130001])
Fossilize ERROR: Failed to record sampler.
Fossilize ERROR: Error: pNext in VkSamplerCreateInfo not supported. (pNext->sType chain: [1000130001])
Fossilize ERROR: Failed to record sampler.
Fossilize ERROR: Error: pNext in VkSamplerCreateInfo not supported. (pNext->sType chain: [1000130001])
Fossilize ERROR: Failed to record sampler.
Fossilize ERROR: Error: pNext in VkSamplerCreateInfo not supported. (pNext->sType chain: [1000130001])
Fossilize ERROR: Failed to record sampler.
133879.298:00d0:00d4:trace:seh:sigsys_handler SIGSYS, rax 0xf086, rip 0x14f92df98
....
133057.309:00d0:00d4:trace:seh:RtlRestoreContext returning to 7b661c46 stack 8e9780
WARNING: image:fonts/square721_ex_tl/64_df.tga$alpha$streamed$nomips:NONE can't generate in production while loading image:fonts/square721_ex_tl/64_df.tga$alpha$streamed$nomips from edit.Parms from material2:fontfx/square721/outline/normal/black
133057.310:00d0:00d4:warn:debugstr:OutputDebugStringA "resource invalid:image:fonts/square721_ex_tl/64_df.tga$alpha$streamed$nomips:NONE is stale: defaulting\n"
WARNING: generated/decls/material2/lights/analytical/point/point_p25.decl - ParmBlock Parse Warning : Invalid RenderParm Name lightfalloff while loading edit.Parms from material2:lights/analytical/point/point_p25
133881.461:00d0:01b8:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\crypt32.dll" at 00007FA113A10000: builtin
133881.463:00d0:01b8:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\dnsapi.dll" at 00007FA150020000: builtin
133881.463:00d0:01b8:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\netapi32.dll" at 00007FA150050000: builtin
133881.463:00d0:01b8:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\secur32.dll" at 00007FA150090000: builtin
133881.477:00d0:01b8:err:winediag:SECUR32_initNTLMSP ntlm_auth was not found or is outdated. Make sure that ntlm_auth >= 3.0.25 is in your path. Usually, you can find it in the winbind package of your distribution.
133881.488:00d0:00d4:warn:debugstr:OutputDebugStringA "WARNING: generated/decls/material2/lights/analytical/point/point_p75.decl - ParmBlock Parse Warning : Invalid RenderParm Name lightfalloff while loading edit.perkFamilies.item.base.edit.disablePerkWhenActivated.edit.upgrades.item.edit.modifiersWeapon.item.data.valueDecl.edit.weaponFX.edit.e"...
...
133058.022:01c4:01c8:fixme:wbemprox:wbem_services_CreateInstanceEnum unsupported flags 0x00000030
133058.029:01c4:01c8:fixme:wbemprox:enum_class_object_Next timeout not supported
info:  Game: dxdiag.exe
info:  DXVK: v1.7.2-4-g280cd4b4
info:  Built-in extension providers:
info:    Win32 WSI
info:    OpenVR
133058.039:01c4:01c8:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\shcore.dll" at 0000000064940000: builtin
133058.039:01c4:01c8:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\shlwapi.dll" at 0000000068A40000: builtin
133058.039:01c4:01c8:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\SHELL32.dll" at 00007F37BE260000: builtin
133058.039:01c4:01c8:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\openvr_api_dxvk.dll" at 0000000180000000: native
133058.040:01c4:01c8:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\api-ms-win-core-synch-l1-2-0.dll" at 000000006E340000: builtin
133058.040:01c4:01c8:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\api-ms-win-core-fibers-l1-1-1.dll" at 000000006B880000: builtin
133058.041:01c4:01c8:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\api-ms-win-core-localization-l1-2-1.dll" at 000000006E6C0000: builtin
133058.041:01c4:01c8:trace:seh:NtQueryInformationThread (0xfffffffffffffffe,1,0x31c6e0,20,(nil))
warn:  OpenVR: Failed to initialize OpenVR
info:  Enabled instance extensions:
info:    VK_KHR_get_surface_capabilities2
info:    VK_KHR_surface
info:    VK_KHR_win32_surface
warn:  D3D9: VK_FORMAT_D16_UNORM_S8_UINT -> VK_FORMAT_D24_UNORM_S8_UINT
warn:  D3D9: VK_FORMAT_A4R4G4B4_UNORM_PACK16_EXT -> VK_FORMAT_B4G4R4A4_UNORM_PACK16
info:  GeForce RTX 2070:
info:    Driver: 450.80.2
info:    Vulkan: 1.2.133
info:    Memory Heap[0]: 
info:      Size: 8192 MiB
info:      Flags: 0x1
info:      Memory Type[7]: Property Flags = 0x1
info:    Memory Heap[1]: 
info:      Size: 24070 MiB
info:      Flags: 0x0
info:      Memory Type[0]: Property Flags = 0x0
info:      Memory Type[1]: Property Flags = 0x0
info:      Memory Type[2]: Property Flags = 0x0
info:      Memory Type[3]: Property Flags = 0x0
info:      Memory Type[4]: Property Flags = 0x0
info:      Memory Type[5]: Property Flags = 0x0
info:      Memory Type[6]: Property Flags = 0x0
info:      Memory Type[8]: Property Flags = 0x6
info:      Memory Type[9]: Property Flags = 0xe
info:    Memory Heap[2]: 
info:      Size: 246 MiB
info:      Flags: 0x1
info:      Memory Type[10]: Property Flags = 0x7
info:  Process set as DPI aware
133058.165:01c4:01c8:fixme:ddraw:ddraw7_Initialize Ignoring guid {baafeb00-00eb-69ee-eba0-3c804c97f796}.
133058.166:01c4:01c8:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\dxvk_config.dll" at 0000000069040000: native
133058.167:01c4:01c8:trace:seh:NtQueryInformationThread (0x98,0,0x31c8d0,30,(nil))
133058.186:01c4:01cc:trace:seh:NtQueryInformationThread (0xfffffffffffffffe,12,0xe8fc30,4,(nil))
...
133058.252:01c4:01c8:err:winediag:MIDIMAP_drvOpen No software synthesizer midi port found, Midi sound output probably won't work.
133058.254:00d0:01c0:trace:seh:NtQueryInformationThread (0xfffffffffffffffe,12,0x380afc50,4,(nil))
133058.257:01c4:01c8:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\dxdiagn.dll" : builtin
133058.257:01c4:01c8:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\d3d9.dll" : native
133058.257:01c4:01c8:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\vulkan-1.dll" : builtin
133058.257:01c4:01c8:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\devenum.dll" : builtin
133058.257:01c4:01c8:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\msdmo.dll" : builtin
133058.257:01c4:01c8:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\avicap32.dll" : builtin
133058.257:01c4:01c8:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\quartz.dll" : builtin
Unable to read VR Path Registry from C:\users\steamuser\Local Settings\Application Data\openvr\openvrpaths.vrpath
133058.342:00c4:00cc:trace:seh:NtQueryInformationThread (0x1c4,0,0x1c15f50,30,(nil))
133058.342:00c4:00cc:trace:seh:NtQueryInformationThread (0x1c4,0,0x1c15f50,30,(nil))
133058.343:00c4:00cc:trace:seh:NtQueryInformationThread (0x1c4,0,0x1c15f50,30,(nil))
...
133058.351:00c4:00cc:trace:seh:NtQueryInformationThread (0x1c4,0,0x1c15f50,30,(nil))
133058.351:00c4:00cc:fixme:dbghelp:fetch_thread_info Couldn't open thread 448 (87)
133063.612:00c4:00cc:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\lsteamclient.dll" at 00007FB7A14C0000: builtin
133063.612:00c4:00cc:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\lsteamclient.dll" : builtin
133074.355:00c4:00cc:warn:debugstr:OutputDebugStringA "Wrote minidump to Crash.dmp.\n"
...
133074.950:00c4:00c8:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFFFFFFFFFA, 000000000091F960
133075.960:003c:0070:trace:seh:NtQueryInformationThread (0xfffffffffffffffe,12,0x119fda0,4,(nil))
133075.960:0058:0080:trace:seh:NtQueryInformationThread (0xfffffffffffffffe,12,0x17dfda0,4,(nil))
133075.961:0084:0094:trace:seh:NtQueryInformationThread (0xfffffffffffffffe,12,0xf9fda0,4,(nil))
133076.062:0030:008c:trace:seh:NtQueryInformationThread (0xfffffffffffffffe,12,0x13cfda0,4,(nil))
133076.062:0030:01e8:trace:seh:NtQueryInformationThread (0xfffffffffffffffe,12,0x1c0fda0,4,(nil))
pid 103640 != 103639, skipping destruction (fork without exec?)

(I don't really know what is relevant from this. I hope it contains some relevant information...)

Edit Strangely, after a restart of my PC, it runs now correctly. I still have the alt+tab issue (i.e. alt+tab, or any overlay occurring within the game will freeze the graphics) but it runs very well otherwise. Maybe even better (smoother, faster) than before, but I don't know. But I mostly hoped that the alt+tab issue would be fixed. I'm using borderless window, as this is what I read somewhere.

Now I also have a log file in comparison from a correct run.

======================
Proton: 1602709129 proton-5.13-1b
SteamGameId: 782330
Command: ['/mnt/zfs/SteamLibrary/steamapps/common/DOOMEternal/idTechLauncher.exe', '+com_skipIntroVideo', '1', '+in_terminal', '1']
Options: {'forcelgadd', 'seccomp', 'noesync'}
======================
ERROR: ld.so: object '/home/az/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/az/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
ERROR: ld.so: object '/home/az/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
ERROR: ld.so: object '/home/az/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
wineserver: using server-side synchronization.
ERROR: ld.so: object '/home/az/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
453.258:0028:002c:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\ntdll.dll" at 000000007BC00000: builtin
453.259:0028:002c:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\kernelbase.dll" at 000000007B000000: builtin
453.259:0028:002c:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\kernel32.dll" at 000000007B610000: builtin
453.259:0028:002c:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\wineboot.exe" at 0000000000400000: builtin
453.259:0028:002c:trace:seh:check_bpf_jit_enable enabled 0x31.
453.261:0028:002c:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\ucrtbase.dll" at 00007F6EB0C90000: builtin
453.261:0028:002c:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\sechost.dll" at 0000000061900000: builtin
453.261:0028:002c:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\advapi32.dll" at 00007F6EB0EB0000: builtin
ERROR: ld.so: object '/home/az/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
...
454.245:00c4:00c8:fixme:heap:RtlSetHeapInformation 0000000000010000 0 000000000091C710 4 stub
454.246:00c4:00c8:warn:debugstr:OutputDebugStringA "Winsock Initialized\n"
454.246:00c4:00c8:trace:seh:dispatch_exception code=40010006 flags=0 addr=000000007B010E0E ip=7b010e0e tid=00c8
454.246:00c4:00c8:trace:seh:dispatch_exception  info[0]=0000000000000015
454.246:00c4:00c8:trace:seh:dispatch_exception  info[1]=0000000000914640
454.246:00c4:00c8:trace:seh:dispatch_exception  rax=0000000000914060 rbx=000000003fff8000 rcx=0000000000914040 rdx=0000000000000000
454.246:00c4:00c8:trace:seh:dispatch_exception  rsi=0000000000914140 rdi=0000000000914070 rbp=0000000000914480 rsp=0000000000914020
454.246:00c4:00c8:trace:seh:dispatch_exception   r8=0000000000000002  r9=0000000000914130 r10=000000007b666fb4 r11=0000000000000246
454.246:00c4:00c8:trace:seh:dispatch_exception  r12=0000000000000001 r13=0000000000000001 r14=0000000000006e5c r15=000000000091c6d8
...
460.388:00d0:00d4:trace:seh:RtlRestoreContext returning to 7b661c46 stack 8e88a0
resource invalid:image:models/customization/characters/doomslayer/set56/doomslayer_arm_left_set56_sss.tga$streamed$mtlkind=sssmask:NONE is stale: defaulting
460.389:00d0:00d4:warn:debugstr:OutputDebugStringA "resource generated:image:models/customization/characters/doomslayer/set56/doomslayer_arm_right_set56_sss.tga$streamed$mtlkind=sssmask:NONE is stale: entry(s) not found\n"
460.389:00d0:00d4:trace:seh:dispatch_exception code=40010006 flags=0 addr=000000007B010E0E ip=7b010e0e tid=00d4
...
WARNING: idBroadcastManager::ReleaseBroadcastEvent called with out of range system ID [65535]
Fossilize ERROR: Error: pNext in VkSamplerCreateInfo not supported. (pNext->sType chain: [1000130001])
Fossilize ERROR: Failed to record sampler.
Fossilize ERROR: Error: pNext in VkSamplerCreateInfo not supported. (pNext->sType chain: [1000130001])
Fossilize ERROR: Failed to record sampler.
Fossilize ERROR: Error: pNext in VkSamplerCreateInfo not supported. (pNext->sType chain: [1000130001])
Fossilize ERROR: Failed to record sampler.
Fossilize ERROR: Error: pNext in VkSamplerCreateInfo not supported. (pNext->sType chain: [1000130001])
Fossilize ERROR: Failed to record sampler.
458.024:00d0:00d4:trace:seh:sigsys_handler SIGSYS, rax 0xf086, rip 0x14f92df98.
458.119:00d0:00d4:fixme:bcrypt:BCryptCreateHash ignoring object buffer
458.289:00d0:00d4:warn:debugstr:OutputDebugStringA "Executing default.cfg for device #0...\n"
...
WARNING:  SWF swf/main_menu/screens/master_levels.swf CreateSWFDependencies defaulted on image textures/swf_images/milestones/hud_slayer_challenge_progbar_milestone_back.png while loading loadBinary:swf/main_menu/screens/master_levels.swf from cswf:swf/main_menu/screens/master_levels.swf
460.529:00d0:00d4:warn:debugstr:OutputDebugStringA "resource generated:image:fonts/square721_ex_tl/64_df.tga$alpha$streamed$nomips:NONE is stale: entry(s) not found\n"
...
459.711:00d0:00f4:fixme:bcrypt:BCryptCreateHash ignoring object buffer
459.711:00d0:00f4:fixme:bcrypt:BCryptCreateHash ignoring object buffer
459.717:00d0:00d4:warn:debugstr:OutputDebugStringA "WARNING: generated/decls/material2/template/light.decl - ParmBlock Parse Warning : Invalid RenderParm Name lightfalloff while loading edit.Parms from material2:template/light\n"
...
463.834:00d0:00d4:trace:seh:RtlRestoreContext returning to 7b661c46 stack 90bba0
during DOOMEternal initialization...
463.835:00d0:00d4:warn:debugstr:OutputDebugStringA "WARNING: idBroadcastManager::ReleaseBroadcastEvent called with out of range system ID [65535]\n"
...

From that new log, I could not find these parts from the old log:

133058.022:01c4:01c8:fixme:wbemprox:wbem_services_CreateInstanceEnum unsupported flags 0x00000030
133058.029:01c4:01c8:fixme:wbemprox:enum_class_object_Next timeout not supported
info:  Game: dxdiag.exe
...
warn:  OpenVR: Failed to initialize OpenVR
...

But I assume this is all already part of the error handling, the crash handler, which collects some information about my system. So this is probably not relevant. So basically I don't know which part of the (first) log is relevant for the error I had.

Hello,

Doom Eternal freezes on Loading screen.

steam-782330.zip

Here's the log file. As it too big I had to zip it.

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model       : 94
model name  : Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
stepping    : 3

NVIDIA Corporation TU104 [GeForce RTX 2080 Rev. A] (rev a1)

nvidia 455.28-7
Vulkan Instance Version: 1.2.153

I just tried it with Proton 5.13-1 and mouse wheel tilting is not recognized by the game anymore. Works again after going back to 5.09.

Hello @Sha1rath, for clarity, are you referring to horizontal scrolling events on your mouse? What model mouse are you using?

Usually I'd ask for a Proton log to go along with the regression, but I don't think that would reveal anything interesting without some addtional logging turned on.

@kisak-valve Yes, horizontal scrolling by tilting the mouse wheel (called tilt-wheel or 4D-wheel).
I am using a Roccat Kone AIMO Remastered.
In game, the tilt buttons are recognized as "Mouse 4" and "Mouse 5", xev outputs them as "button 6" and "button 7".
I tried rebinding it in the game because I assumed maybe the keycodes just changed, but when assigning a new key in the settings menu, when I tilt the wheel it keeps showing "press new key" (or so). The game totally doesn't notice.

About the log: I also assumed that an input event not being recognized would not log anything.

By the way, as my mouse has a lot of buttons (12 if you count all wheel directions), I realized that many of the buttons don't work in proton. The mouse can bind its own buttons to keyboard inputs, which I did as a workaround. Would be nice to see all mouse buttons working without binding keyboard macros to them in the mouse itself. However, the only change I noticed was about the tilt wheel (which I don't want to assign with keyboard macros because it would disable horizontal scrolling in my Linux desktop)...

@Sha1rath Could you get a log with +x11drv,+x11settings,+event,+cursor,+win,+message as additional logging channels on both 5.0-9 where it is working and 5.13-1 where it fails?

Here are the logs:
DoomEternalProtonLogs.tar.gz

And here is what I did when logging them:

Both

• Start Game
• Go to controls customization menu
• Click right field of combat shotgun bindings
• Tilt wheel left

Proton 5.13

• Nothing happens, press new key prompt does not disappear
• Tilt wheel right
• Nothing happens, press new key prompt does not disappear

Proton 5.0-9

• Shotgun gets assigned and is shown as mouse button 4
• Click right field of heavy cannon bindings
• Tilt wheel right
• Cannon gets assigned and is shown as mouse button 5

Both

• Repeatedly press ESC to leave settings menu and exit game

Thank you very much for addressing this.

P.S.: I just tried Dying Light and there I have the same problem: Tilt wheel works in Proton 5.0-9 but not in 5.13. So it is not likely just a Doom Eternal specific problem.

Hi there! Just got the game during the sale. Tab key (For the inventory and stuff) is not working for me. I would swear it was working during the first mission but then nothing, even on the menus... Anyone else?

Hello @Sha1rath, by Proton developer request, I've transferred your recent scroll wheel input feedback to #4341 because it does not appear to be a game-specific issue.

Hi there! Just got the game during the sale. Tab key (For the inventory and stuff) is not working for me. I would swear it was working during the first mission but then nothing, even on the menus... Anyone else?

Try pressing left alt. That should also bring up that same menu, and then you should be able to use Tab again.

It happens to me when I alt-tab out while playing the game. Once I alt-tab back in, I have to use alt one time to get tab to work again.

Even if you didn't alt-tab, try it anyway.

Hello,

Doom Eternal freezes on Loading screen.

steam-782330.zip

Here's the log file. As it too big I had to zip it.

processor : 0
vendor_id : GenuineIntel
cpu family    : 6
model     : 94
model name    : Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
stepping  : 3

NVIDIA Corporation TU104 [GeForce RTX 2080 Rev. A] (rev a1)

nvidia 455.28-7
Vulkan Instance Version: 1.2.153

I'm having this same issue, were you able to get it working? I'm also on a 2080, nvidia 455.34.01

No I have not 😔

On Tue, Nov 3, 2020, 22:45 George Gibbs notifications@github.com wrote:

Hello,

Doom Eternal freezes on Loading screen.

steam-782330.zip
https://github.com/ValveSoftware/Proton/files/5432527/steam-782330.zip

Here's the log file. As it too big I had to zip it.

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 94
model name : Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
stepping : 3

NVIDIA Corporation TU104 [GeForce RTX 2080 Rev. A] (rev a1)

nvidia 455.28-7
Vulkan Instance Version: 1.2.153

I'm having this same issue, were you able to get it working? I'm also on a
2080, nvidia 455.34.01

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-721245884,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAIQWG4SS2O2J7DNOMY7YTSOAXTPANCNFSM4MI6DHIA
.

No I have not pensive

Thanks for confirming, hoping to find a workaround. I submitted bug 1522 over on the mutter tracker as it does seem to work fine for me with KDE and disabling the compositor (which it does by default for fullscreen apps with the latest KDE). No idea if it's actually mutter at fault or something within wine/proton but I figured it couldn't hurt to try and get more eyes on it...

FWIW I run Nvidia and I'm not having any issues on Budgie, which uses GNOME and Mutter under the hood and therefore also has no way to disable the compositor.

No I have not pensive

Thanks for confirming, hoping to find a workaround. I submitted bug 1522 over on the mutter tracker as it does seem to work fine for me with KDE and disabling the compositor (which it does by default for fullscreen apps with the latest KDE). No idea if it's actually mutter at fault or something within wine/proton but I figured it couldn't hurt to try and get more eyes on it...

Interestingly, today it started working again!

Probably something to do with these updates?

[2020-11-03T16:51:12+0600] [ALPM] upgraded vulkan-icd-loader (1.2.153-2 -> 1.2.158-1)
[2020-11-03T16:51:12+0600] [ALPM] upgraded vulkan-tools (1.2.153-1 -> 1.2.158-1)

Interestingly, today it started working again!

It also did not work for me at some point, but then after I restarted my computer, it worked (but there were no updates in the meantime).

@kisak-valve Hi, it seems that because the game doesn't seem to recognize that my bethesda account is verified, I cannot access battlemode nor newer master levels because of it. Would be nice to see a fix soon.

Tested with proton 5.0.10

I'm experiencing the game freezes at "loading" (~10 seconds after launching). I've tried the nvidia 440, 450 and 455 drivers, result is the same. Tried proton versions 5.13-1, 5.0-10, and 5.9-GE, result is the same. Launch arguments used: PROTON_NO_ESYNC=1 %command% +in_terminal 1 +com_skipIntroVideo 1 +com_skipSignInManager 1 (I've tried them individually and together. Result is the same).

system info: https://gist.github.com/dymax78/24837a587c00eb59a2c68fc24c5b80da

proton log dump: steam-782330.zip

Thank you for your time and assistance.

@dymax78 have you tried playing the game with Esync enabled? I haven't had these issues on my end after doing so.

For months the game wouldn't run unless esync was disabled, so that doesn't
make much sense. I guess it might work with Esync now, but I doubt that's
the issue.

On Sun, Nov 8, 2020 at 11:46 PM Alexander Streng notifications@github.com
wrote:

@dymax78 https://github.com/dymax78 have you tried playing the game
with Esync enabled? I haven't had these issues on my end after doing so.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-723750943,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM5Y33YMBZOHY57PSCZLOO3SO5X3TANCNFSM4MI6DHIA
.

@gardotd426 still worth trying. And the game works perfectly with esync(on nvidia hardware but that souldn't matter). In mh case if esync was disabled then 99% of the time the game would get stuck at a black screen before even booting to the main menu.

@gardotd426 still worth trying. And the game works perfectly with esync(on nvidia hardware but that souldn't matter). In mh case if esync was disabled then 99% of the time the game would get stuck at a black screen before even booting to the main menu.

Hi Warrior,

Yes, I've tried that as well. Unfortunately, it's the same result.

Doom Eternal won't load following upgrade from Ubuntu 20.04 - 20.10

Issue transferred from https://github.com/ValveSoftware/steam-for-linux/issues/7458.
@Pentastarch posted on 2020-11-09T16:08:10:

Your system information

Distro: Ubuntu 20.10
Kernel: 5.8.0-26-generic
RAM: 32 GB
GPU Driver: NVIDIA 455.28
GPU: NVIDIA GeForce RTX 2070 SUPER
CPU: AMD Ryzen 7 3700X 8-Core
Proton: 5.13-1
Steam client: Built: 4th Nov, version 1604538810
Steam Runtime Version: steam-runtime_0.20201104.0

Ubuntu 20.10

In the steam beta - yes

I upgraded from 20.04 to 20.10 and Doom Eternal stopped loading. It gets to the loading screen and hangs. Other games - Doom 2016, Metro Exodus load and run fine.

I have reinstalled steam and the game, verified the files but cant get past the load screen.

I did change the screen refresh rate to 60Hz from 144Hz, which worked prior to the upgrade, and it loads the next screen and the music starts. But then hangs there. but I haven't got any further.

Any ideas??

For everyone having it hang on the initial loading screen, try running in Windowed (I believe -window or -safe launch options) or try a different compositor (if you're on gnome, try kde or something uncomposited). I'm having a similar issue with mutter/gnome as listed in my post above which may be what you're running into.

Actually I'm seeing that Battlemode doesn't work either (I've never tried
to play it).

Idk if this is a Proton 5.13 issue or what, I'll try with another Proton
version and see what happens.

On Mon, Nov 9, 2020 at 1:21 PM George Gibbs notifications@github.com
wrote:

For everyone having it hang on the initial loading screen, try running in
Windowed (I believe -window or -safe launch options) or try a different
compositor (if you're on gnome, try kde or something uncomposited). I'm
having a similar issue with mutter/gnome as listed in my post above which
may be what you're running into.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-724188382,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM5Y33526S7GAA3NM2AXZV3SPAXKBANCNFSM4MI6DHIA
.

Ive tried all the proton versions, including the GE versions, upgraded to the latest Nvidia drivers. Purged steam, reloaded everything.
But as all the rest of my games run it must be some kind of interaction - particular to DE and 20.10 - as Vash63 suggests, gnome?

@kisak-valve, so Doom Eternal Battlemode is confirmed not working with 5.13. Should that be in the 5.13 issues? Or just here?

Hello @gardotd426, please confirm that the issue doesn't occur with an older Proton version, then with Proton 5.13, add PROTON_LOG=1 %command% to the game's launch options, reproduce the issue, and attach the generated $HOME/steam-$APPID.log to this issue report as a file. (Proton logs compress well if needed.)

In general, this is the right place to discuss all issues you see with Doom Eternal.

For everyone having it hang on the initial loading screen, try running in Windowed (I believe -window or -safe launch options) or try a different compositor (if you're on gnome, try kde or something uncomposited). I'm having a similar issue with mutter/gnome as listed in my post above which may be what you're running into.

Thanks for the suggestion. Unfortunately, the windowed launch options are being ignored (-windowed, –windowed -w 1024, -sw, or -safe) and the game keeps opening in fullscreen. Based off your response, it's pertinent to note that I recently updated Gnome to 3.38.

Hello @gardotd426, please confirm that the issue doesn't occur with an older Proton version, then with Proton 5.13, add PROTON_LOG=1 %command% to the game's launch options, reproduce the issue, and attach the generated $HOME/steam-$APPID.log to this issue report as a file. (Proton logs compress well if needed.)

In general, this is the right place to discuss all issues you see with Doom Eternal.

@kisak-valve battlemode never worked with Proton due to "unverified account" issue

@kisak-valve battlemode never worked with Proton due to "unverified account" issue

@warriormaster12 I'm sorry, this is wrong.

Battlemode does work with other versions of Proton. I tested it after my previous post, and was able to play like 5 matches in a row with no issues.

And on Proton 5.13, it's not an "unverified account" issue. It's just "Unknown error occurred. Please try again later."

@kisak-valve I'll get those logs and post them later today.

Battlemode does work with other versions of Proton. I tested it after my previous post, and was able to play like 5 matches in a row with no issues.

@gardotd426 battlemode never worked for me with any proton versions, it just says unable to find matches.

@kisak-valve battlemode never worked with Proton due to "unverified account" issue

@warriormaster12 I'm sorry, this is wrong.

Battlemode does work with other versions of Proton. I tested it after my previous post, and was able to play like 5 matches in a row with no issues.

And on Proton 5.13, it's not an "unverified account" issue. It's just "Unknown error occurred. Please try again later."

@kisak-valve I'll get those logs and post them later today.

@gardotd426

Battlemode never worked on my end. I checked bethesda.net and it says that my account is verified but in Doom Eternal it's not.

@gardotd426 battlemode never worked for me with any proton versions, it just says unable to find matches.

This is apparently sometimes an issue with Windows users as well.

But no, I was able to play 5 or 6 matches in a row just by using "Quick Match" (so not like I was invited by anyone or anything) and it worked flawlessly.

Battlemode never worked on my end. I checked bethesda.net and it says that my account is verified but in Doom Eternal it's not.

@warriormaster12 that's unfortunate, but I don't have that issue whatsoever, and it's not the issue with 5.13 either, it's something else.

@gardotd426 battlemode never worked for me with any proton versions, it just says unable to find matches.

This is apparently sometimes an issue with Windows users as well.

But no, I was able to play 5 or 6 matches in a row just by using "Quick Match" (so not like I was invited by anyone or anything) and it worked flawlessly.

Battlemode never worked on my end. I checked bethesda.net and it says that my account is verified but in Doom Eternal it's not.

@warriormaster12 that's unfortunate, but I don't have that issue whatsoever, and it's not the issue with 5.13 either, it's something else.

@gardotd426 you might be an exception not the rule but we'll see. I'll send a lig later today and also try to send a ticket to Bethesda support.

That's not likely.

You pretty much never have situations where multiplayer only works for one
person and not everyone else. You do often have situations where it will
work for most people but a few can't get it to work.

I've tested this on multiple machines.

On Tue, Nov 10, 2020, 2:57 AM Alexander Streng notifications@github.com
wrote:

@gardotd426 https://github.com/gardotd426 battlemode never worked for
me with any proton versions, it just says unable to find matches.

This is apparently sometimes an issue with Windows users as well.

But no, I was able to play 5 or 6 matches in a row just by using "Quick
Match" (so not like I was invited by anyone or anything) and it worked
flawlessly.

Battlemode never worked on my end. I checked bethesda.net and it says
that my account is verified but in Doom Eternal it's not.

@warriormaster12 https://github.com/warriormaster12 that's unfortunate,
but I don't have that issue whatsoever, and it's not the issue with 5.13
either, it's something else.

@gardotd426 https://github.com/gardotd426 you might be an exception not
the rule but we'll see. I'll send a lig later today and also try to send a
ticket to Bethesda support.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-724530867,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM5Y332BA7TH5INNNITWL6TSPDW7JANCNFSM4MI6DHIA
.

@gardotd426 guess you are right then, I already sent a ticket to Bethesda

Hopefully they give you anything other than "Sorry, this game is for
Windows only, we can't provide any help" which is 99.9999% going to be what
they say.

On Tue, Nov 10, 2020 at 4:43 AM Alexander Streng notifications@github.com
wrote:

@gardotd426 https://github.com/gardotd426 guess you are right then, I
already sent a ticket to Bethesda

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-724587166,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM5Y33YYIFYFRLNL7ATKAUDSPEDKHANCNFSM4MI6DHIA
.

For everyone having it hang on the initial loading screen, try running in Windowed (I believe -window or -safe launch options) or try a different compositor (if you're on gnome, try kde or something uncomposited). I'm having a similar issue with mutter/gnome as listed in my post above which may be what you're running into.

Thanks for the suggestion. Unfortunately, the windowed launch options are being ignored (-windowed, –windowed -w 1024, -sw, or -safe) and the game keeps opening in fullscreen. Based off your response, it's pertinent to note that I recently updated Gnome to 3.38.

Its definitely Gnome. Just installed Plasma and it runs fine

For everyone having it hang on the initial loading screen, try running in Windowed (I believe -window or -safe launch options) or try a different compositor (if you're on gnome, try kde or something uncomposited). I'm having a similar issue with mutter/gnome as listed in my post above which may be what you're running into.

Thanks for the suggestion. Unfortunately, the windowed launch options are being ignored (-windowed, –windowed -w 1024, -sw, or -safe) and the game keeps opening in fullscreen. Based off your response, it's pertinent to note that I recently updated Gnome to 3.38.

Its definitely Gnome. Just installed Plasma and it runs fine

Thanks for confirming. I've opened an issue for this on GNOME's mutter tracker, though I'm still not sure if mutter is the fault or something not being handled right between Proton and mutter.

Denuvo was removed from the game in an update so the game should work out of the box. Proton 5.9 runs it well.

From what I've gathered reading this thread, and by personal experience:

• For the love of god do not use GNOME / MATE
• Alt-Tabbing while in full screen or changing the screen resolution can and in many cases will break the rendering and you will have to kill the game. If you need to access other programs while you are playing, play in Windowed mode. The game supports the maximize button.
• Audio crackling may occur. It can be mostly reduced using some custom Pulseaudio settings.
• GPU usage is slightly higher when playing on Proton. On Windows the absolute minimum would be a 1050 2GB, but for Proton you will need a 1060 3GB or better, which I'm pretty sure is recommended anyway.
• I tried multi-player. It doesn't work. The error message doesn't give me anything specific, it just tells me there was a connection issue, so I don't know if it's caused by some sort of anticheat. If anybody has a work-around, let me know.

Specs I've tested on:

GTX 1060 3GB
Intel Core i5 8400
16GB of HyperX Fury DDR4 Dual Channel RAM
GeForce Driver 450 LTS
Intel 660p Series 1TB (where the game is stored)

For everyone having it hang on the initial loading screen, try running in Windowed (I believe -window or -safe launch options) or try a different compositor (if you're on gnome, try kde or something uncomposited). I'm having a similar issue with mutter/gnome as listed in my post above which may be what you're running into.

Thanks for the suggestion. Unfortunately, the windowed launch options are being ignored (-windowed, –windowed -w 1024, -sw, or -safe) and the game keeps opening in fullscreen. Based off your response, it's pertinent to note that I recently updated Gnome to 3.38.

Its definitely Gnome. Just installed Plasma and it runs fine

Kubuntu 20.04, Proton 5.13-1 - multplayer never worked.

@gardotd426 well, I tried but they refused to fix the issue because of Proton. I should try to test the game on windows and creare a ticket afrer that.

Update, they are willing to continue to help me with account verification issue.

@kisak-valve Hi, I thought that it would be a good idea to send the same log that I sent to Bethesda here.

Here's the log
steam-782330.zip

@gardotd426 Bethesda support's conclusion was that the issue isn't with my account/account linking with steam but how Proton handles loging in to the game.

@warriormaster12 Of course, for me Battlemode works fine on Windows.

Have not tried Battlemode, but except alt+tab issue Doom Eternal runs perfectly on my Gnome setup. And it's run great! :-) Started to play the Ancient God DLC.

If anyone need anything that might help, please do ask, I will try to provide as much in my ability.

Have not tried Battlemode, but except alt+tab issue Doom Eternal runs perfectly on my Gnome setup. And it's run great! :-) Started to play the Ancient God DLC.

If anyone need anything that might help, please do ask, I will try to provide as much in my ability.

what version of Gnome?

Gnome 3.38.1

On Sun, Nov 15, 2020, 13:44 dymax78 notifications@github.com wrote:

Have not tried Battlemode, but except alt+tab issue Doom Eternal runs
perfectly on my Gnome setup. And it's run great! :-) Started to play the
Ancient God DLC.

If anyone need anything that might help, please do ask, I will try to
provide as much in my ability.

what version of Gnome?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/3773#issuecomment-727529802,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAIQWGUK7GZKOHZJJ2S2GTSP6BE5ANCNFSM4MI6DHIA
.