Hi Hugues, I agree, that this should be handled in bluez instead of pulseaudio. I only implemented the proof of concept in pulseaudio, since it was not easily possible in bluez and easy to do in pulseaudio. I think some restructuring of bluez/pulseaudio rfcomm handling is required, but I don't plan to take care of this. -- Sebastian On Sun, Feb 11, 2018 at 02:22:46PM +0100, Hugues wrote: > Hello, > Sebastian code works great! > But how can I proceed so the remaining battery is exposed over upower? > > Greping through pulseaudio sources > (git://anongit.freedesktop.org/pulseaudio/pulseaudio) for 'battery' > doesn't return anything, so anything about battery power seems unlikely > to be merged into pulseaudio. > > upower already expose batteries from bluez through dbus > (git://anongit.freedesktop.org/upower:src/linux/up-device-bluez.c) > > So is it possible to do the AT commands at the bluez level and expose > the infos through dbus, so upower expose it to the rest of the system? > > Thanks, > Hugues > > On 02/24/2017 12:01 PM, Hugues wrote: > > Hello, > > Thanks a lot! > > I tried to connect to the headset through dbus to make the AT commands, > > but failed. > > So what's the services/program where this should be implemented so it > > can be exposed on dbus and picked up by the Desktop Environment? > > > > Regards, > > Hugues > > > > On 02/13/2017 06:55 AM, Sebastian Reichel wrote: > >> Hi, > >> > >> FWIW I was also interested in battery level of my Bose QC35 and > >> checked this some time ago. That time I only checked the low > >> energy stuff, since the Android application seems to know the > >> battery status with only LE being connected. > >> > >> Marcel Holtman wrote: > >>>> This headset do have dual mode, I searched around using gatttool ant the > >>>> gatt specification but I find nothing about Battery Level > >>>> (org.bluetooth.characteristic.battery_level.xml) or Battery Service > >>>> (org.bluetooth.service.battery_service.xml). > >> > >> Bose QC35 does not expose battery status through standard battery_level > >> characteristic. There is a proprietary primary service 0xfebe (which > >> is assigned to Bose) with a couple of custom services. I assume battery > >> level can be read through them, but the required commands are unknown. > >> > >>>> How could I read what's in the Apple HFP extensions? > >>> > >>> Start with this one. It describes the extra HFP AT commands that iOS uses: > >>> > >>> https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf > >> > >> Thanks for the documentation link! That is actually implemented for > >> the Bose QC35. Here is a quick hack providing battery status info > >> in pulseaudio log: > >> > >> https://github.com/sre/pulseaudio/commit/d66b66d20e9bc73e6d0ca89283cf2b5675304b00 > >> > >> -- Sebastian > >> > > >
Attachment:
signature.asc
Description: PGP signature
