The fake Arial already distributed with Python is based on Liberation fonts.
It is metrically compatible with the original Arial, but it doesn't support
all its glyphs (specifically, it misses Arabic).
The new one is based on Noto fonts. It support all the Arial glyphs
(I think), but it is not metrically compatible. It is enabled based
on SteamGameId when glyph coverage is considered more important than
metric compatibility.
So far it is enabled for FIFA 21 and FIFA 22.
CW-Bug-Id: #20302
The current script based on fontforge seems to have a few problems.
The generated fonts show glitches, for example in Cyberpunk 2077 for
Thai and in FIFA 22 for Arabic.
I don't precisely know what is the problem, and it might be that
the real bug is in the rendering code rather than in the merging
script. But since this seems to work better overall, I'm sticking
with it.
CW-Bug-Id: #20302
Due to unlucky power off or a crash crash when first starting the game
the prefix can end up in corrupted state with no obvious way of
troubleshooting.
This is an attempt at ensuring that the prefix was created successfully
and force-recreate it if it wasn't.
CW-Bug-Id: #19720
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.
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
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
