Hi Peter, On Tue, Oct 13, 2020 at 10:06 PM Peter Mullen <omaolaip@xxxxxx> 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@xxxxxx> 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
