Skip to content
Snippets Groups Projects
  1. Jul 11, 2018
    • Daniel Stone's avatar
      compositor-drm: Enable planes for atomic · 678aabe8
      Daniel Stone authored
      
      Now that we can sensibly test proposed plane configurations with atomic,
      sprites are not broken.
      
      Signed-off-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      678aabe8
    • Daniel Stone's avatar
      compositor-drm: Relax plane restrictions for atomic · 9fe4bf88
      Daniel Stone authored
      
      Since we now incrementally test atomic state as we build it, we can
      loosen restrictions on what we can do with planes, and let the kernel
      tell us whether or not it's OK.
      
      Signed-off-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      9fe4bf88
    • Daniel Stone's avatar
      compositor-drm: Allow scanout plane to be occluded by overlay · b41abf9c
      Daniel Stone authored
      
      a0f8276f ("compositor-drm: Disallow overlapping overlay planes") was
      a little too pessimistic in rejecting occluded views. Whilst it
      correctly prevented overlay planes from occluding each other, it also
      prevented overlay planes from occluding the scanout plane.
      
      This is undesirable: the primary/scanout plane is specified to stack
      strictly below all overlay planes, so there is no need to reject a plane
      from consideration for scanout due to being occluded by an overlay
      plane.
      
      Shift the check downwards so it only applies to overlay rather than
      scanout planes.
      
      Signed-off-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      b41abf9c
    • Daniel Stone's avatar
      compositor-drm: Incrementally test plane states in mixed mode · a284d271
      Daniel Stone authored
      
      In the plane-only mode, we try to place every view on a hardware plane,
      and fail if we can't do this. This requires a full walk of the scene
      graph to come up with a complete configuration in order to be able to
      test.
      
      In mixed mode, we know at least some visible views will fail to be
      promoted to planes and must be composited via the renderer. In order to
      still use some planes where possible, we use atomic modesetting's
      test-only mode to incrementally test configurations.
      
      We know that the renderer output will always be visible, and because it
      is the renderer, that it will be occupying the scanout plane underneath
      everything else. The actual renderer buffer doesn't materialise until
      after assign_planes, because it cannot know what to render until then.
      
      However, in order to test whether a configuration is valid, we need the
      renderer buffer in the scanout plane. For testing, we fake this by
      temporarily stealing the old buffer - if it seems sufficiently
      compatible - and placing it in the state we construct. This is used to
      test whether or not a renderer buffer will work with the addition of
      overlay planes.
      
      Doing this incremental testing will allow us to enable plane usage for
      atomic by default, since we know ahead of time that our chosen plane
      configuration will work.
      
      Signed-off-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      a284d271
    • Daniel Stone's avatar
      compositor-drm: Add planes-only mode to state proposal · d12e5164
      Daniel Stone authored
      
      Add a new mode, which attempts to construct a scene exclusively using
      planes. This is a building block for incrementally testing and
      constructing state: in the plane-only mode, we test the state exactly
      once, when we have constructed a full set of planes and want to know if
      it works or not.
      
      When using the renderer, we need to incrementally test views one by one
      to see if they will work on planes, falling back to the renderer if not.
      This test is different, since the scanout plane will be occupied by the
      renderer's buffer. Testing using the renderer or client buffers may have
      completely different characteristics, so we need two passes: first,
      constructing a state with only planes and testing if that succeeds,
      falling back later to a mixed renderer/plane mode which tests
      incrementally.
      
      This implements the first mode, and preferentially attempts to use it.
      
      Signed-off-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      d12e5164
    • Daniel Stone's avatar
      compositor-drm: Never lift solid surfaces to planes · ca6fbe3c
      Daniel Stone authored
      
      This will never work, so don't even try to do it.
      
      Signed-off-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      ca6fbe3c
    • Daniel Stone's avatar
      compositor-drm: Add test-only mode to state application · bb6c19f7
      Daniel Stone authored
      
      The atomic API can allow us to test state before we apply it, to see if
      it will be valid. Use this when we construct a plane configuration, to
      see if it has a chance of ever working. If not, we can fail
      assign_planes early.
      
      This will be used in later patches to incrementally build state by
      proposing and testing potential configurations one at a time.
      
      Signed-off-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      bb6c19f7
    • Daniel Stone's avatar
      compositor-drm: Return plane state from plane preparation · f829062e
      Daniel Stone authored
      
      Return a pointer to the plane state, rather than returning its
      underlying weston_plane. This eliminates any ambiguity between placing
      client buffers on planes, and placing them through the renderer.
      
      drm_output_propose_state is only concerned with preparing, testing, and
      returning DRM state objects. Assigning views to weston_planes only
      happens later, inside drm_assign_planes. This makes that split more
      clear.
      
      Signed-off-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      f829062e
    • Daniel Stone's avatar
      compositor-drm: Add modes to drm_output_propose_state · f7a2f835
      Daniel Stone authored
      
      Add support for multiple modes to drm_output_propose_state. Currently we
      intend to operate in three modes: planes-only (no renderer buffer,
      client buffers in planes only), mixed-mode (promote client buffers to
      planes where possible, falling back to the renderer where not), and
      renderer-only (no plane usage at all).
      
      We want to use the first (planes-only) mode where possible: it can avoid
      us having to allocate buffers for the renderer, and it also gives us the
      best chance of the optimal configuration, with no composition. In this
      mode, we walk the scene looking at all views, trying to put them in
      planes, and failing as soon as we find a view we cannot place in a
      plane.
      
      In the second mode, rather than failing, we assign those views which
      cannot be on a plane to the renderer, and allow the renderer to
      composite them.
      
      In the third mode, planes are not usable, so everything but the cursor
      goes to the renderer. We will use this when we cannot use the planes-only
      mode (because some views cannot be placed in planes), but also cannot
      use the 'mixed' mode because we have no renderer buffer yet. Since we
      walk the scene graph from top to bottom, using atomic modesetting we
      will determine if planes can be promoted in mixed mode by placing a
      renderer buffer at the bottom of the scene, placing a cursor buffer if
      applicable, then testing if we can add overlay planes to this mode.
      
      Without a buffer from the renderer, we cannot do these tests, so we push
      everything through the renderer and then switch to mixed mode on the
      next repaint.
      
      This patch implements the mixed and renderer-only modes (previously
      differentiated only by the sprites_are_broken flag), with the
      planes-only mode being left for a later patch.
      
      Signed-off-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      f7a2f835
    • Daniel Stone's avatar
      compositor-drm: Use sprites_are_broken for scanout plane · 44abfaaf
      Daniel Stone authored
      
      When the sprites_are_broken variable is set, do not attempt to promote
      client surfaces to the scanout plane.
      
      We are currently assuming that every client buffer will be compatible
      with the scanout plane, but that is not the case, particularly with more
      exotic tiled/compressed buffers. Once we promote the client buffer to
      scanout, there is no going back: if the repaint fails, we do not mark
      this as failed and go back to repaint through composition.
      
      This permanently removes the ability for scanout bypass when using the
      non-atomic path. Future patches lift the restriction when using atomic
      modesetting, as we can actually test and ensure that the view is
      compatible with scanout.
      
      Signed-off-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reported-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      44abfaaf
    • Daniel Stone's avatar
      compositor-drm: Disallow overlapping overlay planes · a0f8276f
      Daniel Stone authored
      
      The scanout plane strictly stacks under all overlay planes, and the
      cursor plane above. However, the stacking of overlay planes with respect
      to each other is undefined.
      
      We can control the stacking order of overlay planes with the zpos
      property, though this significantly complicates plane assignment. In the
      meantime, simply disallow assigning a view to an overlay, when it
      overlaps another view which is already on an overlay. This ensures
      stacking order is irrelevant, since the planes never intersect each
      other.
      
      Signed-off-by: Daniel Stone's avatarDaniel Stone <daniels@collabora.com>
      Reviewed-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      a0f8276f
  2. Jul 10, 2018
  3. Jul 09, 2018
  4. Jul 06, 2018
  5. Jul 05, 2018
    • Pekka Paalanen's avatar
      libweston: fix output reflow on removal · 9711fd98
      Pekka Paalanen authored
      
      This is regression apparently introduced in
      0de859ed, which accidentally swapped the
      sign of 'delta_width' in the original call site. If one removes an
      output, the remaining outputs on the right are getting moved even
      further to the right.
      
      The outputs to the right should be moved to the left instead, to close
      the gap left by the removed output.
      
      Reported-by: default avatarTomasz Olszak <olszak.tomasz@gmail.com>
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: default avatarIan Ray <ian.ray@ge.com>
      9711fd98
    • Pekka Paalanen's avatar
      desktop-shell: fix output removal for background/panel · 82dd54d9
      Pekka Paalanen authored
      
      When the compositor has multiple outputs (not clones) and one of them is
      removed, the ones remaining to the right will be moved to close the gap.
      Because reflowing the remaining outputs happens before removing the
      wl_output global, we get the new output x,y before the removal. This
      causes us to consider the remaining output immediately to the right of
      the removed output to be a clone of the removed output whose x,y don't
      get updated. That will then hit the two assertions this patch removes.
      
      The reason the assertions were not actually hit is because of a
      compositor bug which moved the remaining outputs in the wrong direction.
      The next patch will fix the reflow, so we need this patch first to avoid
      the asserts.
      
      Remove the assertions and hand over the background and panel if the
      "clone" does not already have them. If the clone already has them, we
      destroy the unnecessary background and panel.
      
      Signed-off-by: Pekka Paalanen's avatarPekka Paalanen <pekka.paalanen@collabora.co.uk>
      Reviewed-by: default avatarMarius Vlad <marius-cristian.vlad@nxp.com>
      82dd54d9
  6. Jul 03, 2018
Loading