1. 03 Jul, 2017 2 commits
  2. 25 Jun, 2017 2 commits
  3. 12 Jun, 2017 9 commits
  4. 23 May, 2017 2 commits
  5. 19 May, 2017 2 commits
  6. 18 May, 2017 1 commit
  7. 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>
      eca5cca5
  8. 21 Apr, 2017 1 commit
    • Bryce Harrington's avatar
      desktop-shell: Enable per-output fade animations · 9ad4de1f
      Bryce Harrington authored
      Instead of creating a single global fade surface across all outputs,
      create a separate surface for each output.  This will permit
      e.g. individual fades for each output (or blocking the fade-outs if
      inhibiting idling as will come in a later patch.)
      
      This also fixes a potential issue if on multihead layout spanning a
      desktop wider than 8096 (or higher than 8096), the fade animation may
      not completely cover all surfaces.
      
      This assumes the output geometry doesn't change to become larger during
      the course of the fade animation.
      Signed-off-by: default avatarBryce Harrington <bryce@osg.samsung.com>
      Reviewed-by: Quentin Glidic's avatarQuentin Glidic <sardemff7+git@sardemff7.net>
      9ad4de1f
  9. 13 Apr, 2017 4 commits
    • 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>
      2cd87fe8
    • Pekka Paalanen's avatar
      libweston-desktop/xwayland: react to geometry changes · 5f93b9f6
      Pekka Paalanen authored
      Fix up the window position whenever the geometry info changes.
      
      If the window geometry changes, we want to keep the input-responding
      content anchored to top-left. It is done by manipulating the dx,dy
      arguments originating from a wl_surface.attach request.
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: Louis-Francis Ratté-Boulianne's avatarLouis-Francis Ratté-Boulianne <lfrb@collabora.com>
      Acked-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      5f93b9f6
    • Pekka Paalanen's avatar
      xwm: use _XWAYLAND_ALLOW_COMMITS · 7ace831c
      Pekka Paalanen authored
      This patch uses the new feature proposed for Xwayland in the patch
      series https://patchwork.freedesktop.org/series/16610/ .
      
      When the frame window is created, immediately forbid Xwayland commits on
      it. This prevents commits before the decorations have been drawn and the
      initial pending state has been set. Commits are enabled right after
      drawing and setting.
      
      This ensures that the decorations are fully drawn when a window is
      mapped. This also solves the initial commit/pending race, but the race
      is on again after mapping.
      
      If Xwayland does not implement the needed support, we are just setting a
      window property with no effect.
      
      This patch is the final piece for solving T7622, excluding the
      _NET_WM_SYNC_REQUEST handling.
      
      Task: https://phabricator.freedesktop.org/T7622Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: Louis-Francis Ratté-Boulianne's avatarLouis-Francis Ratté-Boulianne <lfrb@collabora.com>
      Acked-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      7ace831c
    • Pekka Paalanen's avatar
      xwm: do not draw decor twice on map · ad0da459
      Pekka Paalanen authored
      Normal windows enter the MapRequest handler, which schedules drawing the
      decorations. Then Xwayland realizes the window, which ends with a call
      to xserver_map_shell_surface(). The decorations are already drawn, no
      need to draw them a second time. However, MapRequest handler could not
      set the pending state because the weston_surface did not exist at the
      time, because it gets created only when Xwayland realizes the window,
      which happens after XWM has forwarded the MapWindow in MapRequest
      handler. Therefore set the pending state explicitly at the end.
      Scheduling had it done much later anyway.
      
      Now that the pending state is set much earlier, it seems to be more
      likely that it gets set before Xwayland's first commit is handled. This
      means that -geometry command line option of X11 apps already takes the
      geometry (decorations) into account. I do not think it is reliable yet,
      though.
      
      There is still the race between Xwayland committing and XWM setting the
      pending state assuming the very next commit latches it in appropriately.
      The race exists not because of Wayland, but because WL_SURFACE_ID comes
      via X11, and could be processed after wl_compositor.create_surface and
      wl_surface.commit. That commit/pending race is solved by a following patch.
      
      For override-redirect windows weston_wm_window_schedule_repaint()
      reduced into a call to weston_wm_window_set_pending_state_OR(), so we
      can just call that directly. It should not matter that the call is moved
      to the end of the function.
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: Louis-Francis Ratté-Boulianne's avatarLouis-Francis Ratté-Boulianne <lfrb@collabora.com>
      Acked-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      ad0da459
  10. 12 Apr, 2017 1 commit
  11. 11 Apr, 2017 1 commit
  12. 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
      modesetting.
      
      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>
      08d4edf2
    • 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
      buffer.
      
      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
      expecting.
      Signed-off-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      205c0a01
    • 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>
      65d87d07
    • 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
      flushed.
      
      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>
      f30a18c1
  13. 07 Apr, 2017 10 commits