Skip to content
Snippets Groups Projects
  1. Dec 09, 2020
    • Simon McVittie's avatar
      pressure-vessel: Make graphics drivers outside $HOME available, if used · 23834972
      Simon McVittie authored
      Since !173, we have been able to create symbolic links to graphics
      drivers anywhere on the filesystem, but that didn't mean the graphics
      driver would necessarily be usable, because the directory containing it
      would not necessarily be visible in the container. Add these directories
      to the list of directories to be "exported".
      
      Manual test (Debian on on Intel hardware, adjust as required for
      others):
      
      * Modify /usr/share/vulkan/icd.d/intel_icd.i686.json
        to use /opt/moved-from-usr/lib/i386-linux-gnu/libvulkan_intel.so
      * Move the real i386 libvulkan_intel.so to that location
      * ./run --verbose -- steam-runtime-system-info 2>&1 | tee container.log
      
      Resolves: #29
      Resolves: https://github.com/ValveSoftware/steam-runtime/issues/313
      
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      23834972
  2. Nov 30, 2020
  3. Oct 26, 2020
  4. Oct 01, 2020
  5. Sep 25, 2020
  6. Sep 09, 2020
  7. Sep 02, 2020
    • Ludovico de Nittis's avatar
      Initial support for custom graphics provider path and Flatpak · d7ad67a2
      Ludovico de Nittis authored
      
      pressure-vessel had a few hard coded assumptions about the host system
      and where to look at for the graphics provider.
      
      For example it was assumed that the root was the same host system used
      by both pressure-vessel current environment (where pressure-vessel-wrap
      runs) and also later on by `bwrap`.
      
      But when we run pressure-vessel in a Flatpak container, the final
      `bwrap` command is expected to be executed against the real host system
      (mounted in `/run/host`, in Flatpak).
      
      Also when we are in a Flatpak container we might want to pick the
      graphics stack from the host system (`/run/host`), from the Flatpak
      container itself or it could even be a completely separate one.
      (T22373, T22371)
      
      Signed-off-by: default avatarLudovico de Nittis <ludovico.denittis@collabora.com>
      d7ad67a2
  8. Aug 18, 2020
    • Simon McVittie's avatar
      adverb, wrap: Add --terminate-timeout, --terminate-idle-timeout options · 18bdc4b9
      Simon McVittie authored
      
      This will let us have the following logic when sharing a container
      between multiple commands using -launcher and -launch:
      
      * For setup commands, don't wrap the launched command in the adverb.
        If the setup command starts background processes, they'll continue
        to run. This matches how installscript commands have historically
        worked for Windows (and Wine/Proton) games in Steam: the setup
        command is launched with system(), and can leak background
        processes like wineserver.
      
      * For the main game, wait for all processes to exit, by wrapping
        the launched command in the adverb, with --subreaper only. This
        matches how native Linux games, and the main command of
        Windows/Wine/Proton games, have historically worked in Steam.
      
      * When all processes belonging to the main game have exited,
        the -launcher can exit, at which point the subreaper that wraps it
        can clean up any background processes from the setup commands.
      
      --terminate-idle-timeout can be used to wait a few seconds before
      sending SIGTERM, if desired.
      
      Because the adverb now blocks SIGCHLD, we need to unblock it before
      running the child process; otherwise the child process will inherit
      the blocked signal, breaking things like g_spawn_async().
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      18bdc4b9
  9. Jul 29, 2020
  10. Jul 21, 2020
  11. Jun 17, 2020
  12. Jun 12, 2020
  13. Mar 04, 2020
Loading