- Jan 05, 2021
-
-
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
Start to use the "info" log level See merge request !209
-
Ludovico de Nittis authored
Now that we have the ability to set the log level to "info", this commit promotes, from the debug level, all the messages that can be useful to have, for debugging purposes, but that are not too lousy. Over time, when we also gain more first hand experience with the issue reports that users provide, we can tweak the log messages even more. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
wrap: Log pressure-vessel version on startup See merge request !210
-
Simon McVittie authored
This serves two purposes: it gives us a timestamp for when pressure-vessel started, and it puts the version number in the log. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
Refactoring from Flatpak branch See merge request !207
-
Simon McVittie authored
It's easier to be sure that we are not using this variable outside the expected range of lines if it's only declared within those lines. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If we're going to run the -launcher, then argv[1...] are the arguments for -launcher, not an argv array in their own right. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We previously parsed this to decide whether we could use --unshare-uts, but we stopped doing that more than a year ago, in commit 210fbd8c. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This makes it a bit easier to reason about what we do and don't need. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
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
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Add an option to save the log to a file See merge request !201
-
Simon McVittie authored
graphics: Do not load JSON ICDs multiple times from the same dirs Closes #48 See merge request !205
-
Ludovico de Nittis authored
This is especially useful when we are logging to a file to keep track of when a specific operation happened. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
This is the middle ground between the base logging and the verbose option. Currently we are not logging any messages at the info level, but we might start to do that. And this option gives us more granularity about how much logging we want to print. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
We have our own log handler, so there is no need to use g_printerr() directly. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Ludovico de Nittis authored
Moving this log function to "utils" allows us to avoid a lot of duplication. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Jan 04, 2021
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
When we build the search paths for the JSON ICDs it might happen to have the same directory multiple times. For example if we have "XDG_CONFIG_DIRS=/usr/share" and "XDG_DATA_DIRS=/usr/share" we will look in "/usr/share" two times and duplicate all the JSONs that we find. Usually this is not an issue but with some games, e.g. Red Dead Redemption 2, this can cause a crash at startup https://github.com/ValveSoftware/steam-runtime/issues/336 With this commit we filter out the directories that we already visited to prevent this kind of issues. Fixes: #48 Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Dec 17, 2020
-
-
Ludovico de Nittis authored
pressure-vessel: Let short-term subprocesses inherit non-CLOEXEC fds See merge request !204
-
Simon McVittie authored
To work around older versions of GLib having a potential deadlock in their fd-closing code due to use of non-async-signal-safe functions in the forked child process, the Flatpak-derived code we're using here uses a simple, naive implementation of closing fds: it iterates through every possible fd, up to the rlimit. Unfortunately, Wine users sometimes set their fd rlimit very high (typically around a million), because the "esync" mechanism in Proton's Wine needs a lot of fds. The time taken by each individual syscall is not significant, but when we do a million of them, it adds up. This is arguably a misconfiguration - the recommendation is now to have a soft rlimit of 1024 and a hard rlimit of about a million, so that only processes that opt-in to dealing with a million fds have to be aware of them - but a significant number of misconfigured systems probably still exist. We don't actually *need* to close all the fds here: there's no security boundary, so giving the child access to unnecessary fds isn't a privilage gain; the parent process outlives the child, so leaking fds won't result in them never being closed; and in any case we're reasonably careful to set CLOEXEC on all our fds. So let's just not close them. In particular, this can save literally a million syscalls per helper subprocess invocation (it's not often I get to say that!), reducing pressure-vessel-wrap launch time by 90% on a system with the high fd limit (about 70 seconds down to 7). With the recommended soft limit of 1024, the speedup is less dramatic, but it still takes off nearly 10% (about 6 down to 5.5). Resolves: https://github.com/ValveSoftware/steam-runtime/issues/323 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
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 15, 2020
-
-
Simon McVittie authored
runtime: correctly handle ICD for different ABI even without subdirs Closes #45 See merge request !202
-
Ludovico de Nittis authored
Previously we used the empty directory as an indicator that the capture of the library failed, but this worked only if we always started with an empty directory. And this is not the case when we are not using a subdir. For this reason, even if the capture of a library failed, we didn't set its "kinds" to "NONEXISTENT", and this could have leaded to errors like having duplicated Vulkan implicit layer JSON for the same name and different "library_path", one pointing to the correct ABI and the other to the wrong one. Fixes: #45 Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Dec 14, 2020
-
-
Simon McVittie authored
Improve how we collect DRI drivers See merge request !200
-
Simon McVittie authored
This means we use all the search paths that steam-runtime-tools knows about, and in particular we respect LIBGL_DRIVERS_PATH and a Slackware-specific path. It also means we stop collecting "extra" drivers, which is potentially dangerous, as justified in the previous commit. Resolves: https://github.com/ValveSoftware/steam-runtime/issues/318 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
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>
-
Ludovico de Nittis authored
runtime: Cope with /tmp being a symlink See merge request !199
-
- Dec 11, 2020
-
-
Simon McVittie authored
We can make life easier for the VA-API and VDPAU driver loaders by trying to put everything in one directory, as we already do for DRI. We might as well do the same for Vulkan and EGL, where the names we choose are completely arbitrary anyway. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Instead of building a list of drivers and then converting it into a search path, we can build the search path as we go. The only side-effect is that previously we interleaved x86_64 and i386 paths, but now we put all the x86_64 paths before all the i386 paths. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We need those to be able to deal with some graphics drivers. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Slackware puts DRI drivers here. Partially addresses https://github.com/ValveSoftware/steam-runtime/issues/318 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Now that we have a backport of this function, we don't need to use a simplified version. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Because capsule-capture-libs doesn't overwrite existing symbolic links, in the unlikely event that s2tc exists in more than one directory in the search path, we want to look at the highest-precedence first. The reversed order was correct for the current implementation of collecting DRI drivers, but not for s2tc. 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>
-