We are currently experiencing downtime impacting viewing & cloning the Mesa repo, and some GitLab pages returning 503. Please see #freedesktop on IRC for more updates.

  1. 19 Aug, 2020 2 commits
    • Michael Olbrich's avatar
      pipewire: implement DPMS · a24a326b
      Michael Olbrich authored
      Pipewire doesn't need to wait for any hardware. The finish_frame() callback is
      just artifically delayed to generate the desired framerate.
      So when the DPMS level changes, we can just call finish_frame() immediately if
      necessary and cancel the timer.
      Signed-off-by: Michael Olbrich's avatarMichael Olbrich <m.olbrich@pengutronix.de>
    • Michael Olbrich's avatar
      drm: always check the repaint_status in update_complete · d70e712c
      Michael Olbrich authored
      Initially finish_frame() was never called in drm_output_update_complete() for
      'dpms_off_pending = true'. This is wrong for repaint_status ==
      REPAINT_AWAITING_COMPLETION and that was fixed in
      68d49d77 ("compositor-drm: run finish_frame when
      dpms is turned off in update_complete").
      However finish_frame() may now be called for repaint_status !=
      REPAINT_AWAITING_COMPLETION, which is not allowed and results in a failed
      Fix this by checking dpms and repaint_status unconditionally.
      Signed-off-by: Michael Olbrich's avatarMichael Olbrich <m.olbrich@pengutronix.de>
  2. 18 Aug, 2020 1 commit
    • Marius Vlad's avatar
      backend-drm: Correctly tear down the DRM backend · 5130a8c2
      Marius Vlad authored
      It seem that we skipped to put back in TEXT mode the tty, in case a DRM
      device node wasn't present at that time, or it isn't present at all. This
      orders the destroy part correctly as to handle that case as well.
      As a side effect, as the tty will still be set to GRAPHICS mode we will
      require a manual change of the tty number, which might be not possible
      on all systems. Properly putting back the tty to TEXT mode should avoid
      that, and allows to re-use the same tty no in case the DRM device has
      been created at a later point in time.
      Signed-off-by: Marius Vlad's avatarMarius Vlad <marius.vlad@collabora.com>
  3. 17 Aug, 2020 8 commits
  4. 14 Aug, 2020 2 commits
  5. 13 Aug, 2020 2 commits
  6. 12 Aug, 2020 1 commit
  7. 11 Aug, 2020 1 commit
    • Michael Olbrich's avatar
      compositor: use weston_view_is_opaque() to check for opacity in debug_scene_view_print() · b7e5f10b
      Michael Olbrich authored
      Currently the debug output for 'drm-backend' can be confusing. In the output of
      debug_scene_view_print() views may be listed as 'not opaque' but later, during
      plane assignment, other views underneath such a view is reported as 'occluded on
      our output'.
      This happens because weston_view_is_opaque() has some extra checks to determine
      if a view is fully opaque, such as 'is_opaque' provided by the renderer for
      formats that have no alpha channel.
      Use weston_view_is_opaque() in debug_scene_view_print() as well to get more
      accurate results.
      Signed-off-by: Michael Olbrich's avatarMichael Olbrich <m.olbrich@pengutronix.de>
  8. 06 Aug, 2020 1 commit
  9. 30 Jul, 2020 2 commits
  10. 28 Jul, 2020 1 commit
  11. 09 Jul, 2020 1 commit
  12. 01 Jul, 2020 2 commits
  13. 25 Jun, 2020 2 commits
    • Leandro Ribeiro's avatar
      gitlab CI: add support for DRM-backend tests · a12ba0b3
      Leandro Ribeiro authored
      In order to run DRM-backend tests, a DRM-device is needed. As we
      do not necessarily have control of the hardware that is going to
      run our tests in GitLab CI, DRM-backend tests were being skipped.
      This patch add support to run the tests using VKMS (virtual KMS).
      To achieve this, virtualization is needed, as we need to run a
      custom kernel during the CI job. We've decided to go with virtme,
      as it is simpler to setup and works good for our use case.
      Signed-off-by: Leandro Ribeiro's avatarLeandro Ribeiro <leandro.ribeiro@collabora.com>
    • Leandro Ribeiro's avatar
      launcher: do not touch VT/tty while using non-default seat · 887a7e57
      Leandro Ribeiro authored
      Launcher-direct does not allow us to run using a different
      seat from the default seat0. This happens because VTs are
      only exposed to the default seat, and users that are on
      non-default seat should not touch VTs.
      Add check in launcher-direct to skip VT/tty management if user
      is running on a non-default seat.
      Signed-off-by: Leandro Ribeiro's avatarLeandro Ribeiro <leandro.ribeiro@collabora.com>
  14. 24 Jun, 2020 1 commit
    • Frank Binns's avatar
      shared: fix unused variable warning · 77d06f7b
      Frank Binns authored
      Fix the following build warning by moving the 'seals' declaration inside the
      HAVE_MEMFD_CREATE guard:
        ../shared/os-compatibility.c: In function ‘os_ro_anonymous_file_get_fd’:
        ../shared/os-compatibility.c:341:6: warning: unused variable ‘seals’ [-Wunused-variable]
          int seals, fd;
      Signed-off-by: Frank Binns's avatarFrank Binns <frank.binns@imgtec.com>
  15. 23 Jun, 2020 1 commit
  16. 12 Jun, 2020 1 commit
  17. 11 Jun, 2020 1 commit
    • Tomek Bury's avatar
      gl-renderer: fix pbuffer surface creation · ba548311
      Tomek Bury authored
      When there's neither configless nor surfaceless EGL extension
      (i.e. not a Mesa driver), Weston falls back to a dummy pbuffer surface.
      Weston attempts to find for that surface an EGL config but uses a NULL
      array of pixel formats. This fails with the following messages:
       EGL_KHR_surfaceless_context unavailable. Trying PbufferSurface
       Found an EGLConfig matching { pbf;  } but it is not usable because
          neither EGL_KHR_no_config_context nor EGL_MESA_configless_context
          are supported by EGL.
       failed to choose EGL config for PbufferSurface
       EGL error state: EGL_SUCCESS (0x3000)
       Failed to initialise the GL renderer;
      Signed-off-by: Tomek Bury's avatarTomek Bury <tomek.bury@broadcom.com>
  18. 04 Jun, 2020 1 commit
    • Scott Anderson's avatar
      drm: Fix leak of damage blob id · 15c603ca
      Scott Anderson authored
      This moves the creation of the blob to be earlier, to when the damage is
      calculated. It replaces the damage tracked inside of the plane state
      with the blob id itself.
      This should stop creating new blob ids for TEST_ONLY commits, and them
      being leaked in general, as the blob ids are now freed with the plane
      The FB_DAMAGE_CLIPS property is now always set if it's supported, and
      will be 0 in the case that we have no damage information, which
      signifies full damage to the kernel.
      Signed-off-by: Scott Anderson's avatarScott Anderson <scott.anderson@collabora.com>
  19. 03 Jun, 2020 2 commits
  20. 02 Jun, 2020 5 commits
    • Leandro Ribeiro's avatar
      tests: add drm-backend smoke test · b1c529e9
      Leandro Ribeiro authored
      This adds the first DRM-backend test. It is very simple
      and was made in order to make easier to add more complex
      DRM-backend tests in the future.
      Signed-off-by: Leandro Ribeiro's avatarLeandro Ribeiro <leandro.ribeiro@collabora.com>
    • Leandro Ribeiro's avatar
      tests: add support to run drm-backend tests locally · e8a8c13e
      Leandro Ribeiro authored
      With this patch we add support to run DRM-backend tests locally
      in the test suite. For now this won't work in the CI, as there
      are no cards available. But the plan is to achieve this by using
      VKMS (virtual KMS) in the future.
      To run DRM-backend tests locally, first of all the user has to
      set the environment variable WESTON_TEST_SUITE_DRM_DEVICE to
      'card0', 'card1' or any other device where he wants to run
      the tests. Also, for now it only works if it is run as root,
      but in the future this problem will be solved.
      The tests will run on a non-default seat. The reason for that
      is that we want to avoid opening input devices unnecessarily.
      Also, since DRM-backend usage requires gaining DRM master status
      on a DRM KMS device, nothing else must be using the device at
      the same time. To achieve this we use a lock to run the
      DRM-backend tests sequentially.
      Signed-off-by: Leandro Ribeiro's avatarLeandro Ribeiro <leandro.ribeiro@collabora.com>
    • Leandro Ribeiro's avatar
      drm-backend: add --continue-without-input command line option to DRM-backend · e57d8ae8
      Leandro Ribeiro authored
      In the test suite we may want to run a DRM-backend test on a
      non-default seat, which may not have a input device associated.
      Weston's default behavior is to not open if input devices are
      not found, as it may cause troubles. For instance, Weston can
      open but if no input device is set than the user can not
      interact or leave it.
      Add flag --continue-without-input to DRM-backend so we can run
      these types of tests with no input. Notice that this won't force
      the compositor to skip opening a input device if it finds it on
      the non-default seat.
      Signed-off-by: Leandro Ribeiro's avatarLeandro Ribeiro <leandro.ribeiro@collabora.com>
    • Leandro Ribeiro's avatar
      tests: properly select renderer for DRM-backend · 7b37b4d3
      Leandro Ribeiro authored
      The test suite is dealing only with headless-backend tests.
      In order to make it able to run DRM-backend tests, we have
      to properly select the renderer that it will use.
      This patch add the command line option --use-pixman if the test
      defines the DRM-backend renderer as RENDERER_PIXMAN, and it will
      add nothing to the command line if it defines RENDERER_GL (the
      DRM-backend default renderer is already GL). Also, if the user
      defines the DRM-backend renderer as RENDERER_NOOP, the test will
      fail (as it should, since DRM-backend does not implement it).
      Signed-off-by: Leandro Ribeiro's avatarLeandro Ribeiro <leandro.ribeiro@collabora.com>
    • Leandro Ribeiro's avatar
      tests: don't use width and height for drm/fbdev backend tests · e8033e3d
      Leandro Ribeiro authored
      In the test suite we have some default options which
      are command line arguments used by most of the tests.
      Two of these are width==320 and height==240. But
      when we have DRM or fbdev backends, width and height
      are not possible command line arguments. This makes
      impossible to run tests that uses one of these types
      of backends, as the compositor won't open if the
      command line string is wrong.
      Fix this by not passing command line arguments width
      and height if the backend is DRM or fbdev.
      Signed-off-by: Leandro Ribeiro's avatarLeandro Ribeiro <leandro.ribeiro@collabora.com>
  21. 01 Jun, 2020 2 commits