- Oct 10, 2023
-
-
Simon McVittie authored
pv-runtime: Use a closer match for 99-pulseaudio-default.conf See merge request !597
-
- Oct 06, 2023
-
-
Simon McVittie authored
Add libnvidia-gpucomp to the list of NVIDIA driver libraries See merge request !599
-
Upcoming versions of the NVIDIA driver will include a new component: https://forums.developer.nvidia.com/t/new-driver-component-libnvidia-gpucomp/267060 Update the list of NVIDIA driver libraries so that it can be included in the runtime environment along with the others. steamrt/tasks#340 Signed-off-by:
Daniel Dadap <ddadap@nvidia.com>
-
Simon McVittie authored
log: Lower noisy messages to debug level See merge request !598
-
- Oct 05, 2023
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Fix duplicate Nvidia Vulkan/EGL drivers under Flatpak (steam-runtime#624) See merge request !595
-
Simon McVittie authored
The unofficial Steam app on Flathub uses an extension to provide i386 graphics drivers, alongside the x86_64 graphics drivers provided by an extension to the base runtime. Unlike typical Linux distribution packaging where the JSON manifests are in /usr/share, the JSON manifests for these drivers are installed into architecture-specific locations. When using Mesa, this is fine, because each driver's JSON manifest refers to the Mesa driver by its absolute path, and Vulkan-Loader will ignore the drivers that are for the other word-size. However, when using the Nvidia proprietary driver, the JSON manifest refers to the driver by its basename, which is equally good for both word-sizes. In a typical Linux distribution, both word-sizes would share a single JSON manifest and there would still be no duplication, but in Flatpak, we get two JSON manifests in different locations with identical content. This has been implicated in crashes in some games, such as The Elder Scrolls Online (although I have not been able to reproduce this with the games I've tried). Before pressure-vessel 0.20230919.0, we accidentally avoided this failure mode by generating broken symlinks for the i386 manifests in /app, which meant that only the manifest originally intended to be for x86_64 was loaded; but that was more a case of compensating errors than anything else, and was probably breaking the ability to load Mesa drivers for i386 games (mitigated by the fact that games requiring Vulkan are more likely to target x86_64). 0.20230919.0 fixed that bug, at the cost of introducing this duplication for Nvidia drivers. We can avoid this becoming an issue by only providing the first one of each set of duplicate JSON manifests. Resolves: https://github.com/ValveSoftware/steam-runtime/issues/624 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Unlike layers, Vulkan/EGL drivers and EGL external platforms have relatively small JSON manifests and no built-in way to exclude duplicates. We can use the full content of the manifest to detect trivial cases of duplication. We don't do this for Vulkan layers, because Vulkan-Loader can already deduplicate those by the layer name, and they're substantially larger than drivers (which would make them more memory-consuming). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This will let us use generic functions to manipulate the SrtLoadable's contents without affecting the public API. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This avoids some overly long lines, and will make subsequent changes more straightforward. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
As with commit e7fbf19e "pressure-vessel: Use g_debug for messages that only show when verbose" in pv-wrap, if opt_verbose is true, then we know we'll display these even if they are only at debug severity. Using g_debug instead of g_message gives them the correct prefixes in the log, and avoids a distracting level of highlighting in the systemd Journal. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
There are two reasons we can get profiling messages: either because we explicitly enabled them with SRT_LOG=timing, or because we have asked to get all debug messages indiscriminately. If we're writing to the Journal, g_message() translates into LOG_NOTICE, which shows up with a distracting level of highlighting. This is appropriate if we specifically asked for timing information, but inappropriate if we just want general debug information, so reduce the log level in the latter case. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
tests: Stop assuming libcrypt will be pulled into a scout container See merge request !596
-
- Oct 04, 2023
-
-
Simon McVittie authored
`pcm.!default pulse` assumes that a device named `pulse` already exists in the configuration (which it might, but equally it might not) and overwrites (because of the `!`) the definition of the `default` device with an alias for `pulse`, which could be written as pcm_devices["default"] = pcm_devices["pulse"] in a somewhat more conventional language. In contrast to that, `pcm.!default { type pulse }` overwrites the definition of the `default` device with a newly-defined device whose *type* is `pulse`, more like this pseudocode: pcm_devices["default"] = new PcmDevice(type="pulse") The latter is what `99-pulseaudio-default.conf.example` actually does, and therefore what the fdo runtime's `99-pulseaudio-default.conf` actually does (because it's just a copy of `99-pulseaudio-default.conf.example`, see https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/commit/870889cdde734557298b8e0e4506e275cacb4f90 for the precise implementation). In pressure-vessel we write this to `/etc/asound.conf` rather than into `/etc/alsa/conf.d/` because very old versions of libasound like the one in Steam Runtime 1 'scout' only supported the former and not the latter, but otherwise we intend to mimic what the fdo runtime does, so let's mimic it a little closer. This should make games and other programs that output via libasound, like Shadowrun Returns and `aplay`, more reliable in the container. One other minor divergence from `99-pulseaudio-default.conf.example` is that we don't set the human-readable name `Default ALSA Output (currently PulseAudio Sound Server)` on the device, which seems a bit much for a targeted fix. Thanks: Nozomi Miyamori Resolves: https://github.com/ValveSoftware/steam-runtime/issues/623 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is not guaranteed to be the case now that we are treating libcrypt as potentially a separate library, which is necessary to support use of libxcrypt. Fixes: 81d0099a "Merge libcapsule/v0.20230928.0" Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 28, 2023
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
libcapsule: Don't treat libcrypt.so.1 as part of glibc See merge request !593
-
Simon McVittie authored
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Some parts of libcapsule are sufficiently low-level to want to avoid calling malloc(), instead using PATH_MAX-sized buffers and an assumption that paths are, in practice, smaller than that. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 27, 2023
-
-
Simon McVittie authored
If we have selected a ContainerRuntimeDepot, we might still need to override PRESSURE_VESSEL_PREFIX to its default version of pressure-vessel if there is a different PRESSURE_VESSEL_PREFIX in the environment. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 26, 2023
-
-
Simon McVittie authored
libcrypt.so.1 is build-time optional since glibc 2.28, and is not built by default since 2.38. In newer distributions like Debian >= 11 and Ubuntu >= 20.04, it's usually replaced by libxcrypt, either compiled to be a drop-in replacement for glibc's libcrypt.so.1 (as in Debian, and therefore the Steam Runtime), or with its own SONAME libcrypt.so.2 and optionally a secondary build as libcrypt.so.1 (as in Arch). Because libxcrypt implements a superset of the glibc libcrypt.so.1 ABI, adding some functions and symvers of its own, it is backward- but not forward-compatible: it's OK to use libxcrypt libcrypt.so.1 as a replacement for glibc libcrypt.so.1, but it is not OK to do the opposite. This means it would be incorrect for us to use a system copy of glibc libcrypt.so.1 (perhaps from glibc 2.32 or newer) as a replacement for a container's libxcrypt libcrypt.so.1, even if the system copy of glibc is strictly newer than the container's glibc (for example, Steam Runtime 3 'sniper' is based on Debian 11, so it comes with glibc 2.31 and libxcrypt). Unlike libpthread, libdl and librt, symbols from `libcrypt.so.1` were never absorbed into `libc.so.6`, so we don't have to apply the reasoning seen in 4c2e3e3b "capture-libs: Add a special case to support glibc 2.34+". In practice we've always got away with it in the past, but it's something that could cause a crash or incompatibility. I'm now looking into the possibility of backporting libxcrypt into Steam Runtime 1 and 2 (steamrt/tasks#332), which makes it more important to get this right. Accordingly, exclude libcrypt.so.1 from that special treatment, and instead set it up to be compared separately using the same comparators we use for glibc: by public symvers, then by public symbols, and as a last resort by name. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
These are only directly used within their translation unit, therefore don't need to be extern. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Just for completeness, we're not going to support any of these any time soon. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 22, 2023
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
helpers: Fix use-after-free closing standard output See merge request !592
-
Simon McVittie authored
In these two helpers, original_stdout is automatically freed on exit from its scope, so we must not close it in a way that leaves a dangling pointer to the freed object. Fixes: 44df5dfa "helpers: Warn if closing stdout fails" Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 19, 2023
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
pv-runtime: Improve handling of Vulkan layers, especially under Flatpak Closes #124 See merge request !588
-
Simon McVittie authored
If we find two JSON manifests MangoHud.x86_64.json and MangoHud.x86.json, with library_arch set to 64 and 32 respectively, but both with library_path set to /usr/$LIB/libMangoHud.so, then we want to emit two manifests, one for 64-bit and one for 32-bit. Before this commit, we would successfully load /usr/$LIB/libMangoHud.so for both word sizes for each input manifest, and would incorrectly output *four* manifests in two pairs of duplicates. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
When we create separate JSON manifests for the x86_64 and i386 versions of a manifest, we can avoid them being loaded by the loader for the "other" word size by setting the library_arch field appropriately, even if it was not set in the original manifest. For example, if the original manifest said /usr/$LIB/libMangoHud.so, we'll write out two manifests with library_path set to /usr/lib/x86_64-linux-gnu/libMangoHud.so and /usr/lib/i386-linux-gnu/libMangoHud.so. There is no point in trying to load those into the loader of the opposite word size, so set their library_arch to "64" and "32" respectively. Helps: https://github.com/ValveSoftware/steam-runtime/issues/618 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
When the path to a JSON manifest for an EGL/Vulkan driver or a Vulkan layer contains symlinks, the meaning of those symlinks might be different when the provider is mounted on /run/host, /run/gfx or /run/parent. In particular, for Flatpak apps with the freedesktop Platform version 22.08 or newer, /usr/lib/i386-linux-gnu is a symbolic link to ../../../app/lib/i386-linux-gnu (one more ../ than is needed), which means that when we try to dereference it, we "escape" from /run/parent. We can avoid this by canonicalizing the path in the provider, and then using the canonicalized path /app/lib/i386-linux-gnu/... to form our symlink /run/parent/app/lib/i386-linux-gnu/... so that it will still be resolvable in our final container. Resolves: #124 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Having opened an O_PATH fd for the desired file already, we might as well copy from there instead of repeating _srt_resolve_in_sysroot(). We have to reopen the file via /proc because an O_PATH fd isn't readable on its own. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
It seems unnecessary to have three almost identical calls to _srt_file_test_in_sysroot() which each imply a _srt_resolve_in_sysroot() (differing only in their flags), and potentially a fourth later, when we could just combine them. This is not 100% equivalent if we combined more than one of IF_EXISTS, IF_DIR and IF_REGULAR, but we never actually do that, so keep things simple by allowing at most one of those flags to be combined. If we find a use-case for combining them in future, we'll have to decide what that means. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
When we do this, we also need to increase the file format version if older. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Fixes: f49f6359 "Add "library_arch" field support for Vulkan ICDs and layer manifests" Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-