- Mar 06, 2020
-
-
Ludovico de Nittis authored
When listing graphics drivers now we also list GLX ICDs, such as libGLX_mesa.so.0 and libGLX_nvidia.so.0. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Simon McVittie authored
This only detects the container technologies we are most interested in right now: pressure-vessel, Flatpak and Docker. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Mar 05, 2020
-
-
Simon McVittie authored
It's feeling increasingly odd to manipulate this via environment variables, so make it its own struct member. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We'll need this when the fake home directory sets more parameters than just the environment. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Feb 10, 2020
-
-
Ludovico de Nittis authored
Some drivers have an environment variable that overrides the automatic detection of which driver should be used. For example Mesa has `MESA_LOADER_DRIVER_OVERRIDE`, VA-API has `LIBVA_DRIVER_NAME` and so on. We now log these environment variables in the s-r-s-i output to have a move complete view about the state of the running system. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Nov 08, 2019
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Oct 31, 2019
-
-
Ludovico de Nittis authored
Some libraries like "libtheoraenc.so.1" or "libCgGL.so" assumes that you have already linked to other libraries. With this commit we add support for those situations with the concept of "hidden dependencies". Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Oct 11, 2019
-
-
Ludovico de Nittis authored
When we are in a steamrt container we log the content of the "/overrides" folder. Otherwise, if we are not in a container, we log the content of both "pinned_libs_32" and "pinned_libs_64". Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Sep 26, 2019
-
-
Simon McVittie authored
Instead of inspecting the LD_LIBRARY_PATH runtime with _srt_runtime_check(), we open-code a small partial reimplementation of that function to inspect os-release(5) and provide information about a Steam Runtime container. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This one is a bit different because the raw field is a space-separated list. For convenience, srt_system_info_dup_os_id_like() can be asked to include the OS itself, for use in logic like this pseudocode: for id in info.dup_os_id_like(True): if id in special_cases: special_cases[id].run() break else: do_generic_behaviour() Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This doesn't include information about similar OSs (ID_LIKE), and also does not include a fallback to lsb_release or OS-specific files. However, it's enough to detect Steam Runtime containers. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 25, 2019
-
-
Simon McVittie authored
Until now we've been conflating these two, but Timothee Besset recently clarified their status for me. ~/.steam/steam is maintained by bin_steam.sh, aka /usr/bin/steam, in which it is referred to as STEAMDATALINK. It is the data directory containing user data (cloud-synced configuration and saves), the download cache, and the default Steam Library directory. ~/.steam/root is maintained by steam.sh, in which it is referred to as STEAMROOTLINK. It is the installation directory, containing Steam executables and libraries. As a result, they are normally the same, but can differ, in particular in two situations: * When testing a new Steam client build by running client/steam.sh, client/ gets used as the installation directory, in conjunction with the existing data directory pointed to by ~/.steam/steam. This avoids having to re-login or re-download your library of games for the new test installation. * When Debian bug #916303 was present during the initial Steam installation, the Steam client was unpacked into ~/.steam, resulting in creation of ~/.steam/steam as a real directory that cannot be replaced with a symbolic link. We effectively ended up using ~/.steam as the installation path, but with ~/.steam/steam as the data path. (The Debian steam package has since been fixed, but we cannot easily disentangle existing installations.) Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 15, 2019
-
-
Simon McVittie authored
We can use this to connect up a mock implementation if necessary. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Aug 13, 2019
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 12, 2019
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 02, 2019
-
-
Simon McVittie authored
These are implied by some other header on Debian 10, but not on SteamRT 1. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
This provides a high-level API to wrap SrtLibrary and check if the current system has the expected libraries and symbols. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Jul 29, 2019
-
-
Simon McVittie authored
This provides a high-level API, with a cache to prevent repeated calls to helpers. It does not yet wrap SrtLibrary or do anything with the expectations directory. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-