Skip to content
GitLab
  1. 11 Apr, 2019 1 commit
  3. 10 Apr, 2019 2 commits
  5. 30 Mar, 2019 1 commit
  7. 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
  9. 19 Mar, 2019 1 commit
  11. 18 Mar, 2019 3 commits
  13. 15 Mar, 2019 1 commit
  15. 06 Mar, 2019 3 commits
  17. 05 Mar, 2019 1 commit
  19. 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
  21. 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
  23. 30 Jan, 2019 1 commit
  25. 15 Jan, 2019 1 commit
  27. 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
  29. 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
  31. 27 Nov, 2018 1 commit
  33. 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
  35. 05 Sep, 2018 2 commits
  37. 04 Sep, 2018 1 commit
  39. 03 Sep, 2018 1 commit
  41. 31 Aug, 2018 4 commits
  43. 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
  45. 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
  47. 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