1. 19 Apr, 2021 7 commits
  2. 16 Apr, 2021 1 commit
    • Igor Kovalenko's avatar
      bluetooth: disable HSP HS profile by default · fec9eb17
      Igor Kovalenko authored
      A few headsets have issues if HFP HF profile connection is attempted before
      HSP HS profile connection is closed. Looks like this could happen because
      bluez bluetoothd alows to make simultaneous HSP HS and HFP HF peer connections.
      
      One of affected headsets is WH-1000XM2
      
      Until we find out how to prevent simultaneous HSP HS and HFP HF connections,
      when native backend has HFP HF profile enabled (this is the default) do disable
      HSP HS completely unless user explicitly request it via discovery modarg.
      
      Do this by adding module-bluetooth-discover arg enable_native_hsp_hs,
      default to inverse of enable_native_hfp_hf.
      
      Part-of: <!538>
      fec9eb17
  3. 14 Apr, 2021 1 commit
  4. 09 Apr, 2021 1 commit
  5. 05 Apr, 2021 21 commits
  6. 03 Apr, 2021 1 commit
    • Igor Kovalenko's avatar
      bluetooth: prioritize native backend HFP HF connection · 1f204a13
      Igor Kovalenko authored
      Bluez prepends newly registered profile to a list of supported profiles,
      and new peer profile connections are attempted in reverse order of profile
      registration.
      
      Currently native backend would register HFP AG profile before HSP AG profile.
      When peer supports both HFP HF and HSP HS profiles, this registration order
      causes extra HSP HS connection attempt before native backend would reject it
      to make sure peer is reconnected with HFP HF profile.
      
      Reorder HSP AG profile registration before HFP AG to make sure peer supporting
      both profiles connects with HFP HF profile first.
      
      Part-of: <!534>
      1f204a13
  7. 27 Mar, 2021 5 commits
  8. 26 Mar, 2021 1 commit
    • Marijn Suijten's avatar
      bluetooth: Only use hardware volume callbacks for peer attenuation · 02027518
      Marijn Suijten authored
      Setting these callbacks adds the HW_{VOLUME,MUTE}_CTRL flag even when
      PulseAudio is solely responsible for performing attenuation whilst only
      keeping the peer posted on changes.  For this case the hardware callback
      is not registered at all but instead a hook is attached to catch
      PA_CORE_HOOK_{SINK,SOURCE}_VOLUME_CHANGED.  Only when the peer performs
      attenuation (the peer is in HeadSet/HandsFree role) are the callbacks
      used, without touching PA software volume at all.  A future change could
      potentially use software volume to compensate for the extremely coarse
      16 steps of volume control in HSP and HFP, and to allow volume over
      100%.
      
      Part-of: <!519>
      02027518
  9. 25 Mar, 2021 1 commit
  10. 23 Mar, 2021 1 commit