- Jan 28, 2021
-
-
Ludovico de Nittis authored
Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
This helps us to avoid leaking variables. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
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 27, 2021
-
-
Simon McVittie authored
If one of the variables we are interested in happens to be set already, and doesn't get overridden, then the test will fail. For example, `DRI_PRIME=1 meson test -C _build` would fail. This will become a lot more likely to happen when I start logging ubiquitous environment variables like `DISPLAY`. We can't just set envp = NULL initially, because g_environ_setenv() in Ubuntu 12.04 won't accept NULL as a valid environment block (although newer versions do). Signed-off-by:
Simon McVittie <smcv@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>
-
- Jan 21, 2021
-
-
Ludovico de Nittis authored
JSON-GLib 1.2.0 introduced a new function called `json_from_string()`. It is an handy function that allows us to obtain a jsonNode with just a single operation. This function had to be backported, and modified a little, because we are targeting Scout that has an older JSON-GLib version that misses both `json_from_string()` and `json_parser_steal_root()` (that was used in `json_from_string()`). Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Jan 13, 2021
-
-
Simon McVittie authored
Previously, pv_capture_output() always inherited pressure-vessel-wrap's own environment, and bwrap->envp was ignored. Thanks to @mawww on Github for spotting this. Fixes: f584a55c "runtime: Don't assume container's env is in the PATH" Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jan 12, 2021
-
-
Simon McVittie authored
This is a container-manager-agnostic version of probing /.flatpak-info and /run/pressure-vessel. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jan 11, 2021
-
-
Simon McVittie authored
Clear Linux uses the same cross-architecture ld.so.cache as most distributions (Debian, Fedora, etc.), but puts it in /var/cache/ldconfig to meet their goal of /etc being empty. Create a symlink so that when their glibc tries to load that filename inside the runtime, what it gets is the runtime's /etc/ld.so.cache. Exherbo uses a ld.so.cache per architecture, which we added to a table of known per-architecture ld.so.cache filenames in commit c10e8831. Create symlinks for those too, similar to the Clear Linux case; this has not yet been verified to work, but it can't hurt. It's looking as though NixOS might be adding a Nix-specific filename for the ld.so cache (currently they don't have one at all). When that happens, we can add it to the same array as the Clear Linux filename. Other distributions that turn out to need this can be treated like Clear Linux if they share one cache between all architectures, or like Exherbo if they have a separate cache per architecture. Partially addresses <https://github.com/ValveSoftware/steam-runtime/issues/345>, which also needs <https://gitlab.collabora.com/vivek/libcapsule/-/merge_requests/43>. Also partially addresses <https://github.com/ValveSoftware/steam-runtime/issues/230 >. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jan 05, 2021
-
-
Simon McVittie authored
In a Flatpak environment, we will not be allowed to create /overrides. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We're using FlatpakBwrap as a convenient way to collect up a set of argv, envp and inherited file descriptors, but it isn't actually a bwrap command in all cases. Use a less misleading name. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 17, 2020
-
-
Simon McVittie authored
If we don't use a child setup function, then GLib can go into a more optimized code path involving posix_spawn(), where we don't get detailed error reporting. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 14, 2020
-
-
Simon McVittie authored
These are drivers for which our best guess is that the native loader would not actually load them. We want to include them in steam-runtime-system-info's diagnostic output in case we are wrong, but we don't want to include them in the container: if our guess is correct, then the host system doesn't actually load them, and the worst-case scenario is that they are somehow broken, in which case adding them to the search path might *break* the container. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 11, 2020
-
-
Simon McVittie authored
We need those to be able to deal with some graphics drivers. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 10, 2020
-
-
Simon McVittie authored
Because we were testing for a prefix match with a trailing slash, when FlatpakExports exports /home/me, we would not rewrite it to /home/me/.var/app/com.valvesoftware.Steam. Instead of adding the necessary special cases, use a slightly refactored version of flatpak_has_path_prefix(), which already does what we need. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 08, 2020
-
-
Ludovico de Nittis authored
If the environment variable "STEAM_COMPAT_CLIENT_INSTALL_PATH" is set, it should point to the equivalent of "~/.steam/root". If it doesn't, we flag it in SrtSteamIssues. Fixes: #41 Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Dec 03, 2020
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 25, 2020
-
-
Simon McVittie authored
This was reported by Rémi Bernon as the initial example of SDL's non-udev code path going wrong for touchpads when the invoking user is in the input group. (packaging/libsdl2#1) Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 24, 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
It isn't always obvious which copy of capsule-capture-libs we're going to use to run the tests. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 23, 2020
-
-
Simon McVittie authored
We only have details of the gamepad part for now. I've asked whether it also has accelerometer and touchpad device nodes like the PS4 controller did. Thanks: Sam Lantinga Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 19, 2020
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
On Steam Runtime 1 'scout', this interferes with inheriting the dependencies correctly and causes link failure. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This avoids having dh_link alter what's in the sysroots, which would cause installed-tests to fail. It also avoids issues when tests try to modify the sysroots in-place, which won't work in the installed-tests case, and causes undesired action-at-a-distance in the build-time tests. 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
-
-
Simon McVittie authored
The portal device monitor won't be able to do this, because it loses its record of which object path corresponds to which object as soon as the device is removed. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
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>
-
- Nov 12, 2020
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 10, 2020
-
-
Simon McVittie authored
We'll need this if the portal provides a way to open device nodes that don't exist in the container. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We can use this later, in diagnostic tools. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
These are what we really want for SDL and Wine: they're broadly equivalent to the udev ID_INPUT_FOO properties, and identify which devices are desired at a high level. Also add test coverage for the device-type-guessing heuristic. Thanks to various people in Collabora, Codeweavers and #debian-uk for providing `sudo evemu-describe` output for their devices. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
These are a useful input for guessing what an input device is. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is the official way to determine what an input device is, at the kernel level. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-