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;
To:     linux-bluetooth@vger.kernel.org
From:   Peter Mullen <omaolaip@tcd.ie>
Subject: Bose QC 35 Battery/ANC Support
Message-ID: <333e38b3-da26-e3c6-76fb-1ee1caf90299@tcd.ie>
Date:   Sat, 10 Oct 2020 22:00:38 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.12.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Precedence: bulk

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.

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.

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.

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.

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

Kind regards,
Peter