. "$BST_LIB"

# BST-TIMEOUT: 300   # one probe run, five forked fixtures inside it, and ~190
                     # shell extractions; the 60s default is for suites that
                     # fork far less than this one does.

# libXv 1.0.12 -- the X Video extension client library (poky recipes-graphics/
# xorg-lib). See libxv_%.bbappend for what the port adds and why.
#
# ---------------------------------------------------------------------------
# TWENTY-ONE OF THE TWENTY-THREE ENTRY POINTS ARE UNREACHABLE HERE
#
# libXv is the client interface to the X Video extension: it discovers video
# adaptors and ports on a server and puts image data through them. Every one of
# those operations is a round trip -- xv_find_display(dpy), then a request on a
# wire -- and THIS IMAGE HAS NO X SERVER. No display opens (section 7), so
# XvQueryAdaptors and its twenty siblings cannot be executed here; not untested
# today, unreachable by construction.
#
# Nor can they be driven with an invented Display, which is what makes this
# suite look like 57-libxext.test's and not 57-libxfixes.test's. libXfixes
# exports its extension list and compares the Display pointer without loading
# through it, so a seeded entry lets every real prologue run. libXv keeps its
# list in `static XExtensionInfo _xv_info_data' (Xv.c:63) -- internal linkage --
# and its generated find_display falls through a miss into XextAddDisplay, which
# dereferences. A probe that called one anyway would be reporting its own
# mistake.
#
# ---------------------------------------------------------------------------
# WHAT IS LEFT IS EXACTLY WHERE THIS PORT IS MOST AT RISK
#
# XvFreeAdaptorInfo and XvFreeEncodingInfo are the two entry points with no
# Display parameter, and they are the ARRAY WALKS. Each takes the heap array
# XvQueryAdaptors / XvQueryEncodings built, reads the count out of its HEAD
# element, and strides `pa++' over packed structures mixing CARD32, char,
# unsigned long and pointer:
#
#   for (ii = 0; ii < pAdaptors->num_adaptors; ii++, pa++)     Xv.c:311
#   for (ii = 0; ii < pEncodings->num_encodings; ii++, pe++)   Xv.c:459
#
# On wasm32 a long and a pointer are 4 bytes where the build host has 8, so
# XvAdaptorInfo is 28 bytes here against 56 there and every member offset moves
# with it. That arithmetic is what turns a successful reply into correct data
# rather than into corrupt data, and these two functions are the only part of it
# this image can EXECUTE rather than merely declare. Section 5 runs them, out of
# libXv.a.
#
# WHY THE EXPECTATIONS ARE WRITTEN OUT RATHER THAN DIFFED AGAINST x86-64.
# 57-libxcb.test compares its probe against a build-host reference because its
# question -- what a code generator emitted under cross -- has no absolute
# answer. This one does, and for section 3 a diff would make AGREEMENT the
# defect: the whole content of those cases is that a long and a pointer are four
# bytes here and eight there. Every number below was nonetheless MEASURED rather
# than guessed -- the arch-independent ones on a native build of the same
# tarball on 2026-09-11, the ILP32 ones from the same headers compiled -m32 --
# and the two places where the target must legitimately differ from that
# reference are called out where they appear.
#
# ---------------------------------------------------------------------------
# READ A RED IN SECTION ORDER; THE FIRST SECTION TO GO RED LOCALISES THE DEFECT
#
#   1  the payload arrived                packaging only
#   2  the .pc resolves                   consumers find the header at all
#   3  the probe runs to its end          libXv.a executes on this arm
#   4  the client ABI                     the arch-sensitive layout
#   5  the array walks                    XvFree{Adaptor,Encoding}Info, real code
#   6  the wire sizes                     the protocol's fixed encodings
#   7  the entry-point census             every client API, out of the archive
#   8  the protocol constants             the wire values
#   9  the display that is not there      the documented no-server path
#
# A build where 3 passes and 4 does not has a word-size fault in the toolchain
# rather than anything wrong with this recipe. One where 4 passes and 5 does not
# has the layout right and the library's own walk over it wrong, which is the
# single most consequential thing this port could get wrong and the reason the
# probe exists. 6 going red while 4 is green means a header moved, not a
# compiler.
# ---------------------------------------------------------------------------

# A root prefix, empty on the target and set only when this suite is validated
# NATIVELY under dash before it ships. The runner never sets it, so on the image
# every path below is exactly the absolute one.
R="${BST_LIBXV_ROOT:-}"

INC=$R/usr/include/X11/extensions
LIB=$R/usr/lib
PCD=$R/usr/lib/pkgconfig
XT=$R/usr/libexec/libxv-tests

work=${TMPDIR:-/tmp}/bst-libxv.$$
rm -rf "$work"; mkdir -p "$work"

hasfile() {
  if [ -s "$2" ]; then bst_ok "$1"; else bst_notok "$1" "missing or empty: $2"; fi
}

# xv_line <id> <unique-prefix> <expected-remainder>
#
# The prefix is matched with grep -F rather than the whole line, so a red reports
# WHAT THE PROBE ACTUALLY SAID for that case instead of merely "absent". Every
# prefix is unique by construction: each is a section tag plus a case name, and
# the case name is followed by a space that ends it.
xv_line() {
  _l=$(grep -m 1 -F -- "$2" "$work/out" 2>/dev/null)
  check_eq "$1" "$2$3" "$_l"
}

# ---------------------------------------------------------------------------
# 0. THE CANARY, which is not an assertion about libXv at all.
#
# The guest console drops a suite's FIRST BST result line before the host parser
# sees it -- brintos/linux#96. The harness computes its pass count as
# total-minus-failures, so THE DROPPED LINE IS COUNTED AS A PASS, and a suite
# whose first case is a genuine `not ok' loses the one line that mattered. So
# the first line out of this file asserts something already true.
# Remove this case when #96 is fixed.
bst_ok libxv/suite-canary

# ---------------------------------------------------------------------------
# 1. THE PAYLOAD.
#
# libXv ships exactly ONE header, and that is worth stating rather than counting:
# /usr/include/X11/extensions is shared with xorgproto and every other extension
# library, so a count taken here would start moving the day the next port lands.
# Xv.h and Xvproto.h live beside it and are xorgproto's, not this recipe's --
# they are asserted in section 2 as the things xv.pc's Requires resolve to.

check_rc libxv/dir-extensions 0 test -d "$INC"

hasfile libxv/hdr-Xvlib "$INC/Xvlib.h"

# The client API, by name, out of the installed header. Asserted on contents
# rather than size: a truncated install would still be non-empty, and these five
# structure names are what every consumer's translation unit refers to.
check libxv/hdr-has-XvAdaptorInfo \
  grep -q 'XvAdaptorInfo' "$INC/Xvlib.h"
check libxv/hdr-has-XvEncodingInfo \
  grep -q 'XvEncodingInfo' "$INC/Xvlib.h"
check libxv/hdr-has-XvImageFormatValues \
  grep -q 'XvImageFormatValues' "$INC/Xvlib.h"
check libxv/hdr-has-XvImage \
  grep -q 'XvImage' "$INC/Xvlib.h"
check libxv/hdr-has-XvAttribute \
  grep -q 'XvAttribute' "$INC/Xvlib.h"

# THE PACKAGE VERSION IS NOT IN THE HEADER, AND THAT IS NOT AN OMISSION.
# Xvlib.h defines no version macro at all. XvVersion and XvRevision exist, but
# they are in xorgproto's Xv.h and they are the PROTOCOL version -- 2.2, section
# 8 -- which has not moved in thirty years and says nothing about which libXv
# was installed. The package version is asserted through pkg-config (section 2)
# and through the probe, which was compiled with -DLIBXV_PV out of the recipe's
# own ${PV} (section 3), so a stale probe left by an earlier build cannot pass
# for this one. This case pins the absence, so that a future upstream which
# starts defining one is noticed rather than silently unasserted.
check_rc libxv/hdr-no-package-version 1 \
  grep -q 'XV_MAJOR_VERSION\|LIBXV_VERSION' "$INC/Xvlib.h"

# The delivery. bst_lib_shape rather than an assertion that no .so exists:
# BRINTOS-1740 retires the static-only premise one recipe at a time, so what
# survives conversion is that whatever IS shipped is usable.
hasfile libxv/archive "$LIB/libXv.a"
bst_lib_shape libxv/lib-shape "$LIB/libXv.so*"

hasfile libxv/probe-shipped "$XT/libxv-probe"

# ---------------------------------------------------------------------------
# 2. THE .pc -- how a consumer finds any of the above.

hasfile libxv/pc-present "$PCD/xv.pc"

# THE .pc IS ASSERTED ON ITS CONTENTS FIRST, AND THROUGH pkg-config SECOND.
# Read directly, these lines are true whatever else is installed; asked through
# pkg-config they are true only if the packages xv.pc NAMES are also on the
# image, which is a fact about the image rather than about this port. Both are
# worth having, and separating them is what makes a red say which.
check libxv/pc-requires-xproto \
  grep -q '^Requires:.*xproto' "$PCD/xv.pc"
check libxv/pc-requires-videoproto \
  grep -q '^Requires:.*videoproto' "$PCD/xv.pc"

# x11 and xext are PRIVATE requires, and correctly so: a consumer of the shared
# library would not need them, but this distro is static-only, so every consumer
# here does -- libXv.a reaches into libXext for the extension-info machinery its
# generated find_display expands to, and into Xlib for every request it encodes.
check libxv/pc-requires-private-x11 \
  grep -q '^Requires\.private:.*x11' "$PCD/xv.pc"
check libxv/pc-requires-private-xext \
  grep -q '^Requires\.private:.*xext' "$PCD/xv.pc"

check libxv/pc-libs-name grep -q '\-lXv' "$PCD/xv.pc"

if command -v pkg-config >/dev/null 2>&1; then
  bst_ok libxv/pkg-config-present

  # The graph queries below resolve xv.pc's requires, so they answer about
  # xorgproto-dev and libx11-dev as much as about this port. Gated on all of
  # them being present, and gated by NAME, so that an image missing one reports
  # which -- rather than reporting `xv.pc is broken', which it would not be.
  if [ -f "$PCD/xproto.pc" ] && [ -f "$PCD/videoproto.pc" ] && \
     [ -f "$PCD/x11.pc" ] && [ -f "$PCD/xext.pc" ]; then
    bst_ok libxv/pc-deps-present

    check libxv/pc-exists   pkg-config --exists xv
    check libxv/pc-validate pkg-config --validate xv
    check_eq libxv/pc-modversion 1.0.12 "$(pkg-config --modversion xv 2>/dev/null)"

    # PKG_CONFIG_ALLOW_SYSTEM_LIBS is required for the same reason
    # 57-xtrans.test records for its --cflags case: pkg-config SUPPRESSES a -L
    # naming a directory already on the linker's default path, so the bare query
    # answers usefully only for the -l part.
    check_out libxv/pc-libs -lXv \
      env PKG_CONFIG_ALLOW_SYSTEM_LIBS=1 pkg-config --libs xv

    # The static closure, which is what a consumer on THIS distro actually
    # links. --static is what makes pkg-config follow Requires.private, and a
    # recipe that forgot it is the defect BRINTOS-2456 measured on xcursorgen:
    # sixteen phantom imports and a refused image.
    check_out libxv/pc-static-pulls-xext -lXext \
      env PKG_CONFIG_ALLOW_SYSTEM_LIBS=1 pkg-config --static --libs xv
    check_out libxv/pc-static-pulls-x11 -lX11 \
      env PKG_CONFIG_ALLOW_SYSTEM_LIBS=1 pkg-config --static --libs xv
  else
    bst_skip libxv/pc-deps-present \
      "xv.pc requires xproto, videoproto, x11 and xext; one is missing on this image"
  fi
else
  bst_skip libxv/pkg-config-present "pkg-config not installed on this image"
fi

# ---------------------------------------------------------------------------
# 3. THE PROBE RUNS, AND RUNS TO ITS END.
#
# do_install ships it 0755, but the rootfs is read-only at browser runtime and
# the exec bit is not reliably readable there either, so it is copied to /tmp --
# a mode=1777 tmpfs with no noexec -- and given the bit where the copy lands.

probe=$work/libxv-probe
if cp "$XT/libxv-probe" "$probe" 2>/dev/null && chmod +x "$probe" 2>/dev/null; then
  # bst_probe bounds the run and emits libxv/probe-runs itself. The bound is
  # generous because the probe forks five children and waits on each; a probe
  # that WEDGED rather than crashed is what it is for, and a wedge here would
  # otherwise take the whole suite's wall clock.
  bst_probe libxv/probe-runs "$work/out" 120 "$probe"

  total=$(sed -n 's/^XV-TOTAL //p' "$work/out")
  if [ -n "$total" ]; then bst_ok libxv/probe-complete
  else bst_notok libxv/probe-complete \
    "no XV-TOTAL line: $(_bst_1line "$(tail -n 3 "$work/out" 2>/dev/null)")"; fi

  # The measurement count, bounded from below. Adding a fixture raises it; a
  # probe that got THINNER while still terminating cleanly is what this catches,
  # and nothing else here would -- every case below greps for what it expects, so
  # a line that stopped being printed is indistinguishable from one whose grep
  # simply found nothing. 136 was measured; the floor is set just under it so
  # that adding a case is not a red.
  #
  # The figure counts the PARENT's lines only. The three `heap-after' lines come
  # out of forked children and are scored individually in section 5, but do not
  # reach this counter -- so a child that died silently shows up there and not
  # here, which is the localisation this split is for.
  if [ -n "$total" ] && [ "$total" -ge 130 ]; then bst_ok libxv/probe-coverage
  else bst_notok libxv/probe-coverage \
    "reported ${total:-0} measurements, expected not less than 130"; fi

  # The version the archive was built from, reported by the binary rather than
  # read off a path.
  xv_line libxv/probe-version "XV-VERSION " "1.0.12"

  # -------------------------------------------------------------------------
  # 4. THE CLIENT ABI.
  #
  # THIS SECTION IS THE ONE THAT MUST DISAGREE WITH THE BUILD HOST. These five
  # structures are not protocol-fixed -- section 6's wire sizes are. They are
  # what the compiler laid out for THIS arm out of the members Xvlib.h declares,
  # and every one of them contains a `long' or a pointer, so every number below
  # is half its x86-64 value or thereabouts. A build that agreed with the
  # reference machine here would be an ILP32 target emitting LP64 layout, which
  # is the single fault most likely to survive a clean compile and corrupt the
  # first reply anybody parses.
  #
  # The word sizes come first, so that a red says which primitive moved rather
  # than only that a total did.

  xv_line libxv/abi-sizeof-long    "XV-ABI sizeof-long "    "4"
  xv_line libxv/abi-sizeof-pointer "XV-ABI sizeof-pointer " "4"
  xv_line libxv/abi-sizeof-int     "XV-ABI sizeof-int "     "4"

  xv_line libxv/abi-size-rational  "XV-ABI sizeof-XvRational "   "8"
  xv_line libxv/abi-size-attribute "XV-ABI sizeof-XvAttribute "  "16"
  xv_line libxv/abi-size-encoding  "XV-ABI sizeof-XvEncodingInfo " "28"
  xv_line libxv/abi-size-format    "XV-ABI sizeof-XvFormat "     "8"
  xv_line libxv/abi-size-adaptor   "XV-ABI sizeof-XvAdaptorInfo " "28"
  xv_line libxv/abi-size-image     "XV-ABI sizeof-XvImage "      "36"

  # XvImageFormatValues is the exception that proves the rule: every member is
  # an int or a fixed-size char array, so it is 128 bytes on BOTH machines, and
  # a red here is unambiguous evidence of a packing or alignment difference
  # rather than a word-size one.
  xv_line libxv/abi-size-imgfmt "XV-ABI sizeof-XvImageFormatValues " "128"

  # XvAdaptorInfo member by member. This is the structure XvQueryAdaptors fills
  # in from the reply and XvFreeAdaptorInfo walks, so a single wrong offset here
  # reads one field out of the neighbouring one for every adaptor on the server.
  xv_line libxv/abi-adaptor-base_id      "XV-ABI off-adaptor-base_id "      "0"
  xv_line libxv/abi-adaptor-num_ports    "XV-ABI off-adaptor-num_ports "    "4"
  xv_line libxv/abi-adaptor-type         "XV-ABI off-adaptor-type "         "8"
  # `type' is a char at 8 and `name' a pointer at 12: the three padding bytes
  # between them are the arch-sensitive seam in this structure, and on x86-64
  # there are seven.
  xv_line libxv/abi-adaptor-name         "XV-ABI off-adaptor-name "         "12"
  xv_line libxv/abi-adaptor-num_formats  "XV-ABI off-adaptor-num_formats "  "16"
  xv_line libxv/abi-adaptor-formats      "XV-ABI off-adaptor-formats "      "20"
  xv_line libxv/abi-adaptor-num_adaptors "XV-ABI off-adaptor-num_adaptors " "24"

  xv_line libxv/abi-encoding-id        "XV-ABI off-encoding-encoding_id "   "0"
  xv_line libxv/abi-encoding-name      "XV-ABI off-encoding-name "          "4"
  xv_line libxv/abi-encoding-width     "XV-ABI off-encoding-width "         "8"
  xv_line libxv/abi-encoding-height    "XV-ABI off-encoding-height "        "12"
  xv_line libxv/abi-encoding-rate      "XV-ABI off-encoding-rate "          "16"
  xv_line libxv/abi-encoding-count     "XV-ABI off-encoding-num_encodings " "24"

  xv_line libxv/abi-attribute-flags "XV-ABI off-attribute-flags "     "0"
  xv_line libxv/abi-attribute-min   "XV-ABI off-attribute-min_value " "4"
  xv_line libxv/abi-attribute-max   "XV-ABI off-attribute-max_value " "8"
  xv_line libxv/abi-attribute-name  "XV-ABI off-attribute-name "      "12"

  # XvFormat is `char depth; unsigned long visual_id;' -- one byte and then
  # three of padding here, seven on the build host. It is the smallest structure
  # in the library and the one whose stride a wrong alignment rule would move
  # first.
  xv_line libxv/abi-format-depth     "XV-ABI off-format-depth "     "0"
  xv_line libxv/abi-format-visual_id "XV-ABI off-format-visual_id " "4"

  # The two fixed-size char arrays, which must NOT move: a GUID and a component
  # order are bytes on the wire, and everything before them is an int. These
  # four numbers are identical on both machines.
  xv_line libxv/abi-imgfmt-guid      "XV-ABI off-imgfmt-guid "             "12"
  xv_line libxv/abi-imgfmt-guid-size "XV-ABI sizeof-imgfmt-guid "          "16"
  xv_line libxv/abi-imgfmt-order     "XV-ABI off-imgfmt-component_order "  "92"
  xv_line libxv/abi-imgfmt-order-size "XV-ABI sizeof-imgfmt-component_order " "32"
  xv_line libxv/abi-imgfmt-scanline  "XV-ABI off-imgfmt-scanline_order "   "124"

  # XvImage is five ints and then four pointers, so it is where the word size
  # shows up most plainly: 36 bytes here, 56 on the build host.
  xv_line libxv/abi-image-num_planes "XV-ABI off-image-num_planes " "16"
  xv_line libxv/abi-image-pitches    "XV-ABI off-image-pitches "    "20"
  xv_line libxv/abi-image-offsets    "XV-ABI off-image-offsets "    "24"
  xv_line libxv/abi-image-data       "XV-ABI off-image-data "       "28"
  xv_line libxv/abi-image-obdata     "XV-ABI off-image-obdata "     "32"

  # THE STRIDES, which is the quantity the walks in section 5 actually use.
  # C fixes them equal to the sizes above; they are derived from the type rather
  # than restated, and asserted separately, so that `the layout and the walk
  # disagree' reports as a different defect from `both are wrong in the same
  # way'.
  xv_line libxv/abi-stride-adaptor   "XV-ABI stride-adaptor "   "28"
  xv_line libxv/abi-stride-encoding  "XV-ABI stride-encoding "  "28"
  xv_line libxv/abi-stride-attribute "XV-ABI stride-attribute " "16"
  xv_line libxv/abi-stride-imgfmt    "XV-ABI stride-imgfmt "    "128"
  xv_line libxv/abi-stride-format    "XV-ABI stride-format "    "8"

  # -------------------------------------------------------------------------
  # 5. THE ARRAY WALKS -- THE ONLY libXv CODE THIS IMAGE CAN EXECUTE.
  #
  # XvFreeAdaptorInfo and XvFreeEncodingInfo, driven out of libXv.a over heap
  # arrays built to the contract XvQueryAdaptors leaves behind: the head element
  # carries the total, because the parse writes `pa->num_adaptors =
  # rep.num_adaptors - ii' (Xv.c:230), a countdown.
  #
  # WHAT A GREEN HERE IS AND IS NOT EVIDENCE OF. Each fixture runs in a forked
  # child and the case is the child's exit status, so a walk that strode off the
  # array is reported here rather than ending the probe. Exiting 0 proves the
  # walk did not reach free() with a pointer the allocator could recognise as
  # invalid; it does not prove the stride was right in a way that happened to
  # stay inside the allocation. The `heap-after' cases are the second half --
  # an allocation burst after the walk, which is where a corrupted free list
  # that did not abort during the free shows up.
  #
  # Each name and each format block in the fixture is its OWN allocation,
  # deliberately: a single slab carved up by hand would make every wrong stride
  # look like a right one.

  xv_line libxv/free-stride-adaptor  "XV-FREE stride-adaptor "  "28"
  xv_line libxv/free-stride-encoding "XV-FREE stride-encoding " "28"
  xv_line libxv/free-n-adaptors      "XV-FREE adaptors "        "8"
  xv_line libxv/free-n-encodings     "XV-FREE encodings "       "8"

  # NULL is documented safe for both -- `if (!pAdaptors) return' is the first
  # statement of each -- and it is what XvQueryAdaptors leaves in the caller's
  # out-parameter on EVERY failure path, which on this image is every path. So
  # it is the state a client here would always be freeing, and a port that got
  # it wrong would crash every consumer's cleanup rather than any of its work.
  xv_line libxv/free-null "XV-FREE null exited " "0"

  # A head count of zero: the body must not run and only the base is released.
  # This is the shape a short reply produces -- the init loop has zeroed every
  # count and the parse failed before the second loop wrote the total. The
  # fixture's names and format blocks are deliberately left allocated, so a walk
  # that ran anyway would free them and this case would not be the one to say so
  # quietly.
  xv_line libxv/free-zero-count "XV-FREE zero-count exited " "0"

  xv_line libxv/free-walk-adaptors  "XV-FREE walk-adaptors exited "  "0"
  xv_line libxv/free-adaptors-heap  "XV-FREE adaptors-heap-after "   "ok"
  xv_line libxv/free-walk-encodings "XV-FREE walk-encodings exited " "0"
  xv_line libxv/free-encodings-heap "XV-FREE encodings-heap-after "  "ok"

  # The name pointer is optional -- both loops guard it with `if (pa->name)' --
  # and an array in which only some elements carry one is exactly what a partial
  # parse leaves behind. A walk with the right stride and a wrong guard frees a
  # NULL, which is harmless, or skips a live one, which leaks; this case is here
  # for the third possibility, a guard read from the wrong offset.
  xv_line libxv/free-sparse-names "XV-FREE sparse-names exited " "0"
  xv_line libxv/free-sparse-heap  "XV-FREE sparse-heap-after "   "ok"

  # The probe reached the end of this section rather than being killed inside a
  # waitpid. Separated from the fixtures so that `fork does not work here' is
  # distinguishable from `a walk was wrong'.
  xv_line libxv/free-end "XV-FREE reached-end " "yes"

  # -------------------------------------------------------------------------
  # 6. THE WIRE SIZES.
  #
  # Unlike section 4 these ARE fixed by the X Video protocol and are identical
  # on every architecture: they are the byte counts XvQueryAdaptors strides its
  # reply pointer by while parsing. A wasm32 build that computed a different one
  # would read each adaptor's name out of the middle of the previous record --
  # and would do it on a reply that arrived perfectly intact, which is why this
  # is measured rather than assumed.

  xv_line libxv/wire-rational "XV-WIRE sz_xvRational "       "8"
  xv_line libxv/wire-adaptor  "XV-WIRE sz_xvAdaptorInfo "    "12"
  xv_line libxv/wire-encoding "XV-WIRE sz_xvEncodingInfo "   "20"
  xv_line libxv/wire-format   "XV-WIRE sz_xvFormat "         "8"
  xv_line libxv/wire-attribute "XV-WIRE sz_xvAttributeInfo " "16"
  xv_line libxv/wire-imgfmt   "XV-WIRE sz_xvImageFormatInfo " "128"

  # The padded strides. pad_to_int32 is static in Xv.c and cannot be called from
  # the probe, so these are a RESTATEMENT of its expression rather than an
  # execution of it -- what they catch is a header whose sz_ constant moved, not
  # a compiler that rounds differently. All three are already multiples of four,
  # which is the protocol's doing and is worth pinning: a future constant that
  # was not would change how every later record in the reply is addressed.
  xv_line libxv/wire-pad-adaptor  "XV-WIRE pad-xvAdaptorInfo "  "12"
  xv_line libxv/wire-pad-encoding "XV-WIRE pad-xvEncodingInfo " "20"
  xv_line libxv/wire-pad-format   "XV-WIRE pad-xvFormat "       "8"

  # Every reply header in this extension is one fixed size, and a client that
  # disagreed would mis-frame the first reply it ever read.
  xv_line libxv/wire-reply-adaptors  "XV-WIRE sz_xvQueryAdaptorsReply "  "32"
  xv_line libxv/wire-reply-encodings "XV-WIRE sz_xvQueryEncodingsReply " "32"
  xv_line libxv/wire-reply-extension "XV-WIRE sz_xvQueryExtensionReply " "32"

  # -------------------------------------------------------------------------
  # 7. THE ENTRY-POINT CENSUS.
  #
  # Section 9 establishes that no display opens here, which makes every entry
  # point below unreachable -- so the only thing left to say about them is that
  # they EXIST: that the cross build compiled them, that the static linker
  # resolved each name out of libXv.a, and that the address is in the shipped
  # image. Taking the address is what forces the archive member in, so a name the
  # build had silently dropped fails the LINK in do_compile.
  #
  # THIS CENSUS IS WEAKER THAN 57-libxext.test's AND THE COUNT SAYS WHY. libXv is
  # ONE translation unit, so its twenty-three stand or fall together where
  # libXext's ninety-six can lose a module at a time. What it still catches is a
  # visibility or packaging change that stopped exporting part of the API.

  nsym=$(sed -n 's/^XV-SYM-COUNT //p' "$work/out")
  if [ -n "$nsym" ] && [ "$nsym" -ge 23 ]; then bst_ok libxv/sym-count
  else bst_notok libxv/sym-count \
    "census names ${nsym:-0} entry points, expected not less than 23"; fi

  xv_line libxv/sym-none-null "XV-SYM-NULL " "0"

  # One per family rather than all twenty-three: the discovery calls, the
  # drawing calls, the port calls, the attribute calls, the image calls, and the
  # two the probe actually executes.
  for s in XvQueryExtension XvQueryAdaptors XvQueryEncodings \
           XvPutVideo XvPutImage XvShmPutImage \
           XvGrabPort XvUngrabPort XvStopVideo \
           XvSetPortAttribute XvGetPortAttribute XvQueryPortAttributes \
           XvListImageFormats XvCreateImage XvShmCreateImage \
           XvFreeAdaptorInfo XvFreeEncodingInfo; do
    xv_line "libxv/sym-$s" "XV-SYM $s " "linked"
  done

  # -------------------------------------------------------------------------
  # 8. THE PROTOCOL CONSTANTS.
  #
  # Wire values fixed by the X Video extension specification. A client that
  # disagrees with a server about XvInputMask does not fail to build -- it asks
  # for the wrong half of the adaptors and reports that none exist. Stated from
  # the specification rather than diffed against anything: there is nothing about
  # a second machine that could make an answer here more true.

  xv_line libxv/const-name     "XV-CONST XvName "     "XVideo"
  xv_line libxv/const-version  "XV-CONST XvVersion "  "2"
  xv_line libxv/const-revision "XV-CONST XvRevision " "2"

  # The adaptor type bits. XvInput and XvOutput are POSITIONS, the masks are the
  # bits -- a client that confused the two would ask for output adaptors and get
  # input ones, which is a silent wrong answer rather than an error.
  xv_line libxv/const-input       "XV-CONST XvInput "      "0"
  xv_line libxv/const-output      "XV-CONST XvOutput "     "1"
  xv_line libxv/const-input-mask  "XV-CONST XvInputMask "  "1"
  xv_line libxv/const-output-mask "XV-CONST XvOutputMask " "2"
  xv_line libxv/const-video-mask  "XV-CONST XvVideoMask "  "4"
  xv_line libxv/const-still-mask  "XV-CONST XvStillMask "  "8"
  xv_line libxv/const-image-mask  "XV-CONST XvImageMask "  "16"
  # The drawable-type bits sit two bytes up, not beside the others.
  xv_line libxv/const-pixmap-mask "XV-CONST XvPixmapMask " "65536"
  xv_line libxv/const-window-mask "XV-CONST XvWindowMask " "131072"

  xv_line libxv/const-gettable "XV-CONST XvGettable " "1"
  xv_line libxv/const-settable "XV-CONST XvSettable " "2"

  xv_line libxv/const-rgb          "XV-CONST XvRGB "          "0"
  xv_line libxv/const-yuv          "XV-CONST XvYUV "          "1"
  xv_line libxv/const-packed       "XV-CONST XvPacked "       "0"
  xv_line libxv/const-planar       "XV-CONST XvPlanar "       "1"
  xv_line libxv/const-toptobottom  "XV-CONST XvTopToBottom "  "0"
  xv_line libxv/const-bottomtotop  "XV-CONST XvBottomToTop "  "1"

  xv_line libxv/const-video-notify "XV-CONST XvVideoNotify " "0"
  xv_line libxv/const-port-notify  "XV-CONST XvPortNotify "  "1"
  xv_line libxv/const-num-events   "XV-CONST XvNumEvents "   "2"

  # The protocol ERRORS, which are offsets from the server's first_error.
  xv_line libxv/const-bad-port     "XV-CONST XvBadPort "     "0"
  xv_line libxv/const-bad-encoding "XV-CONST XvBadEncoding " "1"
  xv_line libxv/const-bad-control  "XV-CONST XvBadControl "  "2"
  xv_line libxv/const-num-errors   "XV-CONST XvNumErrors "   "3"

  # The STATUS codes an entry point returns, which are a different namespace
  # from the errors above and overlap them numerically -- XvBadPort is 0 and
  # XvBadExtension is 1. XvBadExtension is what every call on this image would
  # give back, if one could be made at all.
  xv_line libxv/const-bad-extension  "XV-CONST XvBadExtension "  "1"
  xv_line libxv/const-already-grabbed "XV-CONST XvAlreadyGrabbed " "2"
  xv_line libxv/const-invalid-time   "XV-CONST XvInvalidTime "   "3"
  xv_line libxv/const-bad-reply      "XV-CONST XvBadReply "      "4"
  xv_line libxv/const-bad-alloc      "XV-CONST XvBadAlloc "      "5"

  xv_line libxv/const-started   "XV-CONST XvStarted "       "0"
  xv_line libxv/const-stopped   "XV-CONST XvStopped "       "1"
  xv_line libxv/const-busy      "XV-CONST XvBusy "          "2"
  xv_line libxv/const-preempted "XV-CONST XvPreempted "     "3"
  xv_line libxv/const-harderror "XV-CONST XvHardError "     "4"
  xv_line libxv/const-nreasons  "XV-CONST XvNumReasons "    "5"
  xv_line libxv/const-anyreason "XV-CONST XvAnyReasonMask " "31"

  # -------------------------------------------------------------------------
  # 9. THE DISPLAY THAT IS NOT THERE.
  #
  # The documented no-server path, and the reason sections 4 to 8 are what this
  # suite tests instead of the Xv API. What must hold is that it SAYS so --
  # NULL, for each spelling of a display -- rather than crashing, blocking, or
  # handing back a half-built Display that the first XvQueryAdaptors would then
  # walk into.
  #
  # THE unix-0 CASE IS THE ONE PLACE THIS SUITE CANNOT BE VALIDATED AGAINST THE
  # BUILD HOST. A developer's workstation usually HAS a server on :0, so the
  # reference run of this probe opened it; on the image there is none and the
  # answer is NULL. 57-libxext.test pins the same four the same way, against the
  # same image, which is the evidence this one rests on.
  #
  # Note what is NOT here. No entry point is called with a NULL Display: every
  # one of them opens with xv_find_display(dpy), which reaches XextAddDisplay
  # and dereferences, so that would be undefined behaviour rather than a
  # documented failure. The ticket's `a port id that was never returned' and `a
  # call made without a prior successful QueryExtension' are unreachable for
  # exactly this reason -- both need a Display to be asked through -- and they
  # are recorded here as unreachable rather than left looking unasserted.

  xv_line libxv/dpy-no-env  "XV-DPY no-env "  "NULL"
  xv_line libxv/dpy-unix-0  "XV-DPY unix-0 "  "NULL"
  xv_line libxv/dpy-unix-99 "XV-DPY unix-99 " "NULL"
  xv_line libxv/dpy-tcp     "XV-DPY tcp "     "NULL"
  xv_line libxv/dpy-end     "XV-DPY reached-end " "yes"
else
  bst_notok libxv/probe-stage "cannot stage $XT/libxv-probe"
fi

rm -rf "$work"