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> <CABBYNZLFV6THotUuzATG0YJFgDh9cFoU575QqLD+Q2+EHoiPTA@mail.gmail.com>
 <6030b6bc-73f1-6fbd-e5c5-58e2ce4a5d26@tcd.ie>
In-Reply-To: <6030b6bc-73f1-6fbd-e5c5-58e2ce4a5d26@tcd.ie>
From:   Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date:   Wed, 14 Oct 2020 10:15:26 -0700
Message-ID: <CABBYNZLMciCQP_f+e7EM1v=9eS3BAnP17gxYBUNCVE4KxO_8-Q@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 Tue, Oct 13, 2020 at 10:06 PM Peter Mullen <omaolaip@tcd.ie> wrote:
>
> Hi Luiz,
>
> On 2020-10-12 9:43 a.m., Luiz Augusto von Dentz wrote:
> > 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.
> Had a go at that this evening as a proof-of-concept; so far it's working
> well, so this could be viable. I'll finish it off and test it out properly.
>
> >> 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.
> I was able to get the plugin working based on the btd_service state cb,
> but had a couple of concerns with it, mainly because we'll be receiving
> events for all services on all devices, so the filtering of unused
> events adds a bit of overhead.
> I was also able to use the AVCTP state callback without issue, which may
> be better suited than the AVDTP one.

I guess we could add support for subscribing to state changes of a
specific service, that way you don't need to filter anything at the
plugin, how about that?

> >> 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.
> While the plugin is Bose specific, I had tried to keep the interface
> itself generic so that integration with the DE or similar won't need any
> changes if ANC support is added for other devices later.
>
> --
> Peter Mullen


-- 
Luiz Augusto von Dentz