- Feb 22, 2021
-
-
Ludovico de Nittis authored
With the additional "issues" entry in the s-r-s-i report we can now flag the ICDs/layers as being duplicated or also unsupported. This makes it easier to spot misconfigured systems or also regressions about how we import ICDs/layers inside the container. Fixes: T26156 Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Jan 28, 2021
-
-
Ludovico de Nittis authored
Now that check-vulkan prints detailed information about every physical and virtual Vulkan GPU, we can start to provide this info in s-r-s-i too. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Jan 25, 2021
-
-
Simon McVittie authored
A single line with escaped newlines is unnecessarily hard to read. This repurposes code that we already had for printing a udev uevent pseudo-file in this way. We retain the ability to parse old s-r-s-i output in which the diagnostic messages were a string: the intended meaning is fairly obvious. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 18, 2020
-
-
Simon McVittie authored
On operating systems with unusual path layouts, such as Exherbo and NixOS, the de facto standard path for the runtime linker is not necessarily present for all architectures. (Of course, if the x86_64 runtime linker is not present, we won't normally be able to run steam-runtime-system-info either, but at least users of such operating systems can compile it from source code if they need to provide diagnostics.) Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 17, 2020
-
-
Ludovico de Nittis authored
Similarly to what we already have for ICDs, we are now able to parse the Vulkan layers JSON files and add this information in the report. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Oct 26, 2020
-
-
Ludovico de Nittis authored
Print in the steam-runtime-system-info report the information we know about the xdg-portal support. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Oct 07, 2020
-
-
Ludovico de Nittis authored
These two environment variables can be useful for inferring how and which version of the Steam bootstrapper have been used. For example if the reported version is something like "1.0.0.63-1/Debian", we are quite sure that Steam has been installed using the package from Debian's non-free archive area. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Jul 09, 2020
-
-
Simon McVittie authored
In s-r-system-info, we show libraries whose SONAME is not the same as the name we asked for, even in non-verbose mode. For example, if the expectations have not been updated to list libldap_r-2.4.so.2 yet, Debian systems will show: "libldap-2.4.so.2" : { "soname" : "libldap_r-2.4.so.2", "path" : "/usr/lib/x86_64-linux-gnu/libldap-2.4.so.2" }, Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Apr 24, 2020
-
-
Ludovico de Nittis authored
We already stored the path to "ubuntu12_32" but this information was kept private. Now we give a public function to access it and we also show this information in the JSON output. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Apr 20, 2020
-
-
Ludovico de Nittis authored
Add a check similarly to the VDPAU one that we already have. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
We use the automated VDPAU check to add an entry in the steam-runtime-system-info report. Also `check-vdpau` has a new option `--verbose` that prints additional info about the driver in use. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Apr 14, 2020
-
-
Ludovico de Nittis authored
Check if the CPU supports the features we are interested in. Right now they are: SSE3 (pni), x86_64 (lm) and CMPXCHG16B (cx16). Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Apr 01, 2020
-
-
Ludovico de Nittis authored
Now we are able to diagnose if there are problems with how we handle the `steam://` URLs. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Mar 10, 2020
-
-
Ludovico de Nittis authored
"srt_dri_driver_get_library_path" might return a relative path. Instead with this new function we will be sure to receive an absolute path to the driver. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
"srt_va_api_driver_get_library_path" might return a relative path. Instead with this new function we will be sure to receive an absolute path to the driver. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
"srt_vdpau_driver_get_library_path" might return a relative path. Instead with this new function we will be sure to receive an absolute path to the driver. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- 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>
-
- Feb 12, 2020
-
-
Ludovico de Nittis authored
Similarly to the already present Mesa DRI and VA-API drivers, now we are listing also VDPAU modules. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@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>
-
- Jan 09, 2020
-
-
Previously we were listing only ICDs (graphics drivers). With this commit we are now able to get a more complete vision of the running system listing also Mesa DRI and VA-API drivers. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Nov 18, 2019
-
-
Jeremy Whiting authored
-
- 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
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>
-
- Sep 24, 2019
-
-
Simon McVittie authored
This is necessary for pressure-vessel containers to support Vulkan: to be able to make the Vulkan ICDs available in the container, we have to be able to find them, bind-mount them into a suitable location, and provide corresponding ICD JSON metadata to the contained game. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 11, 2019
-
-
Simon McVittie authored
pressure-vessel will use these when it generates any missing locales. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 09, 2019
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-