summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2013-12-18hfp_hf_bluez4: Enable Siri atomKrzysztof Wilk1-0/+2
2013-12-18siri: Add atom driverKrzysztof Wilk4-1/+221
2013-12-18siri: Add atom implementationKrzysztof Wilk3-1/+335
2013-12-18include: Add Siri interface definitionKrzysztof Wilk2-1/+64
2013-12-18dbus: Define Siri DBUS InterfaceKrzysztof Wilk1-0/+1
2013-12-18doc: Add Siri APIKrzysztof Wilk2-1/+42
2013-12-05AUTHORS: Mention Andrew's contributionsDenis Kenzior1-0/+1
2013-12-05hfp: Add Voice Recognition flag to BRSFAndrew Earl1-0/+1
2013-11-26he910: tweak initialization logicDenis Kenzior1-11/+6
2013-11-26netreg: Turn off CIEV indications other than rssiDenis Kenzior1-0/+11
2013-11-26AUTHORS: Mention Slava's contributionsDenis Kenzior1-0/+1
2013-11-26mbpi: Provision mmsc and message_proxySlava Monich1-0/+6
2013-11-25hfp_ag_bluez5: Try to support non-phone hardwareDenis Kenzior1-0/+37
For devices which are not 'real' phone modems, the voicecall initialization can happen outside of the pre-sim state. In this case the voicecall atom detection logic fails. Try to detect the voicecall atom separately, and register the profile if the SIM atom is already present and in state 'READY'. For all other cases, the previous logic still applies.
2013-11-25udevng: Add he910 detection logicDenis Kenzior1-0/+34
2013-11-25plugins: Add initial Telit he910 driverDenis Kenzior2-0/+385
2013-11-25build: Always build the connman pluginDenis Kenzior1-3/+3
It is not related to BLUEZ 4 support
2013-11-11gdbus: Fix trying to remove already removed sourcesBastien Nocera1-0/+3
When we return FALSE from idle handlers, the source is removed. This will be causing warnings in glib 2.40. See https://bugzilla.gnome.org/show_bug.cgi?id=710724
2013-11-08Release 1.13Marcel Holtmann2-1/+13
2013-10-17mbm: Fix segfault with hot-plugged MD300 modemDenis Kenzior1-0/+4
2013-10-14gdbus: Remove not needed check for NULL DBusPendingCallSzymon Janc1-5/+0
It is now checked by g_dbus_send_message_with_reply() so there is no need to double check that in caller.
2013-10-14gdbus: Check for NULL DBusPendingCall in g_dbus_send_message_with_replySzymon Janc1-1/+10
"Warning: if the connection is disconnected or you try to send Unix file descriptors on a connection that does not support them, the DBusPendingCall will be set to NULL, so be careful with this." Check this in g_dbus_send_message_with_reply so that callers don't need to double check for NULL if g_dbus_send_message_with_reply returned TRUE. This also fix crash if passing FD over D-Bus is blocked e.g. by SELinux policy. bluetoothd[1894]: profiles/audio/avdtp.c:session_cb() bluetoothd[1894]: profiles/audio/avdtp.c:avdtp_parse_cmd() Received SET_CONFIGURATION_CMD bluetoothd[1894]: profiles/audio/a2dp.c:endpoint_setconf_ind() Source 0x6c5000: Set_Configuration_Ind bluetoothd[1894]: profiles/audio/avdtp.c:avdtp_ref() 0x6df360: ref=1 bluetoothd[1894]: profiles/audio/a2dp.c:setup_ref() 0x6d32b0: ref=1 process 1894: arguments to dbus_pending_call_set_notify() were incorrect, assertion "pending != NULL" failed in file dbus-pending-call.c line 636. This is normally a bug in some application using the D-Bus library.
2013-10-01hfp_hf_bluez5: Be more pedantic in get_versionDenis Kenzior1-5/+6
If no 'Version' key is found we might be assigning an uninitialized value. Return an error in this case as the 'Version' key is required.
2013-10-01hfp_hf_bluez5: Add version debug infoDenis Kenzior1-0/+2
2013-09-12handsfree-audio: Don't listen() if no defer_setupVinicius Costa Gomes1-0/+3
As we won't allow any card to be registered when the kernel doesn't support defer_setup, we don't need to have the listening SCO socket open in this case.
2013-09-12handsfree-audio: Don't register if no defer_setupVinicius Costa Gomes1-0/+3
If the kernel doesn't support defer_setup for SCO, we shouldn't allow cards to be registered, because in that case we won't be able to properly send the file descriptor to the Agent.
2013-09-12handsfree-audio: Set socket parametersVinicius Costa Gomes1-0/+5
In the AG case, the voice setting needs to be set before we can use Transparent SCO mode, which is necessary for Wideband speech support.
2013-09-12handsfree-audio: Detect transparent SCO in kernelVinicius Costa Gomes3-6/+16
Deferred SCO setup is not enough for HFP 1.6 wideband codec support. Wideband speech also requires Transparent SCO to be enabled in the kernel.
2013-09-12handsfree-audio: Tweak logic a bitDenis Kenzior1-4/+4
2013-09-12handsfree-audio: Add setting SCO air modeVinicius Costa Gomes1-0/+32
2013-09-12hfp_hf_bluez5: Remove Cancel methodDenis Kenzior1-11/+0
2013-09-12hfp_hf_bluez5: Mark Release method as NOREPLYDenis Kenzior1-4/+2
2013-09-12test: Add set-msisdn scriptDenis Kenzior2-1/+26
2013-09-12test: Add display-icon scriptDenis Kenzior2-1/+36
2013-09-12hfpmodem: Call ofono_voicecall_mpty_hint as neededDenis Kenzior1-2/+7
2013-09-12atmodem: Update parse_clcc utility functionDenis Kenzior3-4/+11
2013-09-12voicecall: Implement ofono_voicecall_mpty_hintDenis Kenzior1-0/+40
2013-09-12include: Add voicecall multiparty hint methodDenis Kenzior1-0/+7
On protocols that support creation of multiparty calls outside of oFono's control, we need a way to detect multiparty call transitions. This method adds a way for the driver to hint the core which calls should be part of the multiparty call. Right now this is relevant only to HFP. Real modem hardware should not be using this method.
2013-09-12test: Add selecting the modem in private-chatDenis Kenzior1-1/+7
2013-09-12test: Add selecting the modem in create-multipartyDenis Kenzior1-1/+4
2013-09-12gdbus/client: Use g_dbus_add_properties_watch to track propertiesLuiz Augusto von Dentz1-79/+56
This make the handling much simpler and avoids duplicates of the same match rule.
2013-09-12gdbus/client: Use g_dbus_add_signal_watch to track signalsLuiz Augusto von Dentz1-36/+37
This make the handling much simpler and avoids duplicates of the same match rule.
2013-09-12gdbus/client: Use g_dbus_add_service_watch to track servicesLuiz Augusto von Dentz1-135/+38
This make the handling much simpler and avoids duplicates of the same match rule.
2013-09-12gdbus/watch: Fix crash when disconnecting from D-BusLuiz Augusto von Dentz1-0/+2
When disconnecting from D-Bus a message could be recieved with no sender: Invalid read of size 1 at 0x4A09EE1: strcmp (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) by 0x3B03C386B8: g_str_equal (in /usr/lib64/libglib-2.0.so.0.3600.3) by 0x4065D6: message_filter (watch.c:529) by 0x3B0700F9E5: dbus_connection_dispatch (in /usr/lib64/libdbus-1.so.3.7.4) by 0x4052E7: message_dispatch (mainloop.c:76) by 0x3B03C48962: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3) by 0x3B03C47E05: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3600.3) by 0x3B03C48157: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3) by 0x3B03C48559: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3600.3) by 0x4038C5: client_proxy_removed (test-gdbus-client.c:902) by 0x3B03C6B566: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3) by 0x3B03C6B6E5: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3) Address 0x0 is not stack'd, malloc'd or (recently) free'd
2013-09-12gdbus/watch: Fix aborting when removing D-Bus filterLuiz Augusto von Dentz1-17/+8
In case of filter_data having a watch to a service name it may call dbus_connection_remove_filter twice causing libdbus to abort: process 24723: Attempt to remove filter function 0x4063e0 user data (nil), but no such filter has been added To fix this the code will now only attempt to call dbus_connection_remove_filter once in filter_data_free which is the counterpart of filter_data_get where dbus_connection_add_filter is called.
2013-09-12gdbus/watch: Fix crash when g_dbus_remove_watch is called from connect callbackLuiz Augusto von Dentz1-2/+6
at 0x40570C: update_service (watch.c:601) by 0x40584B: service_reply (watch.c:627) by 0x3B0700C511: ??? (in /usr/lib64/libdbus-1.so.3.7.4) by 0x3B0700F740: dbus_connection_dispatch (in /usr/lib64/libdbus-1.so.3.7.4) by 0x405167: message_dispatch (mainloop.c:76) by 0x3B03C48962: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3) by 0x3B03C47E05: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3600.3) by 0x3B03C48157: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3) by 0x3B03C48559: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3600.3) Address 0x4c58a30 is 32 bytes inside a block of size 56 free'd at 0x4A074C4: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) by 0x3B03C4D9AE: g_free (in /usr/lib64/libglib-2.0.so.0.3600.3) by 0x406102: filter_data_remove_callback (watch.c:378) by 0x405FC0: g_dbus_remove_watch (watch.c:798) by 0x40A22B: g_dbus_client_unref (client.c:1227) by 0x40570B: update_service (watch.c:599) by 0x40584B: service_reply (watch.c:627)
2013-09-10gdbus: Fix emitting PropertiesChanged twiceLuiz Augusto von Dentz1-2/+2
This fixes double emission of PropertiesChanged introduced by flushing changes, the flushing can happen during the pending processing so the pending_prop flag needs to be updated in the beginning and the list of properties can be freed before g_dbus_send_message as it is not required anymore.
2013-09-10gdbus: Avoid calling dbus_connection_send*Luiz Augusto von Dentz2-64/+42
dbus_connection_send* should not be called directly except by g_dbus_send_message.
2013-09-10gdbus: Add g_dbus_send_message_with_replyLuiz Augusto von Dentz2-0/+14
g_dbus_send_message_with_reply flushes pending signals before calling dbus_connection_send_with_reply so it does not alter the message order
2013-09-10gdbus: Fix sending ObjectManager/Properties signals out of orderLuiz Augusto von Dentz1-16/+53
In some cases the order of the messages is altered when a message is sent without processing the pending signals first, currently this affect client_check_order unit test: /gdbus/client_check_order: ** ERROR:unit/test-gdbus-client.c:795:property_check_order: assertion failed: (g_strcmp0(string, "value1") == 0) As can be observed the value of the property is not yet updated because the signal it is still pending, once this fix is applied the test pass: /gdbus/client_check_order: OK Note that the flushing only works when g_dbus_send_message is used so places where dbus_connection_send and other variants are called directly may still change the order.
2013-09-03smsutil: Make sure to return 1/0Denis Kenzior1-1/+1
So the value might be used directly for D-Bus property emission. Otherwise D-Bus asserts and screws itself with: ofonod[7427]: src/sms.c:handle_mwi() process 7427: arguments to dbus_message_iter_append_basic() were incorrect, assertion "*bool_p == 0 || *bool_p == 1" failed in file ../../dbus/dbus-message.c line 2549.