public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: "Frédéric Danis" <frederic.danis.oss@gmail.com>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: [PATCH BlueZ v2 9/9] doc/btmon: Add HFP protocol flow documentation
Date: Thu, 26 Mar 2026 12:28:55 +0100	[thread overview]
Message-ID: <4e0b18ce-7ec4-45ee-8bfc-c220fc6eee61@gmail.com> (raw)
In-Reply-To: <20260324194946.109349-9-luiz.dentz@gmail.com>

Hi Luiz,

On 24/03/2026 20:49, Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
>
> Add btmon-hfp.rst documenting the HFP protocol flow as seen in btmon
> output. Coverage includes:
>
>   - SDP service discovery for Handsfree/AG UUIDs
>   - RFCOMM channel setup over L2CAP PSM 3 (SABM/UA, Parameter
>     Negotiation, Modem Status Command)
>   - AT command exchange for SLC setup (noted as hex dump only -- btmon
>     does not parse AT commands within RFCOMM UIH data frames)
>   - Codec negotiation via AT+BAC/AT+BCS
>   - SCO/eSCO synchronous connection setup (voice setting, coding format)
>   - Codec summary tables (AT-level vs HCI-level codec IDs)
>   - Automation-friendly grep patterns
> ---
>   doc/btmon-classic-audio.rst |   2 +
>   doc/btmon-hfp.rst           | 476 ++++++++++++++++++++++++++++++++++++
>   2 files changed, 478 insertions(+)
>   create mode 100644 doc/btmon-hfp.rst
>
> diff --git a/doc/btmon-classic-audio.rst b/doc/btmon-classic-audio.rst
> index 11943c3a54bf..3e7c5384be87 100644
> --- a/doc/btmon-classic-audio.rst
> +++ b/doc/btmon-classic-audio.rst
> @@ -10,3 +10,5 @@ A2DP uses L2CAP-based AVDTP media channels while HFP uses SCO/eSCO
>   synchronous connections.
>   
>   .. include:: btmon-a2dp.rst
> +
> +.. include:: btmon-hfp.rst
> diff --git a/doc/btmon-hfp.rst b/doc/btmon-hfp.rst
> new file mode 100644
> index 000000000000..c81c0df3feb3
> --- /dev/null
> +++ b/doc/btmon-hfp.rst
> @@ -0,0 +1,476 @@
> +.. This file is included by btmon-classic-audio.rst.
> +
> +HFP: Hands-Free Profile
> +-------------------------
> +
> +HFP carries voice audio over SCO/eSCO connections with call control
> +over RFCOMM. btmon decodes RFCOMM framing and SCO/eSCO connection
> +setup. AT commands (the HFP control protocol) appear as raw hex dumps
> +within RFCOMM data frames -- btmon does not parse AT command syntax.
> +
> +SDP Discovery
> +~~~~~~~~~~~~~~
> +
> +HFP uses SDP to discover the remote device's Hands-Free or Audio
> +Gateway service record and its RFCOMM channel number::
> +
> +    < ACL Data TX: Handle 1 flags 0x00 dlen 25
> +          Channel: 64 len 21 [PSM 1 mode Basic (0x00)] {chan 0}
> +            SDP: Service Search Attribute Request (0x06) tid 1 len 16
> +              Search pattern: [len 5]
> +                Sequence (6) with 3 byte(s) [8 extra bits] len 5
> +                  UUID (3) with 2 byte(s) [0 extra bits] len 3
> +                    Handsfree Audio Gateway (0x111f)
> +              Max record count: 65535
> +              Attribute list: [len 5]
> +                Sequence (6) with 3 byte(s) [8 extra bits] len 5
> +                  Unsigned Integer (1) with 4 byte(s) [0 extra bits] len 5
> +                    0x0000ffff
> +              Continuation state: 0
> +
> +The response contains the service record with the RFCOMM channel::
> +
> +    > ACL Data RX: Handle 1 flags 0x02 dlen 89
> +          Channel: 64 len 85 [PSM 1 mode Basic (0x00)] {chan 0}
> +            SDP: Service Search Attribute Response (0x07) tid 1 len 80
> +              Attribute bytes: 77
> +                Attribute list: [len 75] {position 0}
> +                  Attribute: Service Class ID List (0x0001) [len 2]
> +                    Handsfree Audio Gateway (0x111f)
> +                  Attribute: Protocol Descriptor List (0x0004) [len 2]
> +                    L2CAP (0x0100)
> +                    RFCOMM (0x0003)
> +                      Channel: 1
> +                  Attribute: Bluetooth Profile Descriptor List (0x0009) [len 2]
> +                    Handsfree (0x111e)
> +                      Version: 0x0108
> +              Continuation state: 0
> +
> +Key fields to extract:
> +
> +- **Service Class** -- ``Handsfree (0x111e)`` for HF role,
> +  ``Handsfree Audio Gateway (0x111f)`` for AG role
> +- **RFCOMM Channel** -- The channel number under ``RFCOMM (0x0003)``
> +  in the Protocol Descriptor List (e.g., channel 1)
> +- **Profile Version** -- Under the Bluetooth Profile Descriptor List
> +  (e.g., ``0x0108`` = HFP 1.8, ``0x0109`` = HFP 1.9)
> +
> +RFCOMM Connection Setup
> +~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +RFCOMM runs over L2CAP PSM 3. The connection proceeds in stages:
> +multiplexer session on DLCI 0, parameter negotiation, then the data
> +channel on the target DLCI.
> +
> +**L2CAP connection for RFCOMM**::
> +
> +    < ACL Data TX: Handle 1 flags 0x00 dlen 12
> +          L2CAP: Connection Request (0x02) ident 2 len 4
> +            PSM: 3 (0x0003)
> +            Source CID: 65
> +
> +    > ACL Data RX: Handle 1 flags 0x02 dlen 16
> +          L2CAP: Connection Response (0x03) ident 2 len 8
> +            Destination CID: 65
> +            Source CID: 65
> +            Result: Connection successful (0x0000)
> +            Status: No further information available (0x0000)
> +
> +**SABM/UA on DLCI 0** (multiplexer session)::
> +
> +    < ACL Data TX: Handle 1 flags 0x00 dlen 12
> +          Channel: 65 len 4 [PSM 3 mode Basic (0x00)] {chan 1}
> +            RFCOMM: Set Async Balance Mode (SABM) (0x2f)
> +             Address: 0x03 cr 1 dlci 0x00
> +             Control: 0x3f poll/final 1
> +             Length: 0
> +             FCS: 0x1c
> +
> +    > ACL Data RX: Handle 1 flags 0x02 dlen 12
> +          Channel: 65 len 4 [PSM 3 mode Basic (0x00)] {chan 1}
> +            RFCOMM: Unnumbered Ack (UA) (0x63)
> +             Address: 0x03 cr 1 dlci 0x00
> +             Control: 0x73 poll/final 1
> +             Length: 0
> +             FCS: 0xd7
> +
> +**Parameter Negotiation** (MCC on DLCI 0)::
> +
> +    Channel: 65 len 14 [PSM 3 mode Basic (0x00)] {chan 1}
> +      RFCOMM: Unnumbered Info with Header Check (UIH) (0xef)
> +       Address: 0x03 cr 1 dlci 0x00
> +       Control: 0xef poll/final 0
> +       Length: 10
> +       FCS: 0x70
> +       MCC Message type: DLC Parameter Negotiation CMD (0x20)
> +         Length: 8
> +         dlci 2 frame_type 0 credit_flow 15 pri 7
> +         ack_timer 0 frame_size 127 max_retrans 0 credits 7
> +
> +The DLCI in the PN command identifies the target channel. For RFCOMM
> +channel N, DLCI = N * 2 (or N * 2 + 1 depending on the initiator
> +role).
> +
> +**SABM/UA on target DLCI** (data channel)::
> +
> +    Channel: 65 len 4 [PSM 3 mode Basic (0x00)] {chan 1}
> +      RFCOMM: Set Async Balance Mode (SABM) (0x2f)
> +       Address: 0x0b cr 1 dlci 0x02
> +       Control: 0x3f poll/final 1
> +       Length: 0
> +       FCS: 0x59
> +
> +    Channel: 65 len 4 [PSM 3 mode Basic (0x00)] {chan 1}
> +      RFCOMM: Unnumbered Ack (UA) (0x63)
> +       Address: 0x0b cr 1 dlci 0x02
> +       Control: 0x73 poll/final 1
> +       Length: 0
> +       FCS: 0x92
> +
> +**Modem Status Command** (signals readiness)::
> +
> +    Channel: 65 len 8 [PSM 3 mode Basic (0x00)] {chan 1}
> +      RFCOMM: Unnumbered Info with Header Check (UIH) (0xef)
> +       Address: 0x03 cr 1 dlci 0x00
> +       Control: 0xef poll/final 0
> +       Length: 4
> +       FCS: 0x70
> +       MCC Message type: Modem Status Command CMD (0x38)
> +         Length: 2
> +         dlci 2
> +         fc 0 rtc 1 rtr 1 ic 0 dv 1
> +
> +AT Command Exchange (SLC Setup)
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +HFP uses AT commands over RFCOMM for call control and feature
> +negotiation. btmon shows these as RFCOMM UIH frames with the AT
> +command text visible in the hex dump.
> +
> +**AT command in RFCOMM UIH frame**::
> +
> +    Channel: 65 len 21 [PSM 3 mode Basic (0x00)] {chan 1}
> +      RFCOMM: Unnumbered Info with Header Check (UIH) (0xef)
> +       Address: 0x09 cr 0 dlci 0x02
> +       Control: 0xff poll/final 1
> +       Length: 14
> +       FCS: 0x86
> +       Credits: 1
> +        41 54 2b 42 52 53 46 3d 32 30 35 35 0d         AT+BRSF=2055.
> +
> +The AT command text is readable in the ASCII column of the hex dump
> +(right side). The Service Level Connection (SLC) setup sequence
> +exchanges device features and capabilities:
> +
> +1. ``AT+BRSF=<features>`` / ``+BRSF:<features>`` -- Supported
> +   features bitmask exchange
> +2. ``AT+BAC=1,2`` -- Available codecs (if codec negotiation supported).
> +   Codec IDs: 1 = CVSD, 2 = mSBC, 3 = LC3-SWB
> +3. ``AT+CIND=?`` / ``+CIND:(...)`` -- Indicator mapping query
> +4. ``AT+CIND?`` / ``+CIND:values`` -- Current indicator values
> +5. ``AT+CMER=3,0,0,1`` -- Enable indicator status reporting
> +6. ``AT+CHLD=?`` / ``+CHLD:(0,1,2,3,4)`` -- Three-way calling support

You may add here the optional commands for the HF Indicator feature, i.e.

7. ``AT+BIND=<HF supported HF indicators>``  -- Supported HF indicators 
by HF (if HF indicators are supported)
8. ``AT+BIND=?`` / ``+BIND:(...)`` -- Supported HF indicators by AG (if 
HF indicators are supported)
9. ``AT+BIND?`` /  ``+BIND:anum,state``-- Enable HF indicator status 
reporting (if HF indicators are supported)

> +
> +Key HFP feature bits (from ``AT+BRSF``):
> +
> +.. list-table::
> +   :header-rows: 1
> +   :widths: 10 25 25
> +
> +   * - Bit
> +     - HF Feature
> +     - AG Feature
> +   * - 0
> +     - EC/NR
> +     - Three-way calling
> +   * - 1
> +     - Three-way calling
> +     - EC/NR
> +   * - 2
> +     - CLI presentation
> +     - Voice recognition
> +   * - 3
> +     - Voice recognition
> +     - In-band ring tone
> +   * - 4
> +     - Remote volume
> +     - Voice tag
> +   * - 5
> +     - Enhanced call status
> +     - Reject call
> +   * - 6
> +     - Enhanced call control
> +     - Enhanced call status
> +   * - 7
> +     - Codec negotiation
> +     - Enhanced call control
> +   * - 8
> +     - HF indicators
> +     - Extended error codes
> +   * - 9
> +     - eSCO S4 (T2)
> +     - Codec negotiation
> +   * - 11
> +     -
> +     - eSCO S4 (T2)
> +
> +Codec Connection Setup
> +~~~~~~~~~~~~~~~~~~~~~~~
> +
> +When both sides support codec negotiation (feature bit 7 on HF, bit 9
> +on AG), the AG selects a codec before establishing the audio link.
> +This appears as AT commands in RFCOMM UIH frames::
> +
> +    AG -> HF:  +BCS:2      (select mSBC)
> +    HF -> AG:  AT+BCS=2    (confirm mSBC)
> +    AG -> HF:  OK
> +
> +HFP codec IDs (used in ``AT+BAC`` and ``AT+BCS``):
> +
> +.. list-table::
> +   :header-rows: 1
> +   :widths: 10 20 30
> +
> +   * - ID
> +     - Codec
> +     - Description
> +   * - 1
> +     - CVSD
> +     - Narrow band (8 kHz), mandatory
> +   * - 2
> +     - mSBC
> +     - Wide band speech (16 kHz)
> +   * - 3
> +     - LC3-SWB
> +     - Super wide band (32 kHz), HFP 1.9+
> +
> +These HFP-level codec IDs differ from HCI codec IDs.
> +
> +Voice Setting
> +~~~~~~~~~~~~~~
> +
> +Before SCO/eSCO setup, the host configures the voice setting. For
> +CVSD, the air coding format is CVSD; for mSBC or LC3-SWB, it must be
> +set to Transparent Data::
> +
> +    < HCI Command: Write Voice Setting (0x0c|0x0026) plen 2
> +          Setting: 0x0063
> +            Input Coding: Linear
> +            Input Data Format: 2's complement
> +            Input Sample Size: 16-bit
> +            # of bits padding at MSB: 0
> +            Air Coding Format: Transparent Data
> +
> +For CVSD::
> +
> +    < HCI Command: Write Voice Setting (0x0c|0x0026) plen 2
> +          Setting: 0x0060
> +            Input Coding: Linear
> +            Input Data Format: 2's complement
> +            Input Sample Size: 16-bit
> +            # of bits padding at MSB: 0
> +            Air Coding Format: CVSD

This seems a bit confusing to me. Shouldn't it better with:

Before SCO/eSCO setup, the host configures the voice setting. For
CVSD, the air coding format is CVSD:

     < HCI Command: Write Voice Setting (0x0c|0x0026) plen 2
           Setting: 0x0060
             Input Coding: Linear
             Input Data Format: 2's complement
             Input Sample Size: 16-bit
             # of bits padding at MSB: 0
             Air Coding Format: CVSD

For mSBC or LC3-SWB, the air coding format must be set to
Transparent Data::

     < HCI Command: Write Voice Setting (0x0c|0x0026) plen 2
           Setting: 0x0063
             Input Coding: Linear
             Input Data Format: 2's complement
             Input Sample Size: 16-bit
             # of bits padding at MSB: 0
             Air Coding Format: Transparent Data

> +
> +SCO/eSCO Connection Setup
> +~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +After codec negotiation, the host establishes a synchronous connection
> +for voice audio.
> +
> +**Setup Synchronous Connection** (basic)::
> +
> +    < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
> +          Handle: 1
> +          Transmit bandwidth: 8000
> +          Receive bandwidth: 8000
> +          Max latency: 13
> +          Setting: 0x0063
> +            Input Coding: Linear
> +            Input Data Format: 2's complement
> +            Input Sample Size: 16-bit
> +            # of bits padding at MSB: 0
> +            Air Coding Format: Transparent Data
> +          Retransmission effort: Optimize for link quality (0x02)
> +          Packet type: 0x0008
> +            EV3 may be used
> +
> +**Enhanced Setup Synchronous Connection** (codec-aware)::
> +
> +    < HCI Command: Enhanced Setup Synchronous Connection (0x01|0x003d) plen 59
> +          Handle: 1
> +          Transmit bandwidth: 8000
> +          Receive bandwidth: 8000
> +          Transmit Coding Format:
> +            Codec: mSBC (0x05)
> +          Receive Coding Format:
> +            Codec: mSBC (0x05)
> +          Transmit Codec Frame Size: 60
> +          Receive Codec Frame Size: 60
> +          Input Coding Format:
> +            Codec: mSBC (0x05)
> +          Output Coding Format:
> +            Codec: mSBC (0x05)
> +          Input Coded Data Size: 16
> +          Output Coded Data Size: 16
> +          Input PCM Data Format: 2's complement
> +          Output PCM Data Format: 2's complement
> +          Input PCM Sample Payload MSB Position: 0
> +          Output PCM Sample Payload MSB Position: 0
> +          Input Data Path: HCI
> +          Output Data Path: HCI
> +          Input Transport Unit Size: 60
> +          Output Transport Unit Size: 60
> +          Max latency: 13
> +          Packet type: 0x0008
> +            EV3 may be used
> +          Retransmission effort: Optimize for link quality (0x02)
> +
> +HCI codec IDs displayed by btmon:
> +
> +.. list-table::
> +   :header-rows: 1
> +   :widths: 10 20 30
> +
> +   * - ID
> +     - btmon Name
> +     - Used For
> +   * - 0x02
> +     - CVSD
> +     - Narrow band voice
> +   * - 0x03
> +     - Transparent
> +     - Transparent data mode
> +   * - 0x04
> +     - Linear PCM
> +     - Uncompressed PCM input/output
> +   * - 0x05
> +     - mSBC
> +     - Wide band speech
> +   * - 0x06
> +     - LC3
> +     - Super wide band (LC3-SWB)
> +
> +**Synchronous Connection Complete** (result)::
> +
> +    > HCI Event: Synchronous Connection Complete (0x2c) plen 17
> +          Status: Success (0x00)
> +          Handle: 257
> +          Address: 11:22:33:44:55:66 (OUI 11-22-33)
> +          Link type: eSCO (0x02)
> +          Transmission interval: 0x0c
> +          Retransmission window: 0x06
> +          RX packet length: 60
> +          TX packet length: 60
> +          Air mode: Transparent (0x03)
> +
> +Key fields:
> +
> +- **Link type** -- ``SCO (0x00)`` for legacy, ``eSCO (0x02)`` for
> +  enhanced (used by mSBC and LC3-SWB)
> +- **Air mode** -- ``CVSD (0x02)`` for narrow band,
> +  ``Transparent (0x03)`` for mSBC or LC3-SWB
> +- **RX/TX packet length** -- 60 bytes typical for mSBC T2 settings
> +
> +SCO Data Packets
> +~~~~~~~~~~~~~~~~~
> +
> +After the synchronous connection is established, voice data flows as
> +SCO/eSCO data packets::
> +
> +    > BR-ESCO: Handle 257 flags 0x00 dlen 60
> +    < BR-ESCO: Handle 257 flags 0x00 dlen 60
> +
> +btmon labels packets based on the connection type established in
> +Synchronous Connection Complete:
> +
> +- ``BR-SCO`` -- Legacy SCO connection
> +- ``BR-ESCO`` -- Enhanced SCO connection (mSBC, LC3-SWB, or eSCO CVSD)
> +
> +SCO data payload is **not displayed by default**. It requires the
> +``--show-sco-data`` filter to see the hex dump of voice data.
> +
> +Codec-Specific Connection Summary
> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**CVSD (narrow band)**:
> +
> +- HFP codec ID: 1
> +- HCI codec: CVSD (0x02)
> +- Voice setting: 0x0060 (Air Coding Format: CVSD)
> +- Air mode: CVSD (0x02)
> +- Link type: SCO or eSCO
> +- Typical packet size: 48 bytes (HV3) or 60 bytes (EV3)
> +
> +**mSBC (wide band speech)**:
> +
> +- HFP codec ID: 2
> +- HCI codec: mSBC (0x05)
> +- Voice setting: 0x0063 (Air Coding Format: Transparent Data)
> +- Air mode: Transparent (0x03)
> +- Link type: eSCO
> +- Typical packet size: 60 bytes (EV3, T2 settings)
> +
> +**LC3-SWB (super wide band)**:
> +
> +- HFP codec ID: 3
> +- HCI codec: LC3 (0x06)
> +- Voice setting: 0x0063 (Air Coding Format: Transparent Data)
> +- Air mode: Transparent (0x03)
> +- Link type: eSCO
> +- Note: btmon displays ``LC3``, not ``LC3-SWB``
> +
> +Automating HFP Analysis
> +~~~~~~~~~~~~~~~~~~~~~~~~~
> +
> +**Identify HFP activity** -- look for RFCOMM on PSM 3::
> +
> +    grep -n "PSM: 3\|RFCOMM:" output.txt
> +
> +**Read AT commands** -- search hex dump ASCII for AT command patterns::
> +
> +    grep -n "AT+B\|AT+C\|+BRSF\|+CIND\|+CHLD\|+BCS" output.txt
> +
> +**Check codec negotiation** -- look for BCS (Bluetooth Codec
> +Selection)::
> +
> +    grep -n "+BCS\|AT+BAC\|AT+BCS" output.txt
> +
> +**Verify SCO/eSCO setup**::
> +
> +    grep -n "Setup Synchronous\|Enhanced Setup Synchronous\|Synchronous Connection Complete\|Write Voice Setting" output.txt
> +
> +**Check voice codec** -- confirm air mode and coding format::
> +
> +    grep -n "Air mode:\|Air Coding Format:\|Codec:" output.txt
> +
> +**Detect SCO failures** -- check Synchronous Connection Complete
> +status::
> +
> +    grep -n "Synchronous Connection Complete" output.txt
> +
> +Then examine the next line for ``Status:``. Common failures:
> +
> +- ``Connection Rejected due to Limited Resources (0x0d)`` -- controller
> +  cannot allocate bandwidth
> +- ``SCO Offset Rejected (0x2b)`` -- timing parameters rejected
> +- ``SCO Interval Rejected (0x2c)`` -- interval parameters rejected
> +
> +**Track call state** -- look for CIEV indicator updates::
> +
> +    grep -n "+CIEV\|AT+CHUP\|ATD\|ATA\|AT+CLCC\|RING" output.txt
> +
> +**Full HFP diagnosis pattern**:
> +
> +1. Find SDP query for UUID 0x111e/0x111f -- confirms HFP discovery
> +2. Find L2CAP Connection Request for PSM 3 -- RFCOMM channel setup
> +3. Find RFCOMM SABM/UA on DLCI 0 then target DLCI -- multiplexer and
> +   data channel
> +4. Find AT+BRSF in hex dumps -- feature exchange, check codec
> +   negotiation bit
> +5. Find AT+BAC in hex dumps -- available codecs reported
> +6. Find +BCS/AT+BCS in hex dumps -- codec selected for audio
> +7. Find Write Voice Setting -- verify air coding format matches codec
> +8. Find Setup Synchronous Connection or Enhanced variant -- SCO setup
> +9. Find Synchronous Connection Complete -- check Status, Link type,
> +   Air mode
> +10. Find BR-SCO or BR-ESCO packets -- voice data flowing


  reply	other threads:[~2026-03-26 11:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-24 19:49 [PATCH BlueZ v2 1/9] doc/btmon: Split Advertising and Scanning into btmon-advertising.rst Luiz Augusto von Dentz
2026-03-24 19:49 ` [PATCH BlueZ v2 2/9] doc/btmon: Split LE Audio Protocol Flow into btmon-le-audio.rst Luiz Augusto von Dentz
2026-03-24 19:49 ` [PATCH BlueZ v2 3/9] doc/btmon: Split L2CAP Channel Tracking into btmon-l2cap.rst Luiz Augusto von Dentz
2026-03-24 19:49 ` [PATCH BlueZ v2 4/9] doc/btmon: Split SMP Pairing Flow into btmon-smp.rst Luiz Augusto von Dentz
2026-03-24 19:49 ` [PATCH BlueZ v2 5/9] doc/btmon: Split GATT Database Reconstruction into btmon-gatt.rst Luiz Augusto von Dentz
2026-03-24 19:49 ` [PATCH BlueZ v2 6/9] doc/btmon: Split Connection Tracking into btmon-connections.rst Luiz Augusto von Dentz
2026-03-24 19:49 ` [PATCH BlueZ v2 7/9] doc/btmon: Add HCI initialization sequence documentation Luiz Augusto von Dentz
2026-03-24 19:49 ` [PATCH BlueZ v2 8/9] doc/btmon: Add A2DP/AVDTP protocol flow documentation Luiz Augusto von Dentz
2026-03-24 19:49 ` [PATCH BlueZ v2 9/9] doc/btmon: Add HFP " Luiz Augusto von Dentz
2026-03-26 11:28   ` Frédéric Danis [this message]
2026-03-24 20:44 ` [BlueZ,v2,1/9] doc/btmon: Split Advertising and Scanning into btmon-advertising.rst bluez.test.bot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4e0b18ce-7ec4-45ee-8bfc-c220fc6eee61@gmail.com \
    --to=frederic.danis.oss@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox