- Jul 05, 2021
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- May 11, 2021
-
-
Simon McVittie authored
By including this in libsteam-runtime-tools-0-helpers, we reduce the number of modules we need to manage and keep in sync. The rest of libcapsule isn't actively used yet, so this is a significant simplification. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Apr 26, 2021
-
-
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>
-
- Apr 22, 2021
-
-
Ludovico de Nittis authored
When loading VDPAU modules we rely on $PLATFORM, trying to support all its known possible expansions. However there is always the possibility that we are currently missing some of them or that new ones will be added in the future. For this reason we try to detect the expansion of $PLATFORM, and $LIB, and print its value in the report. In this way it will be easier to notice unusual and/or new expansions. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Mar 23, 2021
-
-
Simon McVittie authored
Instead of trying to format JSON using only glibc, this just prints key=value lines, some of which can be repeated. The values always have control characters and backslashes escaped as C-style octal sequences such as \040 for space, similar to the encoding of /etc/fstab. This allows non-UTF-8 bytestrings to be represented. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If we pass a (signed) char to a varargs function, it's promoted to (signed) int by the default argument promotions (resulting in padding on the left by copying the sign bit); but then %x interprets it as an unsigned int. The practical result is that for anything over 0x7f, for example 0xAB, we interpret the high bit as the sign bit and pad with "1" bits, turning 0xAB into 0xFFFFFFAB. \uFFFFFFAB is not allowed as an escaped JSON character (because Unicode stops at U+10FFFF) so parsing fails. Note that this change does not result in strings with non-ASCII content being interpreted *correctly*: we are effectively taking the bytestring from the OS and decoding it as though it was ISO-8859-1, so if a file's path includes U+00C7 LATIN CAPITAL_LETTER C WITH CEDILLA (`Ç`), encoded as 0xC3 0x87 on disk (assuming a UTF-8 environment), it will go into the JSON document as \u00C3\u0087 instead of the correct \u00C7. Fixing this would require either a considerably more complex implementation of inspect-library, or an output format that is based on bytestrings rather than JSON. Partially addresses https://github.com/ValveSoftware/steam-runtime/issues/385 and #69 . Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jan 27, 2021
-
-
Ludovico de Nittis authored
With the commit 0d0b054a we redirected the JSON results to stderr as a stopgap solution. Now we revert that and print the results in stdout so that we can implement a proper parsing. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Jan 26, 2021
-
-
Simon McVittie authored
heavy is still on Vulkan loader v1.1.73, which doesn't know VK_ERROR_INVALID_DRM_FORMAT_MODIFIER_PLANE_LAYOUT_EXT. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Simon McVittie authored
When the corresponding code in SrtGraphics is ready, we can parse the JSON on stdout and produce machine-readable output from steam-runtime-system-info. However, until we have that, human-readable output is better than nothing. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jan 25, 2021
-
-
Ludovico de Nittis authored
When we call the check-vulkan helper we will have in output information about all the available physical GPUs and also a separate JSON object that tells us if the GPU 0 is able to draw the triangle test. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Jan 20, 2021
-
-
Ludovico de Nittis authored
Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
Our entire codebase is in C with the only exception for check-vulkan and check-gl. They were coded in C++ because they were based on pre-existing codes. Converting check-vulkan in C allows us to conform it to the rest of our codebase and also it will be easier to expand its functionalities, like for example as outlined in #50. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
If it's not zero-initialized, it could lead to a SEGV when we try to create the XCB surface. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Nov 26, 2020
-
-
Ludovico de Nittis authored
Some Intel GPUs don't have the profile "VAProfileNone". For this reason we try "VAProfileH264Main" instead, that should be supported since Intel GMA 4500 and Radeon HD 2000 and GeForce 8. For additional coverage we also fallback to "VAProfileMPEG2Simple", that has a similar GPU compatibility and lastly to "VAProfileNone". Fixes: #24 Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Nov 09, 2020
-
-
Ludovico de Nittis authored
JSON-Glib 1.6.0 introduced new functions to get members from a JSON object with a default fallback value. This allows us to avoid manually checking the existence of a member. The functions that we currently need, have been backported to allow the execution on systems with a JSON-GLIB version older than the 1.6.0 Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Oct 26, 2020
-
-
Ludovico de Nittis authored
With this helper we are able to check if `xdg-desktop-portal` is currently installed and working. It also checks if there is at least a portal backend implementation. It returns 0 if `xdg-desktop-portal` is available and there is at least a backend implementation. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Sep 25, 2020
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 08, 2020
-
-
Simon McVittie authored
This makes it easier for scan-build to understand that we are not doing anything wrong here: parsing the command-line options twice should result in the same number of items being put in hidden_deps[], but scan-build can't know that. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 24, 2020
-
-
Ludovico de Nittis authored
This information could be used to correctly handle libraries like libldap that sometimes is just an alias for libldap_r. 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>
-
Ludovico de Nittis authored
Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Mar 13, 2020
-
-
Simon McVittie authored
I had hoped that dlsym() and dlvsym() would find these special symbols, but in fact they don't. To check for ABI compatibility we need to look for specific symbols, like __atomic_load_1@LIBATOMIC_1.0. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Mar 05, 2020
-
-
Ludovico de Nittis authored
With this helper we are able to test if VA-API is available and usable. It tests the ability to gather the supported configuration profiles, then it creates two surfaces and perform a few simple rendering transformations. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Feb 27, 2020
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
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>
-
- Jan 09, 2020
-
-
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>
-
- Nov 20, 2019
-
-
Jeremy Whiting authored
Just as with check-vulkan use --visible to see the triangle window otherwise application draws a few frames and reports any gl errors found or does exit 0 on success.
-
- Nov 15, 2019
-
-
Simon McVittie authored
This ensures that they can find the non-ubiquitous json-glib library, and the steam-runtime-tools library, even if relocated into a non-standard prefix like the LD_LIBRARY_PATH Steam Runtime. We can't just use a relative version of the standard library directory as our RPATH, because if we did that, we would load glibc from the same place. This causes crashes in pressure-vessel, where ld.so and the rest of glibc are often taken from the host system via /overrides/lib, and the glibc in /lib and /usr/lib is incompatible with ld.so. Instead, use a private library directory and populate it with relative symlinks to our non-glibc dependencies; we assume the host version of glibc is new enough that this is OK. Using DT_RPATH in preference to DT_RUNPATH means we take all our direct and indirect dependencies from the same place. This is important when libjson-glib (which won't ordinarily have a RUNPATH or RPATH) pulls in GIO as an indirect dependency of check-locale, which doesn't directly depend on GIO. The GIO library we get must match the versions of GLib and GObject we're using. This also bypasses LD_LIBRARY_PATH. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 13, 2019
-
-
Simon McVittie authored
This made them usable from outside the LD_LIBRARY_PATH runtime, but breaks their use inside a pressure-vessel container. In pressure-vessel, the glibc family of libraries are typically taken from outside the container (for example /overrides/lib/x86_64-linux-gnu/libc.so.6), and the dynamic linker ld.so is replaced with one that is suitable for the libraries in /overrides. In general, these versions will be incompatible with the ones in /usr/lib/x86_64-linux-gnu, which unfortunately are the ones that get pulled in via the DT_RPATH. This reverts commit 91478a07. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 11, 2019
-
-
Simon McVittie authored
This matters when invoked as a subproject, for example by pressure-vessel, in which case we don't get -I$(top_builddir). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Detected by g++ -Wshadow. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 08, 2019
-
-
Simon McVittie authored
This ensures that they can find the non-ubiquitous json-glib library, and the steam-runtime-tools library, even if relocated into a non-standard prefix like the LD_LIBRARY_PATH Steam Runtime. Using DT_RPATH in preference to DT_RUNPATH means we take all our direct and indirect dependencies from the same place. This is important when libjson-glib (which won't ordinarily have a RUNPATH or RPATH) pulls in GIO as an indirect dependency of check-locale, which doesn't directly depend on GIO. The GIO library we get must match the versions of GLib and GObject we're using. This also bypasses LD_LIBRARY_PATH. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
VkClearValue is a struct whose first member is a union whose first member is an array of four floats, so we need three levels of braces to initialize it. clang++ 8 warns for this. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 05, 2019
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-