1. 10 Apr, 2017 4 commits
    • Daniel Stone's avatar
      compositor-drm: Rename drm_sprite to drm_plane · 08d4edf2
      Daniel Stone authored
      We make the differentiation where planes are an abstract framebuffer
      with a position within a CRTC/output, and sprites are special cases of
      planes that are neither the primary (base/framebuffer) nor cursor plane.
      drm_sprite, OTOH, contains nothing that's actually specific to sprites,
      and we end up duplicating a lot of code to deal with them, especially
      when we come to use an entirely plane-based interface with atomic
      Rename drm_sprite to drm_plane, to reflect that it's actually generic.
      No functional changes.
      Signed-off-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: Quentin Glidic's avatarQuentin Glidic <sardemff7+git@sardemff7.net>
      [Pekka: dropped the removal of an unrelated comment]
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
    • Daniel Stone's avatar
      compositor-drm: Clean up page_flip_pending path · 205c0a01
      Daniel Stone authored
      page_flip_pending is only be set when do a pageflip to a newly-rendered
      buffer; if the flag is not set, we have landed in the start_repaint_loop
      path where the vblank query fails, and thus we must pageflip to the same
      This test was not sufficient for what it was supposed to guard:
      releasing framebuffers back. When using client-supplied framebuffers, it
      is possible to reuse the same buffer multiple times, and we would send a
      framebuffer-release event too early.
      However, since we have a properly reference-counted drm_fb now, we can
      just drop this test, and rely on the reference counting to prevent
      too-early release of client framebuffers.
      page_flip_pending now becomes exactly what the name suggests: a flag
      which indicates whether or not we are expecting a pageflip event. Add
      asserts here to verify that we never receive a pageflip event we weren't
      Signed-off-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
    • Daniel Stone's avatar
      compositor-drm: Turn vblank_pending from bool to refcount · 65d87d07
      Daniel Stone authored
      vblank_pending is currently a bool, which is reset on every vblank
      requests (i.e. sprite pageflip). This can occur more than once per
      frame, so turn it into a callback, so we only fire frame-done when we've
      collected all the events.
      This fixes unexpected behaviour when multiple views per output have been
      promoted to DRM planes.
      Signed-off-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
    • Daniel Stone's avatar
      compositor-drm: Introduce fb_last member · f30a18c1
      Daniel Stone authored
      Previously, framebuffers were stored as fb_current and fb_pending.
      In this scheme, current was the last buffer that the kernel/hardware had
      acknowledged displaying: a framebuffer would be created, set as
      fb_pending, and Weston would request the kernel display it. When the
      kernel signals that the request was completed and the hardware had made
      the buffer current (i.e. page_flip_handler / vblank_handler), we would
      unreference the old fb_current, and promote fb_pending to fb_current.
      In other words, the view is 'which buffer has turned to light?'.
      This patch changes them to a tristate of fb_last, fb_current and
      fb_pending, based around the kernel's view of the current state.
      fb_pending is used purely as a staging area for request construction;
      when the kernel acknowledges a request (e.g. drmModePageFlip returns 0),
      the previous buffer is moved to fb_last, and this new buffer to
      fb_current. When the kernel signals that the request has completed and
      the hardware has made the buffer current, we simply unreference and
      clear fb_last, without touching fb_current/fb_pending.
      The view here is now 'which state is current in the kernel?'.
      As all state changes are incremental on the last state submitted to the
      kernel, even if the hardware has not yet been able to make it current,
      this simplifies state tracking: all state submissions will always be
      relative to fb_current, rather than the previous
      (fb_pending) ? fb_pending : fb_current.
      The use of fb_pending is strictly bounded between a repaint cycle
      (including a grouped set of repaints) beginning, and those repaints
      being flushed to the kernel.
      fb_current will always be valid between an output's first repaint
      flush, and when a disable/destroy request has been processed. For a
      plane, it will be valid when a repaint cycle enabling that plane has
      been flushed, and when a repaint cycle disabling that plane has been
      fb_last is only present when a repaint request for the output/plane has
      been submitted, but not yet completed by the hardware.
      This is the same set of constructs which will be used for storing
      plane/output state objects in future patches.
      Signed-off-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
  2. 07 Apr, 2017 11 commits
  3. 30 Mar, 2017 1 commit
  4. 14 Mar, 2017 1 commit
  5. 13 Mar, 2017 2 commits
  6. 07 Mar, 2017 1 commit
    • Emmanuel Gil Peyrot's avatar
      compositor-drm: pageflip timeout implementation · 11ae2a30
      Emmanuel Gil Peyrot authored
      Weston will not repaint until previous update has been acked by a
      pageflip event coming from the drm driver. However, some buggy drivers
      won’t return those events or will stop sending them at some point and
      Weston output repaints will completely freeze. To ease developers’ task
      in testing their drivers, this patch makes compositor-drm use a timer
      to detect cases where those pageflip events stop coming.
      This timeout implementation is software only and includes basic
      features usually found in a watchdog. We simply exit Weston gracefully
      with a log message and an exit code when the timout is reached.
      The timeout value can be set via weston.ini by adding a
      pageflip-timeout=<MILLISECONDS> entry under [core]
      section. Setting it to 0 disables the timeout feature.
      - Made sure we would get both the pageflip and the vblank events before
        stopping the timer.
      - Reordered the error and success cases in
        drm_output_pageflip_timer_create() to be more in line with the rest
        of the code.
      - Reordered (de)arming of the timer with the code around it to avoid it
        being rearmed before the current dearming.
      - Return the proper value for the dispatcher in the pageflip_timeout
      - Also display the output name in case the timer fires.
      - Reordered a forgotten timer rearming after its drmModePageFlip().
      Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=83884
      Signed-off-by: Frederic Plourde <frederic.plourde at collabora.co.uk>
      Signed-off-by: default avatarEmmanuel Gil Peyrot <emmanuel.peyrot@collabora.com>
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
  7. 27 Feb, 2017 4 commits
  8. 13 Feb, 2017 1 commit
  9. 09 Feb, 2017 3 commits
  10. 07 Feb, 2017 2 commits
  11. 06 Feb, 2017 1 commit
  12. 26 Jan, 2017 1 commit
  13. 17 Jan, 2017 2 commits
  14. 03 Jan, 2017 1 commit
  15. 12 Dec, 2016 5 commits