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 pali.rohar@xxxxxxxxx
