This project is mirrored from https://github.com/Professor-Berni/android_device_sony_kitakami-common.git. Pull mirroring updated .
  1. 11 Jul, 2021 1 commit
  2. 15 May, 2021 3 commits
  3. 30 Apr, 2021 1 commit
  4. 23 Apr, 2021 1 commit
  5. 17 Apr, 2021 1 commit
  6. 20 Jan, 2021 1 commit
  7. 14 Jan, 2021 1 commit
  8. 02 Jan, 2021 5 commits
  9. 15 Dec, 2020 2 commits
  10. 14 Dec, 2020 1 commit
  11. 12 Dec, 2020 3 commits
  12. 11 Dec, 2020 1 commit
  13. 05 Dec, 2020 2 commits
  14. 21 Nov, 2020 1 commit
  15. 13 Nov, 2020 1 commit
  16. 12 Nov, 2020 2 commits
  17. 05 Nov, 2020 1 commit
  18. 04 Nov, 2020 4 commits
    • Bernhard Thoben's avatar
      Changed output directory of aanc_tuning_mixer.txt · 5977b0f8
      Bernhard Thoben authored
      The file aanc_tuning_mixer.txt has to be in /system/etc because:
      E MCS-RT-CTL: Can't open the configuration file /system/etc/aanc_tuning_mixer.txt.
      
      Change-Id: Ie8a28b4486aeebbc76facca1bc7a593b33229583
      5977b0f8
    • Bernhard Thoben's avatar
      Rename audio_tuning_mixer.txt to aanc_tuning_mixer.txt · d1de4207
      Bernhard Thoben authored
      logcat: E MCS-RT-CTL: Can't open the configuration file /system/etc/aanc_tuning_mixer.txt.
      Change-Id: If41179d70cf9dfbc5c2ad43011927aaabc391a6e
      d1de4207
    • Bruno Martins's avatar
      kitakami-common: Restore audio tuning mixer control · 96fafc01
      Bruno Martins authored
       * After all, this still seems to be needed for ACDB MCS init,
         as seen bellow. Just let ACDB loader be happy.
      
         Without the tuning mixer file:
           E ACDB-MCS: acdb_mcs_init: /vendor/etc/audio_tuning_mixer_tasha.txt not present, using /vendor/etc/audio_tuning_mixer.txt config file
           E MCS-RT-CTL: Can't open the configuration file /vendor/etc/audio_tuning_mixer.txt.
           E ACDB-MCS: acdb_mcs_init: MCS routing control initialization failed.
      
         With the tuning mixer file:
           E ACDB-MCS: acdb_mcs_init: /vendor/etc/audio_tuning_mixer_tasha.txt not present, using /vendor/etc/audio_tuning_mixer.txt config file
           D         : [ACPH]->MCS RTC service registered with ACPH
      
      Change-Id: I6e4b1fe27547a354eaa4132aba8e3df04d6184b3
      96fafc01
    • mosimchah's avatar
      kitakami-common: Convert audio_effects.conf to audio_effects.xml · 9b666683
      mosimchah authored
      * https://github.com/luk1337/aeffects-conf2xml
      
      Fixes:
      09-04 19:18:03.152   689   689 E EffectsConfig: Failed to parse /vendor/etc/audio_effects.xml: Tinyxml2 error (3): /vendor/etc/audio_effects.xml (null)
      
      09-04 19:18:03.152   689   689 W AudioPolicyEffects: Failed to load XML effect configuration, fallback to .conf
      
      Change-Id: Ibd985bea0441c7d5cffd37e0b3f65d5c27a16891
      9b666683
  19. 29 Oct, 2020 2 commits
  20. 27 Oct, 2020 5 commits
  21. 27 Sep, 2020 1 commit
    • Benoît Laniel's avatar
      kitakami-common: camera: defer start_preview until surface is valid · 6c0586ea
      Benoît Laniel authored
      Some apps like Snap start preview very early to setup camera while initializing
      UI. It then calls setPreviewDisplay (set_preview_window) to define the surface
      used for preview.
      
      According to https://developer.android.com/reference/android/hardware/Camera.html#setPreviewDisplay%28android.view.SurfaceHolder%29
      "This allows camera setup and surface creation to happen in parallel, saving time."
      
      But https://developer.android.com/reference/android/hardware/Camera.html#startPreview%28%29
      "Preview will not actually start until a surface is supplied with setPreviewDisplay(SurfaceHolder) or setPreviewTexture(SurfaceTexture)."
      
      However, hero camera hal starts preview with an internal buffer when surface
      is not valid / null.
      
      [CAM_ID(0)][]-WARN(setPreviewWindow[204]):Preview window is NULL, create internal buffer for preview
      [CAM_ID(0)][]-INFO(startPreview[519]):setBuffersThread is run
      
      On the next set_preview_window call (the one defining the surface), camera hal
      restarts preview since it is already running using the internal buffer.
      
      [CAM_ID(0)][]-WRN(setPreviewWindow[187]):Preview is started, we forcely re-start preview
      
      Problem with this is that it deadlocks quite often. It loops here
      
      [CAM_ID(0)][]-INFO(m_mainThreadQSetup3AA[1078]):m_flagThreadStop(1)
      
      Let's handle the situation in the wrapper so no restart is done by the hal.
      
      Change-Id: I762af781e5af96b52407387aa9ae67874a8ab8b6
      6c0586ea