1. 24 Jul, 2017 3 commits
  2. 21 Jul, 2017 1 commit
  3. 20 Jul, 2017 1 commit
  4. 18 Jul, 2017 1 commit
  5. 12 Jul, 2017 3 commits
  6. 03 Jul, 2017 5 commits
  7. 25 Jun, 2017 2 commits
  8. 12 Jun, 2017 9 commits
  9. 23 May, 2017 2 commits
  10. 19 May, 2017 2 commits
  11. 18 May, 2017 1 commit
  12. 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
  13. 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
  14. 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
  15. 12 Apr, 2017 1 commit
  16. 11 Apr, 2017 1 commit
  17. 10 Apr, 2017 2 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