1. 06 Dec, 2021 1 commit
  2. 02 Dec, 2021 1 commit
    • Roman Stratiienko's avatar
      drm_hwcomposer: Rework display modes handling · a148f213
      Roman Stratiienko authored
      
      
      Android likes to adapt display output frequency to match window context
      frequency. Unfortunately platform code has some limitations, therefore
      hwcomposer HAL should be careful with reporting supported display modes.
      
      Known platform limitations:
      1: Framework doesn't distinguish between interlaced/progressive modes.
      2. Framework will not switch display frequency in case margin in FPS rate
         is very small (<1FPS or so). Not a big issue, but that is causing
         some CTS tests to fail.
      
      In addition to that VRR technology (or seamless mode switching) require
      hwcomposer to group modes which tells the framework that seamless mode
      configuration change is supported within a group of display modes.
      
      By this commit do the following:
      1. Group modes by the resolution:
         E.g.
      
          Group 1:
          1024x768i@60
          1024x768i@90
          1024x768@50
          1024x768@50.1
      
          Group 2:
          1920x1080@60
          1920x1080@24.3
          1920x1080i@60
          1920x1080i@120
      
      2. Disable modes in a way that each group keeps only interlaced or proressive
         modes enabled. In case KMS reported preferred mode is interlaced - prefer
         interlaced for the whole group, otherwise prefer progressive.
      
      3. Disable mode in case different mode in the same group has similar frequency
         with delta less than 1FPS.
      
      4. Report only modes which remain enabled to the framework.
      
      Test: atest CtsGraphicsTestCases
      
      Signed-off-by: default avatarRoman Stratiienko <roman.o.stratiienko@globallogic.com>
      a148f213
  3. 10 Nov, 2021 2 commits
  4. 28 Oct, 2021 2 commits
  5. 23 Oct, 2021 9 commits
  6. 22 Oct, 2021 1 commit
  7. 29 Sep, 2021 16 commits
  8. 29 Aug, 2021 3 commits
  9. 25 Aug, 2021 1 commit
  10. 24 Aug, 2021 1 commit
    • John Stultz's avatar
      drm_hwcomposer: Quiet noisy errors when planes don't support various attributes · 66763d51
      John Stultz authored
      
      
      If a plane doesn't support alpha or rotation, and IsValidForLayer()
      fails, we see lots of logcat noise to the effect of:
      08-24 04:45:42.957   453   453 E hwc-platform: Failed to emplace layer 0, dropping it
      08-24 04:45:42.957   453   453 E hwc-platform: Failed provision stage with ret -22
      08-24 04:45:42.957   453   453 E hwc-drm-display-composition: Planner failed provisioning planes ret=-22
      08-24 04:45:42.957   453   453 E hwc-drm-two: Failed to plan the composition ret=-22
      
      This noise is unneccessarily worrisome, as they don't really
      help explain why things fail, and we still fall back to client
      composing and frames are correctly composited.
      
      Thus, this patch switches the errors to verbose-level warnings,
      which match the level in IsValidForLayer() which explain what
      actually is going wrong.
      
      Change-Id: I7ed06906b8d9e02e6ec0ac50a94346e9f9c05ac6
      Signed-off-by: John Stultz's avatarJohn Stultz <john.stultz@linaro.org>
      66763d51
  11. 31 Jul, 2021 1 commit
    • John Stultz's avatar
      drm_hwcomposer: Fix sync_file fd leak from "Rework audofd" · 8adf5443
      John Stultz authored
      In commit 0fade37a ("drm_hwcomposer: Rework autofd"),
      a change to some very subtle existing code caused a resource
      leak such that after 10 minutes or so of active display
      output, we would start seeing:
      
        android.hardware.graphics.composer@2.3-service: failed to dup fence 10
      
      over and over in logcat. Moving the mouse would cause black
      frame to flicker and eventually Surfaceflinger would crash
      and restart.
      
      The problem was subtle change in the following hunk:
      @@ -1047,10 +1049,9 @@ HWC2::Error DrmHwcTwo::HwcLayer::SetLayerBlendMode(int32_t mode) {
       HWC2::Error DrmHwcTwo::HwcLayer::SetLayerBuffer(buffer_handle_t buffer,
                                                       int32_t acquire_fence) {
         supported(__func__);
      -  UniqueFd uf(acquire_fence);
      
         set_buffer(buffer);
      -  set_acquire_fence(uf.get());
      +  acquire_fence_ = UniqueFd(fcntl(acquire_fence, F_DUPFD_CLOEXEC));
         return HWC2::Error::None;
       }
      
      The core of the problem being, that the UniqueFd class calls
      close(fd_) in its descructor. So while the change using
      fcntl(...,F_DUPFD_CLOEXEC) matches what was burried in
      set_acquire_fence(), dropping the creation (and more importantly
      the destruction when it goes out of scope) of uf changes the
      logic so we don't end up calling close on the aquire_fence fd
      argument passed in.
      
      One can confirm this resource leak by doing:
        adb shell lsof | grep composer
      
      And noticing the number of sync_file fds growing over time.
      
      Thus, this patch fixes the logic, so instead of dup()'ing the
      passed in fd, (and then closing it as done before Roman's
      patch), we can just set aquire_fence_ to a new UniqueFd directly
      using the aquire_fence fd passed in.
      
      This pattern actually occured twice, so I've fixed it in both
      places.
      
      Fixes: 0fade37a
      
       ("drm_hwcomposer: Rework autofd")
      Signed-off-by: John Stultz's avatarJohn Stultz <john.stultz@linaro.org>
      Change-Id: Iff2ca1c0b6701abbdc10c6ee92edb21a4b84a841
      8adf5443
  12. 24 Jul, 2021 2 commits