1. 06 Feb, 2019 2 commits
    • Alexandros Frantzis's avatar
      libweston: Support zwp_surface_synchronization_v1.set_acquire_fence · acff29b3
      Alexandros Frantzis authored
      Implement the set_acquire_fence request of the
      zwp_surface_synchronization_v1 interface.
      The implementation uses the acquire fence in two ways:
      1. If the associated buffer is used as GL render source, an
         EGLSyncKHR is created from the fence and used to synchronize
      2. If the associated buffer is used as a plane framebuffer,
         the acquire fence is treated as an in-fence for the atomic
         commit operation. If in-fences are not supported and the buffer
         has an acquire fence, we don't consider it for plane placement.
      If the used compositor/renderer doesn't support explicit
      synchronization, we don't advertise the protocol at all. Currently only
      the DRM and X11 backends when using the GL renderer advertise the
      protocol for production use.
      Issues for discussion
      a. Currently, a server-side wait of EGLSyncKHR is performed before
         using the EGLImage/texture during rendering. Unfortunately, it's not clear
         from the specs whether this is generally safe to do, or we need to
         sync before glEGLImageTargetTexture2DOES. The exception is
         TEXTURE_EXTERNAL_OES where the spec mentions it's enough to sync
         and then glBindTexture for any changes to take effect.
      Changes in v5:
        - Meson support.
        - Make explicit sync server error reporting more generic, supporting
          all explicit sync related interfaces not just
        - Fix typo in warning for missing EGL_KHR_wait_sync extension.
        - Support minor version 2 of the explicit sync protocol (i.e., support
          fences for opaque EGL buffers).
      Changes in v4:
        - Introduce and use fd_clear and and fd_move helpers.
        - Don't check for a valid buffer when updating surface acquire fence fd
          from state.
        - Assert that pending state acquire fence fd is always clear
          after a commit.
        - Clarify that WESTON_CAP_EXPLICIT_SYNC applies to just the
        - Check for EGL_KHR_wait_sync before using eglWaitSyncKHR.
        - Dup the acquire fence before passing to EGL.
      Changes in v3:
        - Keep acquire_fence_fd in surface instead of buffer.
        - Clarify that WESTON_CAP_EXPLICIT_SYNC applies to both backend and
        - Move comment about non-ownership of in_fence_fd to struct
          drm_plane_state definition.
        - Assert that we don't try to use planes with in-fences when using the
          legacy KMS API.
        - Remove unnecessary info from wayland error messages.
        - Handle acquire fence for subsurface commits.
        - Guard against self-update in fd_update.
        - Disconnect the client if acquire fence EGLSyncKHR creation or wait
        - Use updated protocol interface names.
        - User correct format specifier for resource ids.
        - Advertise protocol for X11 backend with GL renderer.
      Changes in v2:
        - Remove sync file wait fallbacks.
        - Raise UNSUPPORTED_BUFFER error at commit if we have an acquire
          fence, but the committed buffer is not a valid linux_dmabuf.
        - Don't put buffers with in-fences on planes that don't support
        - Don't advertise explicit sync protocol if backend does not
          support explicit sync.
      Signed-off-by: Alexandros Frantzis's avatarAlexandros Frantzis <alexandros.frantzis@collabora.com>
    • Alexandros Frantzis's avatar
      libweston: Introduce zwp_linux_explicit_synchronization_v1 · 27d7c395
      Alexandros Frantzis authored
      Introduce support for the zwp_linux_explicit_synchronization_unstable_v1
      protocol with an implementation of the zwp_linux_explicit_synchronization_v1
      Explicit synchronization provides a more versatile notification
      mechanism for buffer readiness and availability, and can be used to
      improve efficiency by integrating with related functionality in display
      and graphics APIs.
      In addition, the per-commit nature of the release events provided by
      this protocol potentially offers a solution to a deficiency of the
      wl_buffer.release event (see
      Support for this protocol depends on the capabilities of the backend, so
      we don't register it by default but provide a function which each
      backend will need to call. In this commit only the headless backend when
      using the noop renderer supports this to enable testing.
      Note that the zwp_surface_synchronization_v1 interface, which contains
      the core functionality of the protocol, is not implemented in this
      commit. Support for it will be added in future commits.
      Changes in v7:
        - Added some information in the commit message about the benefits of
          the explicit sync protocol.
      Changes in v6:
        - Fall back to advertising minor version 1 of the explicit sync protocol,
          although we support minor version 2 features, until the new
          wayland-protocols version is released.
      Changes in v5:
        - Meson support.
        - Advertise minor version 2 of the explicit sync protocol.
      Changes in v4:
        - Enable explicit sync support in the headless backend for all
      Changes in v3:
        - Use wl_resource_get_version() instead of hardcoding version 1.
        - Use updated protocol interface names.
        - Use correct format specifier for resource id.
        - Change test name to 'linux-explicit-synchronization.weston'
      Changes in v2:
        - Move implementation to separate file so protocol can be registered
          on demand by backends.
        - Register protocol in headless+noop backend for testing purposes.
      Signed-off-by: Alexandros Frantzis's avatarAlexandros Frantzis <alexandros.frantzis@collabora.com>
  2. 15 Jun, 2015 1 commit
  3. 08 Aug, 2013 1 commit
  4. 06 Apr, 2012 1 commit
    • Benjamin Franzke's avatar
      Introduce weston-launch · bfeda130
      Benjamin Franzke authored
      weston-launch starts weston and provides mechanism
      for weston to set/drop drm master, open a tty,
      and read input devices without being root.
      Execution is allowed for local-active sessions
      or users in the group weston-launch.
  5. 03 Jan, 2012 1 commit
    • Kristian H. Kristensen's avatar
      Rename wayland-compositor to weston · 8334bc1e
      Kristian H. Kristensen authored
      This rename addresses a few problems around the split between core
      Wayland and the wayland-demos repository.
      1) Initially, we had one big repository with protocol code, sample
      compositor and sample clients.  We split that repository to make it
      possible to implement the protocol without pulling in the sample/demo
      code.  At this point, the compositor is more than just a "demo" and
      wayland-demos doesn't send the right message.  The sample compositor
      is a useful, self-contained project in it's own right, and we want to
      move away from the "demos" label.
      2) Another problem is that the wayland-demos compositor is often
      called "the wayland compsitor", but it's really just one possible
      compositor.  Existing X11 compositors are expected to add Wayland
      support and then gradually phase out/modularize the X11 support, for
      example.  Conversely, it's hard to talk about the wayland-demos
      compositor specifically as opposed to, eg, the wayland protocol or a
      wayland compositor in general.
      We are also renaming the repo to weston, and the compositor
      subdirectory to src/, to emphasize that the main "output" is the
  6. 18 Dec, 2011 1 commit