Skip to content
GitLab
  1. 03 Oct, 2019 1 commit
  3. 11 Jul, 2019 2 commits
  5. 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
modes.

Signed-off-by: Neil Armstrong's avatarNeil Armstrong <narmstrong@baylibre.com>
Tested-by: John Stultz's avatarJohn Stultz <john.stultz@linaro.org>
      b67d049c
  7. 11 Jun, 2019 3 commits
  9. 07 Jun, 2019 1 commit
  11. 04 Jun, 2019 1 commit
  13. 11 Apr, 2019 1 commit
  15. 10 Apr, 2019 2 commits
  17. 30 Mar, 2019 1 commit
  19. 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
  21. 19 Mar, 2019 1 commit
  23. 18 Mar, 2019 3 commits
  25. 15 Mar, 2019 1 commit
  27. 06 Mar, 2019 3 commits
  29. 05 Mar, 2019 1 commit
  31. 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
  33. 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
  35. 30 Jan, 2019 1 commit
  37. 15 Jan, 2019 1 commit
  39. 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
  41. 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
  43. 27 Nov, 2018 1 commit
  45. 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
  47. 05 Sep, 2018 2 commits
  49. 04 Sep, 2018 1 commit
  51. 03 Sep, 2018 1 commit
  53. 31 Aug, 2018 3 commits