1. 03 Oct, 2019 1 commit
  2. 11 Jul, 2019 2 commits
  3. 21 Jun, 2019 1 commit
    • Neil Armstrong's avatar
      drm_hwcomposer: pre-filter modes provided to HWC2 · b67d049c
      Neil Armstrong authored
      Currently LocalDisplayAdapter in AOSP filters out similar modes based
      on their currently limited supported attributes: width/height/refresh.
      This leads to a situation where important modes are discarded, like the
      preferred mode and/or the active mode, leading SurfaceFlinger to select
      an unwanted and potentially invalid  mode in the list provided by
      drm-hwcomposer to HWC2.
      Let's pre-filter the modes provided to HWC2 by :
      - systematically adding the preferred mode
      - systematically adding the current active mode, if different
        from preferred mode
      - keeping the interlaced modes filtering-out if no other non-interlace
        modes with same widthXheight exists (for HD-Ready 1080i TVs or CVBS)
      - discarding modes if a similar mode with same widthXheight@refresh was
        already selected for HWC2
      This mimics the behavior of LocalDisplayAdapter filtering algorithm,
      but keeps the important modes from the DRM Point Of View and drops the
      duplicate modes while keeping the mode ordering from DRM in account.
      This local filtering should ultimately go out when HWC2 can actually
      handle mode Attributes to describe Preferred mode, Interlaced, 3D...
      and LocalDisplayAdapter uses these Attributes for filtering duplicate
      Signed-off-by: Neil Armstrong's avatarNeil Armstrong <narmstrong@baylibre.com>
      Tested-by: John Stultz's avatarJohn Stultz <john.stultz@linaro.org>
  4. 11 Jun, 2019 3 commits
  5. 07 Jun, 2019 1 commit
  6. 04 Jun, 2019 1 commit
  7. 11 Apr, 2019 1 commit
  8. 10 Apr, 2019 2 commits
  9. 30 Mar, 2019 1 commit
  10. 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>
  11. 19 Mar, 2019 1 commit
  12. 18 Mar, 2019 3 commits
  13. 15 Mar, 2019 1 commit
  14. 06 Mar, 2019 3 commits
  15. 05 Mar, 2019 1 commit
  16. 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
      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
    • 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>
  17. 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
  18. 30 Jan, 2019 1 commit
  19. 15 Jan, 2019 1 commit
  20. 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>
  21. 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
      Signed-off-by: default avatarAlexey Firago <alexey_firago@mentor.com>
  22. 27 Nov, 2018 1 commit
  23. 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>
    • 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>
  24. 05 Sep, 2018 2 commits
  25. 04 Sep, 2018 1 commit
  26. 03 Sep, 2018 1 commit
  27. 31 Aug, 2018 3 commits