Hi Luiz,
On 2020-10-14 10:15 a.m., Luiz Augusto von Dentz wrote:
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?
Had a look into this, but since the state callback is being registered
during profile-probe, we're not guaranteed that the other services will
have been created yet, so we won't be able to specify which service we
want to subscribe to.
I've removed the AVDTP/AVCTP state callback hook anyway, and switched
over to the existing service-state cb; after moving things around the
overhead turned out to be pretty low, so I'll get it all tidied up and
submit a patch in a couple of days (pending any further feedback).
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
