1. 11 Apr, 2019 1 commit
  2. 10 Apr, 2019 2 commits
  3. 30 Mar, 2019 1 commit
  4. 28 Mar, 2019 1 commit
    • John Stultz's avatar
      drm_hwcomposer: Tweak mode selection to pick the first DRM_MODE_TYPE_PREFERRED mode · a3429c7a
      John Stultz authored
      With commit 1b1e35eb
      
       ("drm_hwcomposer: Chose preferred mode with
      type DRM_MODE_TYPE_PREFERRED"), we now pick a preferred mode
      rather then just the first mode to use.
      
      However, on some systems there may erroniously be multiple modes
      marked as DRM_MODE_TYPE_PREFERRED. In this case, the logic added
      in that commit ends up selecting the *last* preferred mode.
      
      This seems less likely to be the desired choice, compared to
      what we had before (which picked first mode provided).
      
      So this patch alters the selection logic to only use the first
      DRM_MODE_TYPE_PREFERRED mode found, rather than the last.
      
      Change-Id: Ieb3e5d946b96099f14c1c5a287ca8113360a39d1
      Signed-off-by: John Stultz's avatarJohn Stultz <john.stultz@linaro.org>
      a3429c7a
  5. 19 Mar, 2019 1 commit
  6. 18 Mar, 2019 3 commits
  7. 15 Mar, 2019 1 commit
  8. 06 Mar, 2019 3 commits
  9. 05 Mar, 2019 1 commit
  10. 28 Feb, 2019 2 commits
    • John Stultz's avatar
      drm_hwcomposer: Initialize buffer_ pointer to NULL · 6230703e
      John Stultz authored
      
      
      In some cases, we've seen drm_hwcomposer start to try to
      compose frames before anything has called SetClientTarget().
      
      This seems to be some sort of a race, which for some reason
      we only see with certain dummy HDMI dongles (which provide
      fake EDID data) which allow our lab machines to run headless.
      I'm still trying to understand more about why this happens
      only in this case.
      
      The net of the issue is we see CreateComposition() being called,
      which adds the client_layer_ to the zmap. Then it creates the
      DrmHwcLayers copying the non-initialized buffer_ value as the
      sf_handle.
      
      This then later causes a crash in ImportBuffer() when we
      traverse the non-null (but invalid) hnd value.
      
      Thus, this patch simply initilizes the buffer_ pointer to NULL
      so that we error out properly in the case of the race.
      
      Reported-by: Yongqin Liu's avatarYongQin Liu <yongqin.liu@linaro.org>
      Signed-off-by: John Stultz's avatarJohn Stultz <john.stultz@linaro.org>
      Change-Id: I5fde3fccde86519edb04e61cbc2842eda395ade4
      6230703e
    • John Stultz's avatar
      drm_hwcomposer: platformhisi: Conditionalize some of the AFBC support · 65c988de
      John Stultz authored
      
      
      Unfortunately with the AFBC support patches, I validated with
      the hikey960 (which has a gralloc that supports AFBC), but not
      with the original hikey board (which does not support AFBC).
      
      Since we use the same importer for both boards, conditionalize
      the AFBC logic if those values are not defined.
      
      This patch will also need a tweak to the hikey gralloc to add
      support for the handle->internal_format reference (which doesn't
      currently exist on hikey's gralloc).
      
      Change-Id: I31aea82b321ff7dd7608c6a3522cbc93bb629319
      Signed-off-by: John Stultz's avatarJohn Stultz <john.stultz@linaro.org>
      65c988de
  11. 31 Jan, 2019 1 commit
    • Ayan Kumar Halder's avatar
      drm_hwcomposer: Add support for Arm Framebuffer Compression (AFBC) modifiers. · cc5fca4f
      Ayan Kumar Halder authored and Ayan Kumar Halder's avatar Ayan Kumar Halder committed
      
      
      One needs to translate the Gralloc buffer flags for AFBC (eg
      MALI_GRALLOC_INTFMT_AFBC_BASIC) to the corresponding linux kernel drm modifiers.
      This gets passed to libdrm via drmModeAddFB2WithModifiers.
      
      Changes from v1:-
      - Moved ConvertGrallocFormatToDrmModifiers() and IsDrmFormatRgb() from 'DrmGenericImporter'
      to 'HisiImporter' as suggested by Sean paul
      - Check if the format is rgb and set AFBC_FORMAT_MOD_YTR only if any of the AFBC related
      Gralloc flags are set.
      
      Changes from v2:-
      - Changed ConvertGrallocFormatToDrmModifiers() and IsDrmFormatRgb() from 'public' to 'private'
      (suggested by Sean Paul)
      
      Changes from v3:-
      - Reordered the members of 'class HisiImporter'. Functions should go above member variables.
      (suggested by Sean Paul)
      
      Changes from v4:-
      - Rebased and some style changes (as suggested by gitlab-ci-checkcommit.sh)
      
      Signed-off-by: Ayan Kumar Halder's avatarAyan Kumar Halder <ayan.halder@arm.com>
      Reviewed-by: Sean Paul's avatarSean Paul <seanpaul@chromium.org>
      
      /-- Note for reviewer
      I was able to get this working for hikey960 with aosp/master for kernel 4.14. The libdrm
      headers need to be updated as the AFBC modifiers are missing in the aosp/master's external/libdrm.
      --/
      
      Change-Id: I66abaa08d19ce88169cc40522b167dfe5efc7036
      cc5fca4f
  12. 30 Jan, 2019 1 commit
  13. 15 Jan, 2019 1 commit
  14. 14 Dec, 2018 1 commit
    • Jorge E. Moreira's avatar
      drm_hwcomposer: Complete rename of DrmResources to DrmDevice · 5047b229
      Jorge E. Moreira authored and John Stultz's avatar John Stultz committed
      
      
      In AOSP/master, there was a structure renamed, so try to sync
      AOSP/master's build fix change to freedesktop/master.
      
      NOTE: I'm not sure how to best submit this, as the upstream
      freedesktop/master may have users outside of AOSP/master. But
      I'm not sure what devices on an official release are using
      drm_hwc so it seems like this would be more useful then not.
      
      Bug: 116154944
      Test: builds
      Change-Id: I244bd049afae6ba8310f6b6bf2d3b1ee2e891de3
      Signed-off-by: John Stultz's avatarJohn Stultz <john.stultz@linaro.org>
      5047b229
  15. 03 Dec, 2018 1 commit
    • Alexey Firago's avatar
      drm_hwcomposer: platformhisi: Remove fake-importing · c385afe4
      Alexey Firago authored
      
      
      With CanImportBuffer() in place we don't need fake importing
      anymore. Buffers should be checked before supplied to ImportBuffer()
      and plane planner.
      
      Instead of fake importing return -EINVAL for non HW_FB buffers in
      ImportBuffer() and skip non HW_FB in planner. Additionally, return
      error from planner if we didn't emplace any layer to force client
      compositing.
      
      Signed-off-by: default avatarAlexey Firago <alexey_firago@mentor.com>
      c385afe4
  16. 27 Nov, 2018 1 commit
  17. 09 Oct, 2018 2 commits
    • Alexandru Gheorghe's avatar
      drm_hwcomposer: Add z order support · ea1c5e5a
      Alexandru Gheorghe authored
      
      
      Currently, the planner just pops the first available drm plane and if
      that can't be used for the DrmHwcLayer it just returns error.
      
      This proposes a slighlty smarter way to do that by trying to see if
      any of the DrmPlane can be used for the DrmHwcLayer in question.
      
      More, if the drm_plane doesn't have a fix zorder then we could re-add
      him to the list of unused planes, so it could be used for hosting
      other less demanding DrmHwcLayers.
      
      Signed-off-by: default avatarAlexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
      ea1c5e5a
    • Alexandru Gheorghe's avatar
      drm_hwcomposer: Propagate PlanStage error · 2234d377
      Alexandru Gheorghe authored
      
      
      All existing stage planers(PlanStageGreedy, PlanStageProtected,
      PlanStageHiSi) silently ignore if they couldn't allocate a drmplane
      for a drmhwclayer and return success.
      
      That doesn't go well with the assumptions from ValidateDisplay,
      where if the atomic check succeeds we just assume that we could do
      Device composition for a maximum of num_of_drm_planes layers. But,
      since we silently dropped some drmhwclayer we never put those in the
      atomic check and we won't put it in the final atomic commit, so we end
      up with a wrong composition on the screen.
      
      What this proposes is propagating the error, which will make
      ValidateDisplay to fallback on client composition.
      
      Signed-off-by: default avatarAlexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
      2234d377
  18. 05 Sep, 2018 2 commits
  19. 04 Sep, 2018 1 commit
  20. 03 Sep, 2018 1 commit
  21. 31 Aug, 2018 4 commits
  22. 28 Aug, 2018 1 commit
    • John Stultz's avatar
      drm_hwcomposer: Fixup Sean's HiSi dummy planner · 60f5e32d
      John Stultz authored
      
      
      The dummy HiSi Planner is careful to not try to emplace layers
      that aren't HW_FB. However, in some cases we might have a single
      layer to draw. In that case the dummy importer will pretend it
      imported the buffer, and the planner will skip over it and not
      emplace it. Since there were no errors and the layers_ count is
      the same as the available planes, we won't force client
      composition, and will try to do device composition for the
      buffer we didn't really import.
      
      This results in the drm layer going a bit wonky.
      
      Thus, this patch tries to fix this by erroring out if we try to
      plan only a single layer, but don't emplace anything. This
      results in the CreateComposition() function failing, which will
      force client rendering, making it work (with only minimal logcat
      noise - only in the single layer case).
      
      Change-Id: I563dbba3c2adce5617fae61cb0440368053e5bff
      Signed-off-by: John Stultz's avatarJohn Stultz <john.stultz@linaro.org>
      60f5e32d
  23. 27 Aug, 2018 3 commits
    • Sean Paul's avatar
      drm_hwcomposer: Fix HiSi import fail log spam · 54589d28
      Sean Paul authored
      
      
      hikey can only display layers which do not have gralloc usage HW_FB
      (hint: that leaves just the client target layer). As such, there's no
      benefit trying to import them since it'll just fail. So if we encounter
      a layer such as this, fake the import (the release will be a noop since
      gem_handles will be 0).
      
      Also, as a belt-and-suspenders move, replace the greedy planner with one
      that only displays (usage != HW_FB) to be doubly sure that we don't try
      to display the no-op layers
      
      Change-Id: I7bf88cfb7bda1dd5f47b741709619494431558a2
      Signed-off-by: Sean Paul's avatarSean Paul <seanpaul@chromium.org>
      54589d28
    • Sean Paul's avatar
      drm_hwcomposer: Reformat using clang-format-5.0 · f72cccd7
      Sean Paul authored
      
      
      Run the new clang-format style over the codebase to make things
      compatible.
      
      Change-Id: I267d5070929aaa7965d58655da841402debdcb6c
      Signed-off-by: Sean Paul's avatarSean Paul <seanpaul@chromium.org>
      f72cccd7
    • Sean Paul's avatar
      drm_hwcomposer: Update clang-format to 5.0 · 5c23d5d5
      Sean Paul authored
      
      
      Updating clang-format to 5.0 to get a bit more control over our
      styling. Two things that will be beneficial:
      
      - Alphabeticalize headers
      - More control around line breaking, especially preferring
      
      val = SomeFunction(arg1,
                         arg2);
      
      vs:
      
      val =
          SomeFunction(arg1, arg2);
      
      It's still not perfect, but it seems greatly improved.
      
      Signed-off-by: Sean Paul's avatarSean Paul <seanpaul@chromium.org>
      5c23d5d5
  24. 13 Jul, 2018 4 commits
    • Alexandru Gheorghe's avatar
      drm_hwcomposer: add scene flattening · b6a675e6
      Alexandru Gheorghe authored
      
      
      Flattening of a scene is triggered if it doesn't change for a while.
      As of now there is a separate thread which triggers flattening if the
      scene did not change in last 60 vsyncs.
      
      There are two options for flattening a scene:
      * Serial, by using a writeback connector attached to the same crtc as
        the one driving the display. This happens only if possible_clones
        mask reports that the display encoder and writeback encoder could
        work simultaneously.
      The steps for achieving this are:
      1. Build a commit that enables writeback connector, we don't need to
         build a commit that contains the entire active_composition, just
         set the writeback specific properties a let the kernel duplicate
         the rest of the state.
      2. Commit and wait for writeback_fence to fire.
      3. Setup a composition with just one plane enabled.
      4. Apply the composition if a new one has not been applied meanwhile.
      
      * Concurrent, by comitting the scene to a new unused crtc (state !=
        DRM_MODE_CONNECTED) and getting the result back through a writeback
        connector.
      The steps for achieving this are:
      1. Copy layers from active composition.
      2. Plan layers of copy on the unused crtc. This is realized by using a
         newly created DrmDisplayCompositor object.
      3. Commit copy to the unsed crtc and get the result as a drmhwclayer.
      4. Setup a composition with just one plane enabled. Re-importing the
         buffers might be needed since we might have been using a different
         dri node.
      5. Apply the composition if a new one has not been applied while doing
         the flattening
      
      Signed-off-by: default avatarAlexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
      b6a675e6
    • Alexandru Gheorghe's avatar
      drm_hwcomposer: Fix race in ApplyFrame · db440a92
      Alexandru Gheorghe authored
      
      
      ApplyFrame holds the lock just when it swaps the value of
      active_composition_, in a multithread context we could end up in a
      situation where something is shown on the screen, but something else
      is set in active_composition_. Fix it by holding the lock during
      CommitFrame.
      
      Signed-off-by: default avatarAlexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
      db440a92
    • Alexandru Gheorghe's avatar
      drm_hwcomposer: Handle writeback connectors · b46b930e
      Alexandru Gheorghe authored
      
      
      When writeback connectors are available assign them to displays, in
      order to be able to use them for flattening of the current displayed
      scene. The pipeline for each display will look like this:
      
      CRTC ---- encoder ------------ display connector.
       |------- writeback enc ------ writeback connector.
      
      However, the writeback connector will be later used/enabled only if
      one of the following conditions are met:
       - Could be a clone of the display connector, as pointed by the
         possible_clones property.
       - The display_connector is disconnected, so we are safe to use it for
         flattening the scene that's already presented on another display.
      
      Signed-off-by: default avatarAlexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
      b46b930e
    • Alexandru Gheorghe's avatar
      drm_hwcomposer: Parse and store possible_clones information · e8b668c4
      Alexandru Gheorghe authored
      
      
      drmModeEncoder has a field called possible_clones. It's a bit mask
      which tells if the encoder could be simultaneously connected, to the
      same CRTC, with the encoders specified in the possible_clones mask.
      
      Signed-off-by: default avatarAlexandru Gheorghe <alexandru-cosmin.gheorghe@arm.com>
      e8b668c4