Hello!
I would like to open a discussion about problems related to HSP and HFP
profiles usage via bluez D-Bus API.
Bluez daemon since version 5 does not provide internal AT command parser
and relay on application's implementation which registers itself to
bluez via D-Bus API. Application get then via D-Bus bluetooth socket /
file descriptor and therefore must implement whole HSP and HFP profiles.
HSP/HFP profiles today provide lot of different services, including
custom vendors extensions. E.g. bi-directional audio, controls for GSM
calls (answer, reject, ring event), push button notification, battery
status indication, etc...
Basically set of fully different services which are on Linux system
managed by totally different layers or applications. E.g. audio by
pulseaudio, modem by ofono, buttons by linux input layer, battery by
upowerd, ... Some of them are running under ordinary user, some of them
as root; and at different D-Bus levels (system or different user
sessions); so synchronization is hard and maybe not possible (in some
cases).
Plus because different devices use different and custom vendor
extensions, all these services cannot be implemented by one application
which receive bluetooth socket from bluez D-Bus API.
To solve this problem, I would propose a solution for this:
Implement a new central daemon talking on system D-Bus which would
register for HSP and HFP profiles to bluez and then would export needed
information via D-Bus, so other application could implement needed
services (including those new custom vendor extensions).
What do you think about it?
--
Pali Rohár
[email protected]