Skip to content

Improve library data gathering

Simon McVittie requested to merge wip/smcv/refactor-lib-data into master

Related to #77 (closed).

  • pv-runtime: Refactor pv_runtime_collect_lib_data

    If we want to locate drirc.d relative to Mesa EGL ICDs, Vulkan ICDs and DRI drivers, it will probably be easier if pv_runtime_collect_lib_data() takes a path in the provider namespace, so factor out the part that inspects a capsule-capture-libs symlink and figures out the corresponding path in the provider namespace.

    By returning whether the symlink target could be determined (i.e. whether it's a symlink), we can also elide some redundant stat() checks from the caller.

    The indentation in pv_runtime_collect_lib_data() is a bit weird to keep the diffstat reasonable; it will be corrected in the next commit.

  • pv-runtime: Re-indent pv_runtime_collect_lib_data

  • tests: Make more helpers available in test environment

    pv-runtime now uses -detect-platform, and it could in principle use -detect-lib in future, so make sure those are available too.

  • pv-runtime: Clarify when library symlinks can end up in a subdirectory

    We can divide the graphics drivers into two categories.

    For graphics drivers that are found in a special directory (DRI, VA-API and VDPAU), we will always get an absolute path from SrtSystemInfo (and in fact we even have assertions to make sure this is the case), so the graphics driver will always be of type ICD_KIND_ABSOLUTE on success or ICD_KIND_NONEXISTENT on failure.

    For graphics drivers that are found by reference to a manifest file (Vulkan and EGL), we can either be given an absolute path or a basename, so the graphics driver will be of type ICD_KIND_ABSOLUTE or ICD_KIND_SONAME on success or ICD_KIND_NONEXISTENT on failure. For ICD_KIND_ABSOLUTE, the path is arbitrary, so we put the symlink in /overrides in a subdirectory off the default library search path to avoid collisions. For ICD_KIND_SONAME, we always want to put the symlink in the default search path, otherwise searching by SONAME will not find it.

    Either way, the use_subdir_for_kind_soname parameter is redundant: for DRI etc., its value is irrelevant because we never actually see ICD_KIND_SONAME, and for EGL etc., we always want it to be FALSE. Remove the parameter altogether, and add assertions to check our assumptions instead.

  • pv-runtime: Improve precondition checks

  • pv-runtime: Normalize paths in data_in_provider to be root-relative

    This avoids the possibility of spurious diagnostics where we warn about having found two different paths because we represented one of them as foo/bar/baz and the other as /foo/bar/baz.

    In the diagnostic messages, put the leading "/" back, to reduce confusion about what they're meant to be relative to.

  • pv-runtime: Improve debug messages

    When we say what data directory we're using for drirc.d or similar, also say what library we based this decision on.

  • pv-runtime: Avoid redundant checks and diagnostic messages

    If dir_in_provider and dir_in_provider_usr_share are equal, we don't need to check the same path again: we already know it's not a directory.

  • pv-runtime: Assume libraries in /lib or /libQUAL have data in /usr/share

    Our previous heuristic would have fallen back to /usr/share after finding that /share didn't exist.

  • pv-runtime: Find drirc.d adjacent to any known Mesa component

    Previously, we assumed that we could find the ${prefix} of any Mesa installation by basing it on the location of libGLX_mesa.so.0, and in practice this is usually good enough for end-user systems.

    However, Mike Blumenkrantz pointed out on #77 (closed) that in principle there is nothing to stop someone from building a version of Mesa that only has EGL, or a version that only has Vulkan. drirc.d is loaded by multiple Mesa components, including EGL ICDs, Vulkan ICDs, and the lower-level DRI drivers used to implement Mesa's EGL and GLVND ICDs. Look for drirc.d adjacent to all of those.

Edited by Simon McVittie

Merge request reports