- Jun 23, 2022
-
-
Ludovico de Nittis authored
Create a function that opens a library and initializes its Elf. This allows us to reduce code duplication. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Jun 16, 2022
-
-
Simon McVittie authored
This can be combined with --no-stop-on-name-loss to make more than one instance of the same game accessible. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 15, 2022
-
-
Simon McVittie authored
Previously, the listener object would emit ::ready (because all of its zero remaining bus names have been acquired) and run the command as a subprocess even though the listener object is not really in the intended state. Now, if not run with --no-stop-on-name-loss, it will print an error message the first time a name cannot be acquired and exit unsuccessfully. Helps: steamrt/tasks#129 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This didn't account for the possibility of specifying both --terminate and a command. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is a convenient way to list possible targets. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
It's confusing if we say "launcher service" in one place and "launch server" in the other. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 14, 2022
-
-
Simon McVittie authored
This could be useful if we're routinely wrapping games in the launcher service: if that's the case, then we'll want to fall back to running the game without the launcher service if setup fails, rather than just not running any games until it's fixed. Resolves: steamrt/tasks#129 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This might make sense to be the default later, but for now it has to be requested explicitly. It currently only sets up com.steampowered.App1234. Additionally listening for ...App1234.Instance54321 could be added later if wanted. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This might be a useful way to have both per-app and per-instance bus names, for example com.steampowered.App1234 and com.steampowered.App1234.Instance54321 on the same server. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
These can be used to make the command-launcher service linger after a game has exited. For example, if the game crashes too soon after startup to be able to attach a debugger, this allows it to be re-run. Resolves: steamrt/tasks#127 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This can be used to keep the launcher service alive even if it has been replaced by another similarly-named launcher, for example when using a well-known name per Steam game. Resolves: steamrt/tasks#128 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Previously, the synopsis implied that --terminate was only allowed when not specifying a COMMAND, and the exit status description implied that `s-r-launch-client --terminate -- false` would exit 0 (in fact it propagates the exit status from false(1), and exits 1). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Previously, both success and failure came out as exit status 125, contradicting the man page, which said a successful --terminate was exit status 0. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Instead of using a GMainLoop, it's often clearer what is going on if we explicitly loop until a condition becomes false, and that seems to be the case here. Keeping better track of the circumstances under which we exit revealed that if we lose our D-Bus name (due to being replaced by a second instance with --replace), we would have exited after a short delay. This seems unfortunate, because we don't terminate our child processes in that situation, but exiting from the launcher-service process means that the launch-client processes cannot be informed when the child processes exit or given the opportunity to send signals to them, even if they are tracking the launcher-service by its unique name (as we started to do in a previous commit). Resolve this by continuing to not terminate the child processes, but also lingering until they have all exited, so that we can propagate their exit statuses back to the caller if it is watching our unique name. Similarly, in signal_handler() and exit_on_readable_cb(), previously we would unconditionally stop the main loop immediately. Now, we wait for child processes to exit and for a possible queue of D-Bus calls to be processed. Related to steamrt/tasks#128 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If the process we are terminating is not a process group leader, then killpg() will fail with ESRCH. This is particularly significant if we are terminating a wrapped process, for which we set `child_setup_data.keep_tty_session = TRUE` so that it will not give up its controlling terminal (if any). Before this change, `test_wrap_wait` in tests/pressure-vessel/launcher.py would leak its `sleep 600` subprocess, which was not correctly terminated by calling `s-r-launch-client --terminate`. Replace that with a `cat` subprocess so that we can detect when it has been terminated, and replace the previous use of stdout (which duplicated similar code in `test_wrap_info_fd`) to facilitate that. This will become more important when we keep better track of child processes in order to avoid exiting while there are still managed child processes running. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This wasn't particularly descriptive, and I now want to use the name pv_launcher_server_stop() for something else. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
With the `terminate-after` option, processes that make us exit are not necessarily the "main" process. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If the launched process is run directly (as opposed to via a wrapper script that runs it as a subprocess or puts it in the background), then this is a convenient way to attach a debugging tool like strace or gdbserver to the launched process (typically a game). The `MAINPID` variable name is borrowed from systemd.exec(5). Note that for tools that ptrace the game (like gdbserver and strace), this will not work on Ubuntu or other distributions that use YAMA, unless you set sysctl `kernel.yama.ptrace_scope=0` to remove the restriction on debugging non-child processes. main_pid remains set even after the main process has terminated, because this gives us a way to keep track of whether the process we are looking at was the main process (which we will want in a subsequent commit to clarify the message when implementing `terminate_after`), and to keep track of whether the main process was ever run (which we will want for steamrt/tasks#129). Resolves: steamrt/tasks#126 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>
-
Simon McVittie authored
The launcher API is stateful: once we have asked an instance of the launcher to start a subprocess, we must send any subsequent Terminate() or SendSignal() messages to the original instance, not to a second instance that has taken over the same well-known bus name with `s-r-launcher-service --replace`. Similarly, we must listen for ProcessExited signals from the original instance, not a replacement. We can achieve this by resolving the well-known bus name (analogous to a DNS name) to a unique name (analogous to a dynamic IP address, but more so, since it is never reused during the lifetime of a dbus-daemon). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This bug was inherited from flatpak-spawn. Forwarded: https://github.com/flatpak/flatpak-xdg-utils/pull/59 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 08, 2022
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is a closer match for what Steam does, and provides ancillary features like logging and STEAM_COMPAT_LAUNCHER_SERVICE. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- May 16, 2022
-
-
Simon McVittie authored
This lets us default them all to 'auto', rather than failing the build if man pages are not explicitly disabled and pandoc is missing. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- May 12, 2022
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We can test this by inserting the ability to take mock data. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Apr 12, 2022
-
-
Simon McVittie authored
This is an experimental replacement for, and generalization of, PRESSURE_VESSEL_WRAP_GUI=1. When it is included in a scout runtime shipped with Steam, it will allow developers and testers to swap between runtimes by setting the Steam launch options for a game to: steam-runtime-launch-options -- %command% Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Apr 07, 2022
-
-
Simon McVittie authored
Recent Meson versions have warnings if you add the subprojects directory as an include path, because the way Meson wants to consume subprojects is by the subproject's build system producing a Meson dependency object that encapsulates its include directory. libglnx seems to be set up to have the libglnx directory be its include path instead: for example, ostree (by the author of libglnx) already uses "libglnx.h" or <libglnx.h> everywhere. Do the same here. Flatpak equivalent: https://github.com/flatpak/flatpak/pull/4842 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Mar 31, 2022
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jan 28, 2022
-
-
Simon McVittie authored
These are sometimes run in contexts where their stdout and stderr are not available, so it's useful to have a way to force their output to go *somewhere*. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This lets us select them for debug output with "G_MESSAGES_DEBUG=steam-runtime-tools". Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jan 27, 2022
-
-
Simon McVittie authored
In situations where Steam is providing the whole UI, such as Steam Deck and Big Picture mode, we might want to prioritize steam.pipe higher than x-d-p, so that Steam has the opportunity to choose what the UX will be (launching an external browser, vs. showing the web page in-process using CEF and steamwebhelper). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
In cases where we tried both steam.pipe and xdg-desktop-portal, this lets us show both their errors, instead of only the most recent. 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>
-
- Jan 13, 2022
-
-
Simon McVittie authored
These are used by the NVIDIA proprietary driver for integration with non-X11 display technologies such as Wayland and gbm. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Dec 03, 2021
-
-
Simon McVittie authored
This gives us a better version number, from the Vulkan driverInfo. It also lets us see the driver name and the machine-readable VkDriverId. Resolves: #79 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Oct 20, 2021
-
-
Ludovico de Nittis authored
Steam is x86-specific, but the majority of steam-runtime-tools is architecture-agnostic. Adding one arbitrary non-x86 architecture gives us a way to evaluate how much work would be required if full support for some other architecture is needed in future. Using aarch64 seems the easiest non-x86 to test with real hardware, since the Raspberry Pi 4 is widely available. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-