Up until now ./configure.sh was baking in the default value into the
generated Makefile. Because of it if there was a change that requires a
newer version of the SDK the compilation would fail until the next
./configure.sh invocation does the update.
This is proved to be confusing - mysterious build errors without clear
explanation.
With this change the default value is a part of Makefile.in and if user
doesn't specify --proton-sdk-image it will be always used and always up
to date.
--proton-sdk-image overrides the default and stores it in the Makefile
just like it used to.
The second grep in sequence can exit early (-q, as soon as we have one
match it exits with a success) which makes the first grep unhappy as its
write pipe is closed early, resulting in:
syncing vulkan-loader... grep: write error: Broken pipe
Let's silence those errors.
The default registry contains some fully qualified paths to fonts
that are available on the build machine, but make no sense on any
other system. This is useless, and also known to cause bug, because
it confuses the Wine font caching code. An affected game is
Lumberjack's Dynasty.
Wine Mono / Gecko packages are already cached in a contrib folder,
and downloading them outside of proton source directory is brittle.
This also makes the source sync run twice when using the toplevel
Makefile.
This breaks MinGW autoimport mechanism but nothing in Proton should be
using it. Instead, any PE module should be using standard dllimport and
ntdll will do the relocations as expected. We also don't and hopefully
never have modules larger than 2GB, so 32-bit %rip relative offsets
should be enough for everything.
This will OTOH save a lot of .refptr indirections, that are otherwise
generated for any extern symbols, even though they are later linked in
the same module, making all code smaller and maybe a little faster.
If a stream ID is not set, gstreamer will generate random stream IDs for
the streams in downstream elements. This can cause decodebin to generate
its source pads in a non-deterministic order, as decodebin takes into
account the stream IDs when sorting the source pads.
This patch includes some changes from Arek Hiler.
CW-Bug-Id: #21192
1. ElementImpl trait requires GstObjectImpl
2. gst logging macros are no longer globals prefixed with gst_, they
live inside gst:: instead
3. element is not longer passed around in many places, it can be
accessed as self.obj() or self.instance()
4. query_default is now a part of gst::Pad and takes the pad as an argument
5. some constructors were changed to use from_$type()
6. query.view_mut() returns QueryViewMut
7. ElementFactory::make now returns a builder that we have to .build()
There are some extra cleanups as well:
1. spurious 'mut' and '&' are removed, a lot of that can be infered or
were turned into a dereference by the compiler anyway
2. !bla.is_ok() are now bla.is_err()
3. some unneeded imports were removed
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.
