Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <333e38b3-da26-e3c6-76fb-1ee1caf90299@tcd.ie>
In-Reply-To: <333e38b3-da26-e3c6-76fb-1ee1caf90299@tcd.ie>
From:   Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date:   Mon, 12 Oct 2020 09:43:39 -0700
Message-ID: <CABBYNZLFV6THotUuzATG0YJFgDh9cFoU575QqLD+Q2+EHoiPTA@mail.gmail.com>
Subject: Re: Bose QC 35 Battery/ANC Support
To:     Peter Mullen <omaolaip@tcd.ie>
Cc:     "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Peter,

On Sun, Oct 11, 2020 at 1:04 PM Peter Mullen <omaolaip@tcd.ie> wrote:
>
> Hi all,
>
> I've been working on a plugin that adds support for battery level
> reporting and Active Noise Cancelling (ANC) control for the Bose QC 35
> headphones. The patch is nearly ready to go, but because of the
> non-standard way it's implemented I figured it might be necessary to get
> some preliminary feedback on it prior to submission (or to see if it's
> worth submitting).
>
> As a brief overview of device control, the QC35 has a set of additional
> controls operating over rfcomm channel 8 where messages are passed back
> and forth between devices. The messages consist of a 3-byte opcode, a
> 1-byte payload length, and N-bytes of payload. There's some more
> information on the specifics here:
> https://blog.davidventura.com.ar/reverse-engineering-the-bose-qc35-bluetooth-protocol.html
>
> As this is a non-standard "profile", there's no profile UUID assigned to
> it which makes adding a profile somewhat more complicated. My solution
> here was to add a profile under the iPod Accessory Protocol (iAP)
> profile UUID which the QC35 lists, and to then filter out devices in the
> profile probe callback based on manufacturer ID, device class, and
> product ID. This isn't ideal as the probe will be called for any device
> listing the iAP UUID, so suggestions for alternative approaches (if
> necessary) are appreciated.

We could in possibly add pid/vid to btd_profile that way it can be
probed by pid/vid in addition to UUID, that way one can make a driver
that is specific to a vendor or a product.

> For session state control, I've hooked into the AVDTP state-change
> callback. Again, possibly non-standard but this seemed to be the best
> way to trigger the initiatiation/tearing down of the rfcomm connection.

I would recommend hooking to the btd_service state, like for example
the policy plugin is doing.

> For battery level integration, I've basically just wrapped the dbus
> interface from the standard GATT battery profile. This has been working
> fine with my DE; the battery level shows immediately after connection
> and updates as the level drops.

We had some discussion on weather we should continue using a custom
D-Bus interface or just emulate the battery reports over UHID given
that is probably better integrated with the system.

> For ANC integration, I've added a new dbus interface under
> "org.bluez.Anc1". The interface contains a read-only "Range" property,
> which indicates the number of discrete values the ANC can be set to, and
> a read-write property "Level" which gets/sets the level. This interface
> layout was chosen to be device agnostic, so that ANC support could
> potentially be added for more devices in future.

I'd probably add Bose to the name of the interface if it is bose specific.

> Let me know if there are any thoughts on this; I can get the patch ready
> and submitted if desired.
>
> Kind regards,
> Peter
>


-- 
Luiz Augusto von Dentz