1. 26 Sep, 2020 4 commits
    • Erik Kurzinger's avatar
      Update .gitlab-ci/debian-install.sh to pull meson 0.50 · c3c4cefe
      Erik Kurzinger authored
      
      
      Which is the minimum required version for building the
      libnvidia-egl-wayland prerequisite.
      Signed-off-by: default avatarMiguel A Vico Moya <mvicomoya@nvidia.com>
      c3c4cefe
    • Miguel A. Vico's avatar
      Update .gitlab-ci.yml to install wayland-eglstream protocols · 40eb4372
      Miguel A. Vico authored and Erik Kurzinger's avatar Erik Kurzinger committed
      
      
      Otherwise, Gitlab CI will fail because it won't be able to find
      wayland-eglstream-protocols package.
      Signed-off-by: default avatarMiguel A Vico Moya <mvicomoya@nvidia.com>
      40eb4372
    • Miguel A. Vico's avatar
      compositor: Process stream attach requests with wl_eglstream_controller · 0e3bba55
      Miguel A. Vico authored and Erik Kurzinger's avatar Erik Kurzinger committed
      So far, the EGLStream implementation of the Wayland client-side driver
      has been using wl_surface_attach + commit in order to make the server
      create its stream endpoint and attach a consumer to it.
      
      However, no actual buffer would be actually shared between client and
      server, which goes against many of the assumptions behind
      wl_surface_attach + commit.
      
      This has caused different interaction issues in the past.
      
      In order to properly resolve this once and for all, a new
      wl_eglstream_controller protocol has been added which will let clients
      request the compositor to create its stream.
      
      This change adds the required code for weston to create a
      wl_eglstream_controller global and process attach_eglstream_consumer
      requests.
      
      [mvicomoya: - Dynamically load libnvidia-egl-wayland.so.1 instead linking
                    against it
                  - Add wayland-eglstream-protocols package dependency and
                    generate server header for wayland-egls...
      0e3bba55
    • Miguel A. Vico's avatar
      backend-drm: Add support for EGLDevice+EGLOutput · 8f9701ca
      Miguel A. Vico authored and Erik Kurzinger's avatar Erik Kurzinger committed
      
      
      As previously stated, EGLDevice and EGLOutput will provide means
      to access native device objects and different portions of display
      control hardware respectively.
      
      Whenever EGL_EXT_device_drm extension is present, EGLDevice can
      be used to enumerate and access DRM KMS devices, and EGLOutputLayer
      to enumerate and access DRM KMS crtcs and planes.
      
      By using EGLStreams and attaching an EGLOutputLayer consumer
      (representing a DRM KMS crtc or plane) to it, backend-drm can
      produce final composition frames and present them on a DRM device.
      
      This change adds required logic to support presentation through
      EGLDevice+EGLOutput+EGLStream. Whether GBM or EGLDevice should be
      used can be controlled by --use-egldevice backend argument.
      Signed-off-by: default avatarMiguel A Vico Moya <mvicomoya@nvidia.com>
      Reviewed-by: default avatarAndy Ritger <aritger@nvidia.com>
      Reviewed-by: default avatarAdam Cheney <acheney@nvidia.com>
      Reviewed-by: James Jones's avatarJames Jones <jajones@nvidia.com>
      8f9701ca
  2. 19 Sep, 2020 4 commits
  3. 04 Sep, 2020 1 commit
  4. 27 Aug, 2020 3 commits
  5. 26 Aug, 2020 8 commits
  6. 24 Aug, 2020 1 commit
  7. 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>
      a24a326b
    • 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
      assertion.
      
      Fix this by checking dpms and repaint_status unconditionally.
      Signed-off-by: Michael Olbrich's avatarMichael Olbrich <m.olbrich@pengutronix.de>
      d70e712c
  8. 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>
      5130a8c2
  9. 17 Aug, 2020 8 commits
  10. 14 Aug, 2020 2 commits
  11. 13 Aug, 2020 2 commits
  12. 12 Aug, 2020 1 commit
  13. 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>
      b7e5f10b
  14. 06 Aug, 2020 1 commit
  15. 30 Jul, 2020 1 commit