1. 03 Jul, 2017 2 commits
  2. 12 Jun, 2017 5 commits
  3. 23 May, 2017 1 commit
  4. 19 May, 2017 1 commit
  5. 02 May, 2017 1 commit
    • Daniel Stone's avatar
      Account for very large repaint window misses · eca5cca5
      Daniel Stone authored
      At the bottom of weston_output_finish_frame(), code exists to account
      for flips which have missed the repaint window, by shifting them to lock
      on to the next repaint window rather than repainting immediately.
      This code only accounted for flips which missed their target by one
      repaint window. If they miss by multiples of the repaint window, adjust
      them until the next repaint timestamp is in the future. This will only
      happen in fairly extreme situations, such as Weston being scheduled out
      for a punitively long period of time. Nevertheless, try to help recovery
      by still aiming for more predictable timings.
      Signed-off-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
  6. 13 Apr, 2017 1 commit
    • Derek Foreman's avatar
      compositor-drm: Fix disabling cursor plane · 2cd87fe8
      Derek Foreman authored
      commit a7cba1d4 changed the way
      the cursor plane is setup.  Previously it was pre-emptively set
      disabled for the next frame, and that would be changed at next
      frame time if the cursor plane was to be used.  It was changed
      to be disabled at plane assignment time.
      We disable the use of planes entirely by setting disable_planes to
      a non-zero value, which bypasses all calls to assign_planes - so
      if the plane was set-up in the previous frame it will retain its
      state post-disable.
      This leads to desktop zoom leaving the cursor plane in place when
      it sets disable_planes.
      This patch clears any stale cursor plane state from the redraw
      handler if disable_planes is set so drm_output_set_cursor()
      will do the right thing.
      Reviewed-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Reported-by: default avatarEmmanuel Gil Peyrot <emmanuel.peyrot@collabora.com>
  7. 11 Apr, 2017 1 commit
  8. 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>
  9. 07 Apr, 2017 13 commits
  10. 30 Mar, 2017 3 commits
  11. 25 Mar, 2017 1 commit
  12. 24 Mar, 2017 3 commits
  13. 22 Mar, 2017 1 commit
  14. 17 Mar, 2017 2 commits
  15. 14 Mar, 2017 1 commit