From 08dbd29e3333d4041cbdb1a3c36590ebc554547b Mon Sep 17 00:00:00 2001 From: Leandro Ribeiro Date: Mon, 7 Feb 2022 21:26:59 -0300 Subject: [PATCH] gitlab-ci: compile Linux image with support to VGEM Add VGEM to the Linux image that runs in the CI. There are tests that we plan to add in the future that need this. This brings a complication, as we already have VKMS in the image. The order in which DRM devices are loaded is not always the same, so the node they receive is non-deterministic. Until now we were sure that VKMS (the virtual device we use to run the DRM-backend tests in the CI) would be in "/dev/dri/card0", but now we can't be sure. To deal with this problem we find the node of each device using a one-liner shell script. This commit also updates the documentation section that describes specificities of DRM-backend tests in our test suite. Signed-off-by: Leandro Ribeiro --- .gitlab-ci.yml | 2 +- .gitlab-ci/build-deps.sh | 3 ++- .gitlab-ci/virtme-scripts/run-weston-tests.sh | 9 ++++++++- doc/sphinx/toc/test-suite.rst | 17 +++++++++++++---- 4 files changed, 24 insertions(+), 7 deletions(-) diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index 4210e007..e68b5741 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -43,7 +43,7 @@ variables: FDO_UPSTREAM_REPO: wayland/weston FDO_REPO_SUFFIX: "$BUILD_OS/$BUILD_ARCH" - FDO_DISTRIBUTION_TAG: '2022-01-22.0-for-axbgr16161616' + FDO_DISTRIBUTION_TAG: '2022-02-07.00-add-vgem-to-ci' include: diff --git a/.gitlab-ci/build-deps.sh b/.gitlab-ci/build-deps.sh index f707aa59..67e06701 100755 --- a/.gitlab-ci/build-deps.sh +++ b/.gitlab-ci/build-deps.sh @@ -75,7 +75,8 @@ if [[ -n "$KERNEL_DEFCONFIG" ]]; then --enable CONFIG_DRM \ --enable CONFIG_DRM_KMS_HELPER \ --enable CONFIG_DRM_KMS_FB_HELPER \ - --enable CONFIG_DRM_VKMS + --enable CONFIG_DRM_VKMS \ + --enable CONFIG_DRM_VGEM make ARCH=${LINUX_ARCH} oldconfig make ARCH=${LINUX_ARCH} diff --git a/.gitlab-ci/virtme-scripts/run-weston-tests.sh b/.gitlab-ci/virtme-scripts/run-weston-tests.sh index 66da7b33..a45f9668 100755 --- a/.gitlab-ci/virtme-scripts/run-weston-tests.sh +++ b/.gitlab-ci/virtme-scripts/run-weston-tests.sh @@ -7,8 +7,15 @@ chmod -R 0700 /tmp # set environment variables to run Weston tests export XDG_RUNTIME_DIR=/tmp/tests -export WESTON_TEST_SUITE_DRM_DEVICE=card0 export LIBSEAT_BACKEND=seatd +# In our test suite, we use VKMS to run DRM-backend tests. The order in which +# devices are loaded is not predictable, so the DRM node that VKMS takes can +# change across each boot. That's why we have this one-liner shell script to get +# the appropriate node for VKMS. +export WESTON_TEST_SUITE_DRM_DEVICE=$(basename /sys/devices/platform/vkms/drm/card*) +# To run tests in the CI that exercise the zwp_linux_dmabuf_v1 implementation in +# Weston, we use VGEM to allocate buffers. +export WESTON_TEST_SUITE_ALLOC_DEVICE=$(basename /sys/devices/platform/vgem/drm/card*) # ninja test depends on meson, and meson itself looks for its modules on folder # $HOME/.local/lib/pythonX.Y/site-packages (the Python version may differ). diff --git a/doc/sphinx/toc/test-suite.rst b/doc/sphinx/toc/test-suite.rst index f7803292..65083988 100644 --- a/doc/sphinx/toc/test-suite.rst +++ b/doc/sphinx/toc/test-suite.rst @@ -218,10 +218,19 @@ DRM-backend tests DRM-backend tests require a DRM device, so they are a special case. To select a device the test suite will simply look at the environment variable -``WESTON_TEST_SUITE_DRM_DEVICE``. So the first thing the user has to do in order -to run DRM-backend tests is to set this environment variable with the card that -should run the tests. For instance, in order to run DRM-backend tests with -``card0`` we need to run ``export WESTON_TEST_SUITE_DRM_DEVICE=card0``. +``WESTON_TEST_SUITE_DRM_DEVICE``. In Weston's CI, we set this variable to the +DRM node that VKMS takes (``cardX`` - X can change across each bot, as the order +in which devices are loaded is not predictable). + +**IMPORTANT**: our DRM-backend tests are written specifically to run on top of +VKMS (KMS driver created to be used by headless machines in test suites, so it +aims to be more configurable and predictable than real hardware). We don't +guarantee that these tests will work on real hardware. + +But if users want to run DRM-backend tests using real hardware anyway, the first +thing they need to do is to set this environment variable with the DRM node of +the card that should run the tests. For instance, in order to run DRM-backend +tests with ``card0`` we need to run ``export WESTON_TEST_SUITE_DRM_DEVICE=card0``. Note that the card should not be in use by a desktop environment (or any other program that requires master status), as there can only be one user at a time