- 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>
-
- 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>
-
- Jan 08, 2020
-
-
Simon McVittie authored
If a GLib function that raises an error fails unexpectedly during testing, it's a lot more informative to see an assertion failure that includes details of the error, rather than just the boolean result. For a conventional GLib function we should not look at the "out" parameters until we have checked that the function was successful. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jan 07, 2020
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 05, 2019
-
-
Simon McVittie authored
As well as being a harmless and vaguely desirable change in its own right, this works around a bug in deb-build-snapshot, which doesn't always use the dist tarball that it just generated for the updated dpkg package. Signed-off-by:
Simon McVittie <smcv@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 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 10, 2019
-
-
Simon McVittie authored
Rather than dumping this to Steam's stderr, it's more useful if we gather it up and make it available alongside all the other diagnostic information. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 27, 2019
-
-
Simon McVittie authored
Some Steam games assume that the en_US.UTF-8 locale is available, and it's reasonably likely that others assume that the C.UTF-8 locale is available, or that the locale environment variables are set to usable values. Having checks for locale properties will also help us when experimenting with containers: we can check whether the locale that was set outside the container is available inside the container. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 15, 2019
-
-
Ludovico de Nittis authored
Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Aug 06, 2019
-
-
Ludovico de Nittis authored
Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Simon McVittie authored
This has become less an example and more a command-line driver for the library, so rename it accordingly. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
examples/system-info.c now prints a JSON object containing all the available API of steam-runtime-tools. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-