If a Steam user runs Steam from a terminal, puts it in the background
and then exits from that terminal, or if they restart their desktop
session from a terminal (as in ValveSoftware/Proton#6277) and then exit
from that terminal, then we can inherit a stdout and/or stderr file
descriptor pointing to an invalid file descriptor. Writing to such a
file descriptor fails with EIO. Similarly, we could get write errors
as a result of OS state, such as ENOSPC if we are writing to a disk
that is full, or EPIPE if a stream to a logging framework such as the
systemd journal has been shut down.
In sufficiently pathological situations, the file descriptor could even
become invalid while the `proton` script is running, so even checking
for validity on startup would not be enough to prevent this.
The ability to log to stderr is important but not functionally critical,
and it's not like there is anything we can usefully do about a write
failure here (or even anywhere we can usefully put a warning message),
so just ignore write errors. This is similar to the behaviour of the
`logging` framework in the Python standard library (which writes to
`stderr` if a user-defined handler fails, but takes no other action)
and also similar to the approach taken to solve
ValveSoftware/steam-for-linux#8069.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Link: https://github.com/ValveSoftware/Proton/pull/6341
This comments out all of the games that do not need the MFDXGI hack on
the experimental branch because the experimental branch has support for
shared resources.
This separates out the games that only need shared resources in order to
play video correctly without the MFDXGI hack. El Hijo (853050) and
Labyrinth City: Pierre the Maze Detective (1421790) were also added.
Recent versions of the Steam Runtime include an IPC server/client pair
which can be used to run commands inside the container environment
(or any other special execution environment), analogous to sshd/ssh or
flatpak-portal/flatpak-spawn. The server runs inside the Steam Runtime
container and accepts commands over D-Bus; the client runs on the host
system, asks the server to run a command, and forwards its stdin, stdout
and stderr back to the host.
https://gitlab.steamos.cloud/steamrt/steamlinuxruntime/-/merge_requests/72
adds support for injecting commands into the SteamLinuxRuntime_soldier
compatibility tool (and any later version, such as sniper). However,
Steam compatibility tools are stackable: in particular, Proton runs in a
soldier container (or presumably sniper in future). If we are debugging
a Proton game, then ideally we will want to inject commands into Proton's
execution environment rather than soldier's, so that they run with the
correct environment variables etc. to communicate with a running Proton
session. In particular, it's important that the `WINEPREFIX` is correct.
The steam-runtime-launcher-interface-0 program implements the
interface for compatibility tools to use to decide where, if anywhere,
to launch the command server.
This commit does not alter the scripts produced by
PROTON_DUMP_DEBUG_COMMANDS. To run those scripts' commands in the
container environment, pass their filenames to
steam-runtime-launch-client.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Link: https://github.com/ValveSoftware/Proton/pull/5891
This removes games that we believe are fixed by the initial improved
implementation of the mfdxgidevicemanager - specifically games with
graphical distortion during video playback.
CW-Bug-ID: #19126
Various games using KT Engine like recent WRC and TT Isle of Man, when
run in a win10 prefix, try to load UWP/xinput1_3.dll that ships with the
games. It seems to be mostly-compatible xinput implementation built on
top of windows.gaming.input.dll.
However if we try to replace it with the builtin the game crashes
because it tries to call entry points that are not available in the
original xinput (that's the "mostly-compatible" part), so we need this
override.
Since our windows.gaming.input.dll implementation is just a stub
controllers other than steering wheels (which are handled through
dinput) do not work.
This reverts commit 9eb14500c2.
We are going to introduce a fake micross.ttf which also includes
all of these Arabic characters. We will use that one instead.
Some unofficial builds running closer to upstream created a Documents ->
My Documents symlink. We would then create a My Documents -> Documents
symlink, resulting in infinite recursion. Detect this scenario and fix
it before merging user directories.
The upcoming NVIDIA 470 driver series will introduce a DLL (nvngx.dll)
for the support of NVIDIA DLSS in Proton. This change adds logic for
discovering the location of DLL files provided by the NVIDIA driver, and
copies them to C:\Windows\System32\
Reviewed-by: Adam Moss <amoss@nvidia.com>
Add https://github.com/jp7677/dxvk-nvapi as a submodule. dxvk-nvapi will
not be copied into Proton prefixes by default, but instead will be
controlled via the environment variable PROTON_ENABLE_NVAPI. This is
done to avoid any potential adverse effects of the nvapi DLL existing
in cases where an application may require a function that is not
implemented by dxvk-nvapi.
This new functionality can be enabled by setting the following environment
variable to a value of `1`:
`PROTON_ENABLE_NVAPI`
This functionality is needed in order to support DLSS within Proton.
Reviewed-by: Adam Moss <amoss@nvidia.com>
