- May 18, 2021
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- May 17, 2021
-
-
Simon McVittie authored
pv-wrap: Share Pipewire socket with container if available See merge request !314
-
Simon McVittie authored
This gives us direct access to Pipewire using its native protocol, similar to the direct access we already have to PulseAudio, X11 and Wayland. In a Flatpak subsandbox, applications will have to go via xdg-desktop-portal instead, as they do for any other Flatpak app. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
Fix listing overrides in system-info with recent pressure-vessel See merge request !313
-
Ludovico de Nittis authored
pressure-vessel: Sync flatpak_envp_cmp() from Flatpak 1.11.1 See merge request !312
-
- May 12, 2021
-
-
Simon McVittie authored
When pressure-vessel operates in --copy-runtime mode, /overrides is a symlink to /usr/lib/pressure-vessel/overrides. "find /overrides -ls" is useless here: it just lists the symlink, rather than traversing the directory hierarchy. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
"foo/bar/" is meant to be exactly equivalent to "foo/bar/.", and almost equivalent to "foo/bar" (with the important difference that it fails if bar is a non-directory). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Previously, this would have incorrectly returned success with the error set, breaking the usual GError invariants. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
At this point, current_path is everything up to but not including fd. For example, if we are traversing "x/y/z/w" with current_path = "x/y", then the fds array contains { x, y } and fd is the result of opening z. We're looking at the result of calling fstatat() on z, so we need to see "x/y/z" in the error messages, for example if z is a regular file (therefore "x/y/z/w" cannot possibly exist). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This function was originally written for pressure-vessel and subsequently added to Flatpak. If we use Flatpak's version, we can stay closer to being in sync with Flatpak's flatpak-utils.c. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- May 11, 2021
-
-
Simon McVittie authored
runtime: Use _srt_find_myself() to locate pressure-vessel prefix See merge request !310
-
- May 07, 2021
-
-
Simon McVittie authored
This is slightly simpler, and makes it easy for PvRuntime to locate tools in the helpers path (libexec/steam-runtime-tools-0) too. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Apr 30, 2021
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
pressure-vessel: Use a mtree(5) manifest to set up the runtime See merge request !295
-
Simon McVittie authored
At the moment we deploy the runtime from a giant tarball to avoid Steam downloader limitations, but that leads to a noticeable delay the first time we launch a game after a new runtime version has been downloaded. Now that the Steam download mechanism can deal better with larger numbers of smaller files, we're considering returning to the original design where the runtime depot contains unpacked files. However, the Steam download mechanism doesn't preserve permissions, modification times, or filenames that differ only by case, and has not always preserved empty directories, so we need a way to deal with all of those things. By reading a manifest written in a subset of the BSD mtree(5) format, we can create directories and symlinks, and set permissions modification times on regular files. As a bonus, it's actually slightly faster to duplicate a runtime with hard-links (--copy-runtime mode) by reading the manifest than by reading the actual directory tree, because the manifest is more likely to be contiguous on disk. In principle the mtree(5) manifest could also be used to validate that the runtime content has not become corrupted by checking files against their sha256sums. This isn't implemented here (and it would have to be done only on demand rather than routinely, because it would be slow), but the parser does at least read the sha256. In the tests, we now need to remove the mtree manifest when copying and editing a runtime. When we edit a runtime in-place, it no longer conforms to the manifest, so this can't necesarily be expected to work. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This can be used to create directories, symlinks and zero-byte files, create files as a clone (hard-link or copy) of files in a reference directory, assert that files exist, set executable/non-executable permissions, and set files' modification times. When cloning files from a reference directory, the default is to use the same filename as the destination, but that can be overridden (for example to deal with inconvenient/non-Windows-friendly filenames). This is also actually slightly faster than pv_cheap_tree_copy(), presumably because the manifest is contiguous on-disk and the directories are not necessarily. Setting directories' modification times is implemented, but probably won't work in practice, because any files we create in the directory will alter its mtime. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Apr 28, 2021
-
-
Simon McVittie authored
If we are operating from ./scout_platform_x.y.z, self->id will be NULL. Instead of matching on the names of directories, we can just check whether the deployment we are going to use is the same file (device and inode number) as the old deployment we are considering deleting. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
pressure-vessel: Speed up graphics driver discovery by operating in parallel See merge request !307
-
- Apr 27, 2021
-
-
Simon McVittie authored
This is helpful when trying to reduce this time by parallelizing. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
SrtSystemInfo is not thread-aware, but can safely be handed off from one thread to another, and caches its results internally; so we can use a thread per architecture, plus an extra thread for cross-architecture Vulkan and EGL ICDs, to enumerate graphics drivers and populate the cache in parallel with any other container setup. We join the threads just before looking at their results, to maximize the length of time for which we're running in parallel. On slow hardware (Lenovo T520 circa 2011, with 500G 7200rpm HDD) this cuts something like 20% off the setup time with a cold cache (`echo 3 | sudo tee /proc/sys/vm/drop_caches`). It also has a benefit (more like 15%) with a warm cache, immediately after a previous pressure-vessel run. This does make it somewhat harder to profile pressure-vessel, because when two I/O-bound operations run in parallel, they both take longer than they otherwise would, even though the overall task finishes sooner; this makes it hard to attribute I/O cost to particular actions. The new --single-thread option can be used to get a better idea of where the time is really going. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This encapsulates both the PROVIDER_GRAPHICS_STACK flag and the associated paths: if the object is null then the paths are meaningless, and if the object is non-null then they are meaningful. Making this an immutable "value object" also means we can share it between threads, unlike PvRuntime, which has state. This could become important if we want to make graphics driver enumeration multi-threaded to speed up pressure-vessel. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Add Flatpak version information See merge request !305
-
Simon McVittie authored
runtime: Avoid Wayland when in a Scout container See merge request !306
-
Ludovico de Nittis authored
Unset SDL_VIDEODRIVER if it was previously set to "wayland", when we are in a Scout SteamLinuxRuntime, because Scout is too old to support Wayland. This is not necessary for Soldier or Sniper because we expect it to be working for them. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
If we are in a Flatpak container it can be useful to have the Flatpak version in the system report. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
Move the existing container information from `system-info` to a separate GObject class. In this way it will be easier to expand the amount of information, related to the container that is in use, that we can log. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Simon McVittie authored
pv-runtime: Don't waste time enumerating "extra" graphics drivers See merge request !304
-
- Apr 26, 2021
-
-
Simon McVittie authored
There's no point in doing this when we aren't going to use them. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
These are interesting to a diagnostic tool, but not to pressure-vessel. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
pv-runtime: Avoid opening libraries to determine their SONAME See merge request !301
-
Ludovico de Nittis authored
helpers: Refactor $LIB, $PLATFORM detection See merge request !302
-
Simon McVittie authored
We can make a pretty good guess at what $PLATFORM will be: on many CPU architectures, there is one well-known name for the architecture, and $PLATFORM always takes that value. We might as well try it, even on otherwise unknown architectures - the worst that can happen is that our guess was wrong. Known exceptions include: * ARM 32-bit (Debian's porterboxes are v7l or v8l) * i386 (Meson calls it x86, but $PLATFORM can be i386, i486, i586 or i686) * mips family (Debian's porterboxes are octeon2 or octeon3) * PowerPC (Debian's porterbox is power8) * s390x (Debian's porterbox is z900) * x86_64 ($PLATFORM can sometimes be haswell or xeon_phi) of which we are unlikely to care about the non-x86 cases in practice. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
There's no real reason why we need to hard-code the x86 architectures here - we can do this generically across all multiarch tuples. In particular, this means we detect $LIB correctly on all Debian derivatives and in the freedesktop.org SDK, even on non-x86. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
pressure-vessel is currently x86-only, but we want to be portable to non-x86 if it's easy to do. It's reasonably common for all architectures to use lib, lib32 or lib64 for $LIB. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Generating files in the source directory is ugly, and open-coding the build instructions that we would have generated isn't a whole lot more code. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Add support to detect the expansion of $LIB and $PLATFORM See merge request !297
-
- Apr 22, 2021
-
-
Simon McVittie authored
This is no longer used. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-