1. 06 Dec, 2019 1 commit
    • maurossi's avatar
      drm_hwcomposer: set primary display only if connected (v4) · ad493d60
      maurossi authored
      Android-x86 supports one display which has to be connected, so when looking for
      primary disaply we add check for condition 'conn->state() == DRM_MODE_CONNECTED'
      we set found_primary flag only for connected display and skip the treatment of
      additional displays.
      (v2) Same logic but Changes in implementation due to following commits:
           0f5abd79 ("drm_hwcomposer: Rename DrmResources to DrmDevice")
           c5463587 ("drm_hwcomposer: Add resource manager support")
      (v3) Due to commit 27cd4805 ("drm_hwcomposer: Organize files into subdirs")
      (v4) Due to commit d07c3705
       ("drm_hwcomposer: Add property hwc.drm.primary_display_order")
      This is essential to avoid following logcat errors on integrated and dedicated GPUs:
      ... 2245  2245 E hwc-drm-device: Could not find a suitable encoder/crtc for display 3
      ... 2245  2245 E hwc-drm-device: Failed CreateDisplayPipe 90 with -19
      Tested with i965 on Skylake GT2, amdgpu on HD7790, RX560 and nouveau on GT610, GT1030
      Signed-off-by: maurossi's avatarMauro Rossi <issor.oruam@gmail.com>
  2. 04 Dec, 2019 1 commit
    • Roman Stratiienko's avatar
      drm_hwcomposer: Introduce dumpsys metrics · 0d1a2cdb
      Roman Stratiienko authored
      To make optimal performance/power consumption ratio we want to use composing by
      dedicated hardware to merge as much as possible composition cases.
      We are going to continuously optimize and improve drm_hwcomposer HAL, that
      makes high demand on formal validation process.
      Introduce "pixel operation" definition. It should be in direct ratio with power
      consumption, but currently it roughly calculated as sum of pixels merged by
      each layer.
      In some future we should apply some average gains depending of operation type
      to calculate pixops more precisely. (e.g. scaling should take more pixops than
      blending, and blending should take more that copying, etc.).
      Using pixops could be very helpful when drm_hwc HAL have a choice which layer
      sets to merge by GPU, making possible minimal energy model based planning.
      Create statistics of the following events:
      1. Total frames count
      2. Total pixel operations
      3. Pixel operations validated to use GPU (CLIENT)
      4. Calculate composer efficiency: DEVICE/TOTAL operations ratio
      5. Failed atomic validation commits count
      6. Failed atomic presenting commits count
       - $ adb shell dumpsys SurfaceFlinger
      Statistics will be shown at the end of the dump in 2 forms:
      1. Since system launched
      2. Since last dumpsys command called
      Using statistics for the regression slope monitoring example:
      1. Boot the board without the change
      2. Use touch or keyboard (avoid using of mouse pointer) to do some predefined
      actions (open application, start video, etc.)
      3. Save the metrics
      4. Boot the board with the change
      5. Do exactly the same actions as in (2)
      6. Save the metrics
      7. Use metrics before and after change to indicate regression slope
      Signed-off-by: default avatarRoman Stratiienko <roman.stratiienko@globallogic.com>
  3. 03 Dec, 2019 1 commit
    • Matteo Franchin's avatar
      drm_hwcomposer: Fix returned fence in PresentDisplay · c56eede3
      Matteo Franchin authored and John Stultz's avatar John Stultz committed
      DrmHwcTwo::HwcDisplay::PresentDisplay was always returning -1 as the
      present fence. This commits ensures the fence fd is correctly retrieved
      after doing the commit-frame operation. It also updates outdated logic
      that caused PresentDisplay to return the retire fence rather than the
      present fence.
      DrmHwcTwo::HwcDisplay::AddFenceToPresentFence is also changed so that
      it assumes it is given ownership of the file descriptor it receives as
      argument. This function was indeed called consistently with this
      behaviour, which meant the dup led to leakage of file descriptors.
      With the changes above this patch fixes a failure in the CTS test
      dEQP-VK.wsi.android.display_timing.fifo.display_timing (for example
      running Android 10 on HiKey960). The test failed with the error
      "Unexpectedly received invalid timestamp." reported multiple times in
      the logcat output.
      Change-Id: If662e5239895b8b0e2ea31fd99747855f901a427
      Signed-off-by: Matteo Franchin's avatarMatteo Franchin <matteo.franchin@arm.com>
  4. 28 Nov, 2019 2 commits
  5. 27 Nov, 2019 1 commit
  6. 21 Nov, 2019 3 commits
  7. 20 Nov, 2019 1 commit
    • Roman Stratiienko's avatar
      drm_hwcomposer: Fix mixed layer composition · f2647231
      Roman Stratiienko authored
      Fix cases when mixed layer composition require non-device layer in the middle:
      Layer z_order - SF type    - validated type before - validated type fixed
                  0 - DEVICE     - CLIENT                - CLIENT
                  1 - DEVICE     - DEVICE                - CLIENT
                  2 - DEVICE     - DEVICE                - CLIENT
                  3 - SOLIDCOLOR - CLIENT                - CLIENT
                  4 - DEVICE     - DEVICE                - DEVICE
      In such composition SF will merge layers 0 and 3 and hwcomposer will
      merge <SF>,1,2,4 that results incorrect merging order.
      Issue was observed on the rcar3 (imagination importer), db845c and allwinner H3
      (Generic importer) platforms.
      Reproduces with compositions that requires 'cursor' or 'dim' layers.
      How to reproduce:
       1. Connect USB mouse when on home screen, you should see mouse cursor
          under icons (Tested with Launcher3QuickStep desktop)
       2. Go to Settings -> WIFI -> Connect to the AP, then you should see
          password dialog under AP list.
      1. Mark intermediate layers as CLIENT to ensure CLIENT section is in range
      from bottom layer to most top CLIENT layer.
      2. Use this layer composition to validate if DRM can handle it.
      Signed-off-by: default avatarRoman Stratiienko <roman.stratiienko@globallogic.com>
  8. 11 Nov, 2019 1 commit
    • Roman Stratiienko's avatar
      drm_hwcomposer: Add Imagination platform support · e3ed48d7
      Roman Stratiienko authored
      External Android.bp file should be created in order to build this module:
      cc_library_shared {
          name: "hwcomposer.drm_imagination",
          defaults: ["hwcomposer.drm_defaults"],
          srcs: [":drm_hwcomposer_platformimagination"],
          whole_static_libs: ["drm_hwcomposer"],
          shared_libs: ["libion"],
          include_dirs: [
      libion is needed to make ion.h header visible `linux/ion.h`.
      Signed-off-by: default avatarRoman Stratiienko <roman.stratiienko@globallogic.com>
  9. 06 Nov, 2019 1 commit
  10. 22 Oct, 2019 4 commits
  11. 10 Oct, 2019 1 commit
  12. 11 Jul, 2019 2 commits
  13. 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>
  14. 11 Jun, 2019 3 commits
  15. 07 Jun, 2019 1 commit
  16. 04 Jun, 2019 1 commit
  17. 11 Apr, 2019 1 commit
  18. 10 Apr, 2019 2 commits
  19. 30 Mar, 2019 1 commit
  20. 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>
  21. 19 Mar, 2019 1 commit
  22. 18 Mar, 2019 3 commits
  23. 15 Mar, 2019 1 commit
  24. 06 Mar, 2019 3 commits
  25. 05 Mar, 2019 1 commit
  26. 28 Feb, 2019 1 commit
    • 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