- Mar 04, 2020
-
-
Simon McVittie authored
Refactor bin/system-info See merge request steam/steam-runtime-tools!106
-
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
This means pressure-vessel branches that need the new VDPAU enumeration code can check for this prerelease. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Mar 03, 2020
-
-
Simon McVittie authored
Use loops to reduce build-system repetition See merge request steam/steam-runtime-tools!104
-
- Feb 27, 2020
-
-
Simon McVittie authored
To reduce repetition. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
It doesn't really matter which one people use. GNOME/GLib projects seem to have chosen _build, which is the preferred build directory for pressure-vessel (where it sometimes matters, because add-relocatable-install.py needs to know how to exclude it). However, Mesa suggests build, debhelper uses obj-$(GNU_TUPLE), and Meson tutorials suggest builddir. Let's ignore all of them. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Add check-vdpau helper See merge request steam/steam-runtime-tools!103
-
Ludovico de Nittis authored
With this helper we are able to test if VDPAU is available and usable. It is a simple test that renders a 4x4 surface and checks that the output is what we expected. Exit code is 0 on success. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Feb 12, 2020
-
-
Simon McVittie authored
Enumerate VDPAU drivers See merge request steam/steam-runtime-tools!100
-
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 11, 2020
-
-
Simon McVittie authored
Log driver-selection environment variables See merge request steam/steam-runtime-tools!99
-
- 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>
-
Simon McVittie authored
meson: remove redundant Wall and Wextra flags See merge request steam/steam-runtime-tools!98
-
- Feb 03, 2020
-
-
Ludovico de Nittis authored
Move indirect_strcmp0 to utils and rename it to _srt_indirect_strcmp0. In this way we will be able to reuse this function in places other than graphics.c Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
Using the "warning_level=2" mesa option both "Wall" and "Wextra" are already set by default. With this commit we also get rid of the compiler warnings: meson.build:117: WARNING: Consider using the built-in warning_level option instead of using "-Wall". meson.build:117: WARNING: Consider using the built-in warning_level option instead of using "-Wextra". Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Jan 20, 2020
-
-
Simon McVittie authored
Fix flags behaviour See merge request steam/steam-runtime-tools!97
-
- Jan 17, 2020
-
-
Simon McVittie authored
This is basically never going to be useful, except to test the previous commit, so I haven't bothered to include it in the man page. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
GLib flags conventionally have a NONE value that is numerically zero and represents default behaviour, with any deviation from default behaviour being represented by a nonzero flag. In particular, for the flags we currently know (INCLUDE_ALL and NONE), there are only two states that make sense to have numerically distinct: NONE and INCLUDE_ALL. If NONE is non-zero, then 0 makes no sense (it would request behaviour that differs from the behaviour of not setting any flags, but what would that mean?), while NONE|INCLUDE_ALL logically ought to be equivalent to INCLUDE_ALL. Fixing this requires some adjustments to the logic for skipping extra drivers, because (NONE & flags) will never be nonzero. It's the presence or absence of INCLUDE_ALL that we should care about, not the presence or absence of NONE. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jan 10, 2020
-
-
Simon McVittie authored
Snapshot builds via deb-build-snapshot will skip this check, because their upstream version number contains '+' or '~'. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jan 09, 2020
-
-
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
Enumerate Mesa DRI modules and VA-API drivers See merge request steam/steam-runtime-tools!84
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
When we found a loader library in ${prefix}/libQUAL, we were correctly looking in ${prefix}/libQUAL/dri. However, when we found a Debian-style loader library in ${prefix}/lib/${multiarch}, we were correctly looking for preferred drivers in ${prefix}/lib/${multiarch}/dri, but we were looking for extra drivers in ${prefix}/lib and ${prefix}/libQUAL, not in ${prefix}/lib/dri and ${prefix}/libQUAL/dri as we should. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If running without supplying library expectations, we won't necessarily have this anywhere else in our output. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
It's slightly preferable to list linker and compiler flags in stack order, with the lowest in the stack first. This allows use of a higher-level library from a non-standard prefix without also necessarily picking up lower-level libraries from the same non-standard-prefix. For example, if /path/to/json-glib also includes a copy of GLib, then -L/path/to/glib -lglib-2.0 -L/path/to/json-glib -ljson-glib-1.0 will link the GLib from /path/to/glib, but -L/path/to/json-glib -ljson-glib-1.0 -L/path/to/glib -lglib-2.0 will link both the GLib and the json-glib from /path/to/json-glib. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
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
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Unblock SIGCHLD when spawning subprocesses See merge request steam/steam-runtime-tools!93
-
Simon McVittie authored
tests: Check error indicator before checking boolean result See merge request steam/steam-runtime-tools!96
-
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>
-
Simon McVittie authored
This can be wrapped around a command in the same way as env(1) to see what happens: in particular, it can undo some of Steam's execution environment. This is a developer tool rather than something for use in production, so it's only installed alongside the installed-tests at the moment. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This avoids a coreutils limitation in versions [8.27, 8.29), which unfortunately includes Ubuntu 18.04: timeout(1) relied on SIGCHLD not being blocked, but did not unblock it themselves. The Steam client runs s-r-s-i from a thread that has SIGCHLD blocked, and SIGALRM, SIGPIPE and SIGTRAP ignored. This is contrary to frequent expectations of general-purpose libraries and command-line utilities: in particular, SIGPIPE is used by processes writing to a pipe to detect that the read end has died, SIGTRAP is frequently used to terminate processes on an assertion failure, and SIGCHLD is often necessary for subprocess management. Games (whether Steam or non-Steam) appear to be run with only SIGPIPE and SIGTRAP ignored, so strictly speaking, unignoring those two makes the behaviour of s-r-s-i unlike the behaviour of actual games. However, the effect of unblocking SIGPIPE and SIGTRAP is to make s-r-s-i more likely to crash (the default disposition of both those signals is process termination), which is probably what we want: if there is any difference, we want s-r-s-i's helpers to be more strict than games (crash more often), so that they can act as an early-warning system for issues that could manifest in games. In s-r-s-i, don't unblock signals until after we have finished command-line parsing and redirected stdout to print to the original stderr. Otherwise, g_debug() would go to the original stdout, resulting in it being invalid JSON. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-