Age | Commit message (Collapse) | Author | Files | Lines |
|
When there are many devices around that support the HFP AG profile,
we may have a lot of modems that the user will never use.
|
|
This patch removes unnecessary GDBusProxy object access when property
changed is triggered. The property name and the argument iterator is
informed in the function callback.
|
|
|
|
This patch fix an unusual scenario, service_level_connection() fails if
GIOChannel or GAtChat memory allocation fails.
|
|
Rename this property to better indicate that it is the remote Address
being referred to.
|
|
This patch adds a copy of Bluetooth RFCOMM socket declaration.
|
|
Adds a copy of BlueZ bacmp() function.
|
|
Adds a copy of BlueZ ba2str() function.
|
|
This patch adds the initial SCO server socket handling. BtIO and BlueZ
functions should not be used, with the new Profile API the objetive is
to get rid of these dependencies.
|
|
Adds a copy of BlueZ bacpy() function.
|
|
Adds local copy of SCO Bluetooth sockets declarations, since the
objective to avoid including BlueZ library headers.
|
|
When receiving a NewConnection call from BlueZ, initiates the Service
Level Connection using the received file descriptor. The HFP modem
sub-components (devinfo, voicecall, netreg, handsfree and callvolume)
are created at this point.
|
|
Parse the essential arguments in the message, in this case only the
file descriptor, and register the modem if it is not already
registered. This is necessary because in some cases, we may receive a
NewConnection call, and the SDP process is still taking place.
|
|
If the device Alias property changes we should also change the name of
the modem.
|
|
Now that we are able to keep track of devices appearing and
disappearing from BlueZ, we are able to register the modem when a
device that supports the HFP AG UUID appears.
|
|
|
|
This patch tracks the GDBusProxy for Bluetooth devices in order to be
able to get their properties.
|
|
This patch adds the initial callbacks to track when BlueZ connects so
we can register our HFP external profile handler. And tracks the
interfaces added or removed.
|
|
|
|
|
|
|
|
If we send these commands before the EMRDY notification has been seen,
they will simply return an error.
|
|
|
|
Some phones do not send the corresponding call state update (+CIEV)
after a successful release-and-swap operation (AT+CHLD=1).
This has been observed with a Nokia 500, while testing ReleaseAndSwap()
while an active and a held call exist:
ofonod[20414]: > AT+CLCC\r
ofonod[20414]: < \r\n+CLCC: 1,0,1,0,0,"<number1>",145\r\n
ofonod[20414]: < \r\n+CLCC: 2,0,0,0,0,"<number2>",145\r\n
ofonod[20414]: < \r\nOK\r\n
ofonod[20414]: > AT+CHLD=1\r
ofonod[20414]: < \r\nOK\r\n
After this, no +CIEV is received, but the call has been hung up.
The proposed approach to solve this consists of using AT+CLCC, unless
a call release has been received within a specific time period.
The result fixes the problem as can be seen below:
ofonod[20847]: < \r\n+CLCC: 1,0,1,0,0,"<number1>",145\r\n
ofonod[20847]: < \r\n+CLCC: 2,0,0,0,0,"<number2>",145\r\n
ofonod[20847]: < \r\nOK\r\n
ofonod[20847]: > AT+CHLD=1\r
ofonod[20847]: < \r\nOK\r\n
ofonod[20847]: > AT+CLCC\r
ofonod[20847]: < \r\n+CLCC: 1,0,0,0,0,"<number1>",145\r\n
ofonod[20847]: < \r\nOK\r\n
ofonod[20847]: < \r\n+CIEV: 5,2\r\n
ofonod[20847]: < \r\n+CIEV: 5,0\r\n
|
|
While processing the result of AT+CLCC, process the differences in a way
that disconnections are reported first, then call state changes and
finally new calls.
The goal is to avoid unnecessary transitional states such as two active
calls existing at the same time.
|
|
Define a helper function in order to use foreach statements when
ofono_voicecall_notify() needs to be called.
|
|
|
|
Right now, only the mandatory CVSD codec is supported. The mSBC
mandatory codec is "temporarily" not supported.
The spec alows this, HFP 1.6 Spec Section 4.34.1 page 92: "If wide band
speech is supported then the mandatory codec (mSBC) shall be included
unless it is temporarily unavailable."
|
|
|
|
|
|
Makefile.am:518: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
|
|
The long-obsoleted AM_CONFIG_HEADER macro was removed in automake 1.13.
Use AC_CONFIG_HEADERS instead.
|
|
src/storage.h:32:1: error: unknown type name 'ssize_t'
src/storage.h:36:1: error: unknown type name 'ssize_t'
|
|
This patch declares the external HFP Profile handler. It contains the
initial implementation of the D-Bus Profile1 interface and methods
responsible for handling Bluetooth connections.
|
|
|
|
|
|
Adds utility API to handle BlueZ 5 RegisterProfile and UnregisterProfile
methods.
|
|
This patch adds the initial file to support external HFP profile and
BlueZ 5. "hfp_hf_bluez5" plugin will implement an external Bluetooth
profile compatible with BlueZ 5, and "hfp_hf_bluez4" plugin will keep
the compatibility with BlueZ 4.
|
|
This patch adds the file for Bluetooth(BlueZ 5) oFono plugin.
|
|
As BlueZ 5 introduced backwards incompatible API changes, and we want to
keep support for BlueZ 4 based plugins for some time, we need to separate
the plugins that are based on BlueZ 4 from the ones based on BlueZ 5.
The bluetooth.c plugin has now been renamed to bluez4.c and the hfp_hf.c
plugin is renamed to hfp_hf_bluez4. This will make it easy to add a
HFP HF plugin for BlueZ 5.
|
|
Going forward, BlueZ 5 will be supported by default. BlueZ 4 support
will have to be explicitly enabled by using '--enable-bluez4'.
As before, the '--disable-bluetooth' configure option will disable all
bluetooth support (BlueZ 4 and BlueZ 5)
|
|
|
|
|
|
|
|
This reverts commit dfd1fae50b8197b0b4ed81fed3139726e4ae1bf5.
|
|
|
|
|
|
This matches the huawei plugin.
|
|
The pointer returned by dbus_message_iter_get_signature() must be freed
with dbus_free().
Fixes this memory leak:
==1857== 16 bytes in 1 blocks are definitely lost in loss record 104 of
251
==1857== at 0x402BF52: realloc (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==1857== by 0x415E286: dbus_realloc (in
/lib/i386-linux-gnu/libdbus-1.so.3.5.8)
==1857== by 0x415E70B: ??? (in
/lib/i386-linux-gnu/libdbus-1.so.3.5.8)
==1857== by 0x415F17B: ??? (in
/lib/i386-linux-gnu/libdbus-1.so.3.5.8)
==1857== by 0x414CB33: dbus_message_iter_get_signature (in
/lib/i386-linux-gnu/libdbus-1.so.3.5.8)
==1857== by 0x8053239: properties_set (object.c:899)
==1857== by 0x5FFFFF: ???
==1857==
|
|
|