2011-12-02 18:34:05

by Anderson Lizardo

[permalink] [raw]
Subject: [PATCH RFC BlueZ 0/5] Time Profile (server) improvements

Hi,

This series implements two new features for GATT Time Profile (server role):

* Reference Time Update Service (RTUS), with two drivers (called "providers"
here): dummy (for testing) and timed (for N9/harmattan)
* Support for current time notifications

We are aware of the current plan of moving platform specific code out of BlueZ
(to agents communicating over D-Bus). Is it feasible to be done now for GATT
servers as well?

Comments are welcome.

Best Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia (INdT)
Manaus - Brazil


2011-12-02 18:34:10

by Anderson Lizardo

[permalink] [raw]
Subject: [PATCH RFC BlueZ 5/5] Add testing API to dummy Time Server provider

The new TimeUpdated() is useful to test Current Time Characteristic
value notifications.
---
time/provider-dummy.c | 39 +++++++++++++++++++++++++++++++++++++++
1 files changed, 39 insertions(+), 0 deletions(-)

diff --git a/time/provider-dummy.c b/time/provider-dummy.c
index ba0744f..ab90f7b 100644
--- a/time/provider-dummy.c
+++ b/time/provider-dummy.c
@@ -23,20 +23,59 @@
*/

#include <stdint.h>
+#include <glib.h>
+#include <dbus/dbus.h>
+#include <gdbus.h>

#include "server.h"
#include "log.h"

+#define TIME_DUMMY_IFACE "org.bluez.TimeProviderTest"
+#define TIME_DUMMY_PATH "/org/bluez/test"
+
+static DBusConnection *connection = NULL;
+
+static DBusMessage *time_updated(DBusConnection *conn, DBusMessage *msg,
+ void *data)
+{
+ DBG("");
+
+ current_time_updated();
+
+ return dbus_message_new_method_return(msg);
+}
+
+static GDBusMethodTable dummy_methods[] = {
+ { "TimeUpdated", "", "", time_updated },
+};
+
int time_provider_init(void)
{
DBG("");

+ connection = dbus_bus_get(DBUS_BUS_SYSTEM, NULL);
+
+ if (g_dbus_register_interface(connection, TIME_DUMMY_PATH,
+ TIME_DUMMY_IFACE, dummy_methods, NULL,
+ NULL, NULL, NULL) == FALSE) {
+ error("time-dummy interface %s init failed on path %s",
+ TIME_DUMMY_IFACE, TIME_DUMMY_PATH);
+ dbus_connection_unref(connection);
+
+ return -1;
+ }
+
return 0;
}

void time_provider_exit(void)
{
DBG("");
+
+ g_dbus_unregister_interface(connection, TIME_DUMMY_PATH,
+ TIME_DUMMY_IFACE);
+ dbus_connection_unref(connection);
+ connection = NULL;
}

void time_provider_status(uint8_t *state, uint8_t *result)
--
1.7.0.4


2011-12-02 18:34:09

by Anderson Lizardo

[permalink] [raw]
Subject: [PATCH RFC BlueZ 4/5] Add support for sending notifications for current time

From: Vinicius Costa Gomes <[email protected]>

Now, we are able to send notifications when the time gets updated,
this should occur when, for example, the user changes the system's
timezone.
---
time/server.c | 117 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
time/server.h | 2 +
2 files changed, 118 insertions(+), 1 deletions(-)

diff --git a/time/server.c b/time/server.c
index 56eecb1..df70d2f 100644
--- a/time/server.c
+++ b/time/server.c
@@ -29,10 +29,17 @@
#include <glib.h>
#include <time.h>
#include <errno.h>
+#include <stdlib.h>
#include <bluetooth/uuid.h>

+#include "adapter.h"
+#include "manager.h"
+
#include "att.h"
#include "gattrib.h"
+#include "attio.h"
+#include "textfile.h"
+#include "storage.h"
#include "attrib-server.h"
#include "gatt-service.h"
#include "log.h"
@@ -46,6 +53,21 @@
#define TIME_UPDATE_STAT_CHR_UUID 0x2A17
#define CT_TIME_CHR_UUID 0x2A2B

+struct adapter_ccc {
+ struct btd_adapter *adapter;
+ uint16_t handle;
+};
+
+struct notify_callback {
+ struct btd_device *device;
+ guint id;
+};
+
+static GSList *devices_notify;
+
+static uint16_t current_time_ccc_handle;
+static uint16_t current_time_value_handle;
+
static int encode_current_time(uint8_t value[10])
{
struct timespec tp;
@@ -92,6 +114,94 @@ static uint8_t current_time_read(struct attribute *a, gpointer user_data)
return 0;
}

+static void filter_devices_notify(char *key, char *value, void *user_data)
+{
+ struct adapter_ccc *ccc = user_data;
+ struct btd_adapter *adapter = ccc->adapter;
+ struct btd_device *device;
+ char addr[18];
+ uint16_t handle, ccc_val;
+
+ sscanf(key, "%17s#%04hX", addr, &handle);
+
+ if (ccc->handle != handle)
+ return;
+
+ ccc_val = strtol(value, NULL, 16);
+ if (!(ccc_val & 0x0001))
+ return;
+
+ device = adapter_find_device(adapter, addr);
+ if (device == NULL)
+ return;
+
+ if (g_slist_find(devices_notify, device))
+ return;
+
+ devices_notify = g_slist_append(devices_notify, device);
+}
+
+static GSList *devices_to_notify(struct btd_adapter *adapter, uint16_t ccc_hnd)
+{
+ struct adapter_ccc ccc_list = { adapter, ccc_hnd };
+ char filename[PATH_MAX + 1];
+ char srcaddr[18];
+ bdaddr_t src;
+
+ adapter_get_address(adapter, &src);
+ ba2str(&src, srcaddr);
+
+ create_name(filename, PATH_MAX, STORAGEDIR, srcaddr, "ccc");
+
+ textfile_foreach(filename, filter_devices_notify, &ccc_list);
+
+ return devices_notify;
+}
+
+static void send_notification(GAttrib *attrib, gpointer user_data)
+{
+ struct notify_callback *callback = user_data;
+ uint8_t value[10], pdu[ATT_MAX_MTU];
+ int err, len;
+
+ err = encode_current_time(value);
+ if (err)
+ goto done;
+
+ len = enc_notification(current_time_value_handle, value, sizeof(value),
+ pdu, sizeof(pdu));
+ g_attrib_send(attrib, 0, ATT_OP_HANDLE_NOTIFY, pdu, len,
+ NULL, NULL, NULL);
+
+done:
+ btd_device_remove_attio_callback(callback->device, callback->id);
+ devices_notify = g_slist_remove(devices_notify, callback->device);
+ g_free(callback);
+}
+
+void current_time_updated(void)
+{
+ struct btd_adapter *adapter;
+ GSList *devices, *l;
+
+ adapter = manager_get_default_adapter();
+ if (adapter == NULL)
+ return;
+
+ devices = devices_to_notify(adapter, current_time_ccc_handle);
+
+ for (l = devices; l; l = l->next) {
+ struct btd_device *device = l->data;
+ struct notify_callback *callback;
+
+ callback = g_new0(struct notify_callback, 1);
+ callback->device = device;
+
+ callback->id = btd_device_add_attio_callback(device,
+ send_notification, NULL, callback);
+ }
+}
+
static uint8_t local_time_info_read(struct attribute *a, gpointer user_data)
{
uint8_t value[2];
@@ -123,7 +233,10 @@ static void register_current_time_service(void)
ATT_CHAR_PROPER_NOTIFY,
GATT_OPT_CHR_VALUE_CB, ATTRIB_READ,
current_time_read,
-
+ GATT_OPT_CCC_GET_HANDLE,
+ &current_time_ccc_handle,
+ GATT_OPT_CHR_VALUE_GET_HANDLE,
+ &current_time_value_handle,
/* Local Time Information characteristic */
GATT_OPT_CHR_UUID, LOCAL_TIME_INFO_CHR_UUID,
GATT_OPT_CHR_PROPS, ATT_CHAR_PROPER_READ,
@@ -193,4 +306,6 @@ int time_server_init(void)
void time_server_exit(void)
{
time_provider_exit();
+
+ g_slist_free(devices_notify);
}
diff --git a/time/server.h b/time/server.h
index 0e1f858..91be6e8 100644
--- a/time/server.h
+++ b/time/server.h
@@ -51,3 +51,5 @@ void time_provider_exit(void);
/* Time provider control and status routines. Implemented by provider-*.c */
void time_provider_status(uint8_t *state, uint8_t *result);
uint8_t time_provider_control(int op);
+
+void current_time_updated(void);
--
1.7.0.4


2011-12-02 18:34:08

by Anderson Lizardo

[permalink] [raw]
Subject: [PATCH RFC BlueZ 3/5] Time Profile: Add "timed" time provider

From: Sheldon Demario <[email protected]>

This provider adds support for timed, which is used on Harmattan for
managing time information.
---
Makefile.am | 2 +-
time/provider-timed.c | 141 +++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 142 insertions(+), 1 deletions(-)
create mode 100644 time/provider-timed.c

diff --git a/Makefile.am b/Makefile.am
index ac562b9..089d86f 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -346,7 +346,7 @@ EXTRA_DIST += src/genbuiltin src/bluetooth.conf \
audio/audio.conf audio/telephony-dummy.c \
audio/telephony-maemo5.c audio/telephony-ofono.c \
audio/telephony-maemo6.c sap/sap-dummy.c sap/sap-u8500.c \
- time/provider-dummy.c \
+ time/provider-dummy.c time/provider-timed.c \
proximity/proximity.conf

if ALSA
diff --git a/time/provider-timed.c b/time/provider-timed.c
new file mode 100644
index 0000000..62774e1
--- /dev/null
+++ b/time/provider-timed.c
@@ -0,0 +1,141 @@
+/*
+ *
+ * BlueZ - Bluetooth protocol stack for Linux
+ *
+ * Copyright (C) 2011 Nokia Corporation
+ * Copyright (C) 2011 Marcel Holtmann <[email protected]>
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+#ifdef HAVE_CONFIG_H
+#include <config.h>
+#endif
+
+#include <glib.h>
+#include <time.h>
+#include <errno.h>
+#include <bluetooth/uuid.h>
+#include <bluetooth/sdp.h>
+#include <dbus/dbus.h>
+#include <gdbus.h>
+
+#include "log.h"
+#include "server.h"
+#include "glib-helper.h"
+
+static guint watch = 0;
+static DBusConnection *connection = NULL;
+static gboolean source_online = FALSE;
+static uint8_t update_state = UPDATE_STATE_IDLE;
+static uint8_t update_result = UPDATE_RESULT_NOT_ATTEMPTED;
+
+uint8_t time_provider_control(int op)
+{
+ switch (op) {
+ case GET_REFERENCE_UPDATE:
+ /* Usually we should check for UPDATE_STATE_PENDING here, but
+ * on Harmattan reference time updates are passive (through
+ * cellular network). */
+
+ update_state = UPDATE_STATE_IDLE;
+ if (!source_online)
+ update_result = UPDATE_RESULT_NO_CONN;
+ else
+ update_result = UPDATE_RESULT_SUCCESSFUL;
+
+ break;
+ case CANCEL_REFERENCE_UPDATE:
+ update_state = UPDATE_STATE_IDLE;
+ update_result = UPDATE_RESULT_CANCELED;
+ break;
+ default:
+ DBG("Invalid control point value: 0x%02x", op);
+ }
+
+ return 0;
+}
+
+void time_provider_status(uint8_t *state, uint8_t *result)
+{
+ *state = update_state;
+ *result = update_result;
+}
+
+static gboolean settings_changed(DBusConnection *conn, DBusMessage *msg,
+ void *data)
+{
+ DBusMessageIter iter, res;
+
+ DBG("");
+
+ update_state = UPDATE_STATE_IDLE;
+
+ dbus_message_iter_init(msg, &iter);
+
+ if (dbus_message_iter_get_arg_type(&iter) != DBUS_TYPE_STRUCT) {
+ DBG("Unexpected signature");
+ update_result = UPDATE_RESULT_ERROR;
+
+ return TRUE;
+ }
+
+ dbus_message_iter_recurse(&iter, &res);
+ if (dbus_message_iter_get_arg_type(&res) != DBUS_TYPE_BOOLEAN) {
+ DBG("Unexpected signature");
+ update_result = UPDATE_RESULT_ERROR;
+
+ return TRUE;
+ }
+
+ dbus_message_iter_get_basic(&res, &source_online);
+ if (!source_online) {
+ DBG("No connection to reference time");
+ update_result = UPDATE_RESULT_NO_CONN;
+ } else
+ update_result = UPDATE_RESULT_SUCCESSFUL;
+
+ return TRUE;
+}
+
+int time_provider_init(void)
+{
+ connection = dbus_bus_get(DBUS_BUS_SYSTEM, NULL);
+
+ watch = g_dbus_add_signal_watch(connection, "com.nokia.time",
+ "/com/nokia/time",
+ "com.nokia.time",
+ "settings_changed",
+ settings_changed,
+ NULL, NULL);
+
+ if (watch == 0) {
+ dbus_connection_unref(connection);
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+
+void time_provider_exit(void)
+{
+ g_dbus_remove_watch(connection, watch);
+ watch = 0;
+
+ dbus_connection_unref(connection);
+ connection = NULL;
+}
--
1.7.0.4


2011-12-02 18:34:07

by Anderson Lizardo

[permalink] [raw]
Subject: [PATCH RFC BlueZ 2/5] Time Profile: implement generic "time provider" interface

From: Sheldon Demario <[email protected]>

With this new interface, it is possible to implement providers for each
supported platform.

This commit adds an initial "dummy" provider, useful for testing.
---
.gitignore | 1 +
Makefile.am | 6 +++++
acinclude.m4 | 7 ++++++
time/provider-dummy.c | 53 +++++++++++++++++++++++++++++++++++++++++++++++++
time/server.c | 17 +++++++++++----
time/server.h | 8 +++++++
6 files changed, 87 insertions(+), 5 deletions(-)
create mode 100644 time/provider-dummy.c

diff --git a/.gitignore b/.gitignore
index badd1a0..ba78b68 100644
--- a/.gitignore
+++ b/.gitignore
@@ -36,6 +36,7 @@ src/builtin.h
src/bluetoothd
audio/telephony.c
sap/sap.c
+time/provider.c
scripts/bluetooth.rules
scripts/97-bluetooth.rules
scripts/97-bluetooth-hid2hci.rules
diff --git a/Makefile.am b/Makefile.am
index 07b8626..ac562b9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -226,6 +226,8 @@ if TIMEPLUGIN
builtin_modules += time
builtin_sources += time/main.c \
time/server.h time/server.c
+
+builtin_nodist += time/provider.c
endif

if ALERTPLUGIN
@@ -344,6 +346,7 @@ EXTRA_DIST += src/genbuiltin src/bluetooth.conf \
audio/audio.conf audio/telephony-dummy.c \
audio/telephony-maemo5.c audio/telephony-ofono.c \
audio/telephony-maemo6.c sap/sap-dummy.c sap/sap-u8500.c \
+ time/provider-dummy.c \
proximity/proximity.conf

if ALSA
@@ -479,6 +482,9 @@ src/builtin.h: src/genbuiltin $(builtin_sources)
audio/telephony.c: audio/@TELEPHONY_DRIVER@
$(AM_V_GEN)$(LN_S) $(abs_top_srcdir)/$< $@

+time/provider.c: time/@TIME_PROVIDER@
+ $(AM_V_GEN)$(LN_S) $(abs_top_srcdir)/$< $@
+
sap/sap.c: sap/@SAP_DRIVER@
$(AM_V_GEN)$(LN_S) $(abs_top_srcdir)/$< $@

diff --git a/acinclude.m4 b/acinclude.m4
index 2097d77..5930a79 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -213,6 +213,7 @@ AC_DEFUN([AC_ARG_BLUEZ], [
dfutool_enable=no
datafiles_enable=yes
telephony_driver=dummy
+ time_provider=dummy
maemo6_enable=no
sap_driver=dummy
dbusoob_enable=no
@@ -252,6 +253,12 @@ AC_DEFUN([AC_ARG_BLUEZ], [
time_enable=${enableval}
])

+ AC_ARG_WITH(time, AC_HELP_STRING([--with-time=PROVIDER], [select time provider]), [
+ time_provider=${withval}
+ ])
+
+ AC_SUBST([TIME_PROVIDER], [provider-${time_provider}.c])
+
AC_ARG_ENABLE(alert, AC_HELP_STRING([--enable-alert], [enable Phone Alert Profile plugin]), [
alert_enable=${enableval}
])
diff --git a/time/provider-dummy.c b/time/provider-dummy.c
new file mode 100644
index 0000000..ba0744f
--- /dev/null
+++ b/time/provider-dummy.c
@@ -0,0 +1,53 @@
+/*
+ *
+ * BlueZ - Bluetooth protocol stack for Linux
+ *
+ * Copyright (C) 2011 Nokia Corporation
+ * Copyright (C) 2011 Marcel Holtmann <[email protected]>
+ *
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+#include <stdint.h>
+
+#include "server.h"
+#include "log.h"
+
+int time_provider_init(void)
+{
+ DBG("");
+
+ return 0;
+}
+
+void time_provider_exit(void)
+{
+ DBG("");
+}
+
+void time_provider_status(uint8_t *state, uint8_t *result)
+{
+ *state = UPDATE_STATE_IDLE;
+ *result = UPDATE_RESULT_NOT_ATTEMPTED;
+}
+
+uint8_t time_provider_control(int op)
+{
+ DBG("");
+
+ return 0;
+}
diff --git a/time/server.c b/time/server.c
index 4958fd3..56eecb1 100644
--- a/time/server.c
+++ b/time/server.c
@@ -137,10 +137,12 @@ static uint8_t time_update_control(struct attribute *a, gpointer user_data)
{
DBG("handle 0x%04x", a->handle);

- if (a->len != 1)
+ if (a->len != 1) {
DBG("Invalid control point value size: %d", a->len);
+ return 0;
+ }

- return 0;
+ return time_provider_control(a->data[0]);
}

static uint8_t time_update_status(struct attribute *a, gpointer user_data)
@@ -149,8 +151,8 @@ static uint8_t time_update_status(struct attribute *a, gpointer user_data)

DBG("handle 0x%04x", a->handle);

- value[0] = UPDATE_STATE_IDLE;
- value[1] = UPDATE_RESULT_SUCCESSFUL;
+ time_provider_status(&value[0], &value[1]);
+
attrib_db_update(a->handle, NULL, value, sizeof(value), NULL);

return 0;
@@ -179,11 +181,16 @@ static void register_reference_time_update_service(void)
int time_server_init(void)
{
register_current_time_service();
- register_reference_time_update_service();
+
+ if (time_provider_init() < 0)
+ DBG("error initializing time provider");
+ else
+ register_reference_time_update_service();

return 0;
}

void time_server_exit(void)
{
+ time_provider_exit();
}
diff --git a/time/server.h b/time/server.h
index 12b47ed..0e1f858 100644
--- a/time/server.h
+++ b/time/server.h
@@ -43,3 +43,11 @@ enum {

int time_server_init(void);
void time_server_exit(void);
+
+/* Time provider init and exit routines. Implemented by provider-*.c */
+int time_provider_init(void);
+void time_provider_exit(void);
+
+/* Time provider control and status routines. Implemented by provider-*.c */
+void time_provider_status(uint8_t *state, uint8_t *result);
+uint8_t time_provider_control(int op);
--
1.7.0.4


2011-12-02 18:34:06

by Anderson Lizardo

[permalink] [raw]
Subject: [PATCH RFC BlueZ 1/5] Time Profile: add Reference Time Update Service

Add support for the Reference Time Update Service (RTUS). From the spec:

"This service defines how a client can request an update from a
reference time source from a time server using the Generic Attribute
Profile (GATT)."
---
time/server.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++
time/server.h | 19 +++++++++++++++++++
2 files changed, 66 insertions(+), 0 deletions(-)

diff --git a/time/server.c b/time/server.c
index 5c32dc2..4958fd3 100644
--- a/time/server.c
+++ b/time/server.c
@@ -39,8 +39,11 @@
#include "server.h"

#define CURRENT_TIME_SVC_UUID 0x1805
+#define REF_TIME_UPDATE_SVC_UUID 0x1806

#define LOCAL_TIME_INFO_CHR_UUID 0x2A0F
+#define TIME_UPDATE_CTRL_CHR_UUID 0x2A16
+#define TIME_UPDATE_STAT_CHR_UUID 0x2A17
#define CT_TIME_CHR_UUID 0x2A2B

static int encode_current_time(uint8_t value[10])
@@ -130,9 +133,53 @@ static void register_current_time_service(void)
GATT_OPT_INVALID);
}

+static uint8_t time_update_control(struct attribute *a, gpointer user_data)
+{
+ DBG("handle 0x%04x", a->handle);
+
+ if (a->len != 1)
+ DBG("Invalid control point value size: %d", a->len);
+
+ return 0;
+}
+
+static uint8_t time_update_status(struct attribute *a, gpointer user_data)
+{
+ uint8_t value[2];
+
+ DBG("handle 0x%04x", a->handle);
+
+ value[0] = UPDATE_STATE_IDLE;
+ value[1] = UPDATE_RESULT_SUCCESSFUL;
+ attrib_db_update(a->handle, NULL, value, sizeof(value), NULL);
+
+ return 0;
+}
+
+static void register_reference_time_update_service(void)
+{
+ /* Reference Time Update service */
+ gatt_service_add(GATT_PRIM_SVC_UUID, REF_TIME_UPDATE_SVC_UUID,
+ /* Time Update control point */
+ GATT_OPT_CHR_UUID, TIME_UPDATE_CTRL_CHR_UUID,
+ GATT_OPT_CHR_PROPS,
+ ATT_CHAR_PROPER_WRITE_WITHOUT_RESP,
+ GATT_OPT_CHR_VALUE_CB, ATTRIB_WRITE,
+ time_update_control,
+
+ /* Time Update status */
+ GATT_OPT_CHR_UUID, TIME_UPDATE_STAT_CHR_UUID,
+ GATT_OPT_CHR_PROPS, ATT_CHAR_PROPER_READ,
+ GATT_OPT_CHR_VALUE_CB, ATTRIB_READ,
+ time_update_status,
+
+ GATT_OPT_INVALID);
+}
+
int time_server_init(void)
{
register_current_time_service();
+ register_reference_time_update_service();

return 0;
}
diff --git a/time/server.h b/time/server.h
index 621bf2b..12b47ed 100644
--- a/time/server.h
+++ b/time/server.h
@@ -22,5 +22,24 @@
*
*/

+enum {
+ UPDATE_RESULT_SUCCESSFUL = 0,
+ UPDATE_RESULT_CANCELED = 1,
+ UPDATE_RESULT_NO_CONN = 2,
+ UPDATE_RESULT_ERROR = 3,
+ UPDATE_RESULT_TIMEOUT = 4,
+ UPDATE_RESULT_NOT_ATTEMPTED = 5,
+};
+
+enum {
+ UPDATE_STATE_IDLE = 0,
+ UPDATE_STATE_PENDING = 1,
+};
+
+enum {
+ GET_REFERENCE_UPDATE = 1,
+ CANCEL_REFERENCE_UPDATE = 2,
+};
+
int time_server_init(void);
void time_server_exit(void);
--
1.7.0.4


2012-02-02 14:06:05

by Anderson Lizardo

[permalink] [raw]
Subject: Re: [PATCH RFC BlueZ 0/5] Time Profile (server) improvements

Hi Arik,

On Thu, Feb 2, 2012 at 9:32 AM, Arik Nemtsov <[email protected]> wrote:
> On Thu, Feb 2, 2012 at 15:07, Anderson Lizardo
> <[email protected]> wrote:
>> Hi Arik,
>>
>> On Thu, Feb 2, 2012 at 8:19 AM, Arik Nemtsov <[email protected]> wrote:
>>> Does this mean the server-application operating over D-Bus would be
>>> able to register read/write callbacks on specific attributes?
>>
>> Actually the API will be more high level, and hopefully Profile
>> agnostic, so it can be reused between profiles.
>
> Maybe you have some preliminary suggested documentation? It would be
> interesting to take a look

Sure, Claudio is "taking care" of this document, and will send you
soon for early comments. But we want to send to the list ASAP as well.
There is draft documents for PhoneAlert/AlertNotification as well.

>>> It would be nice to get a sense of the API soon. We're planning on
>>> implementing several GATT servers. Namely - ANS, PASS, IAS, LLS and
>>> TPS. This can obviously effect the design.
>>
>> It would be interesting for us to cooperate on this then. IAS/LLS/TPS
>> are implemented on BlueZ upstream already (check proximity/* files).
>
> It would indeed be nice to cooperate :)
> As for IAS/LLS/TPS - I think maybe a rewrite using the higher-level
> gatt_service_add() API is in order.

Indeed. Feel free to send patches for those :)

For Time/Phone Alert/Alert Notifications services, we will already
send using the gatt_service_add() API.

>
> For IAS/LLS the notification to an upper-level app is missing
> (something the new D-Bus API will probably address).

Correct. The Proximity Reporter API is already documented in
docs/proximity-api.txt, but needs to be implemented.

> For TPS,
> returning the RSSI is missing (in a read_cb).

I thinki this is on purpose. Are you aware that there is ongoing
discussions on BT SIG to avoid this "RSSI polling" altogether on
future Core spec revision? The plan is then to completely avoid
exposing this information at the moment because it may not be more
available on future revisions.

But feel free to send proposals on how to handle this. We may have
issues with too much polling and overhead if RSSI values are sent over
D-Bus too often.

>> ANS and PASS have skeleton code and initial implementation (which I
>> will send soon to the list once I clean it up) on my development tree
>> (warning: it is currently messy and outdated, and needs cleanup):
>>
>> git://gitorious.org/~lizardo/bluez/lizardo-bluez.git (branch
>> for-upstream-phone-alert)
>
> It seems I can't get to gitorious right now (seems to be some planned
> maintenance). I'll definitely take a look once I can.

Ok. As I said the code is messy, so I expect comments only for the
patches I'll send here :) But feel free to take a look.

>
> NDCS adds very little code. My main concern here is updating the
> DST-change time periodically from the server-app.
> Seems to me it's better to wait for your proposed skeleton implementations.

No problem. I agree the most tricky part will be on properly handle
notifications.

I plan to only handle the "easy" part now , so at least we can work
with Time clients which may want to interact with this service.

Best Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil

2012-02-02 13:32:01

by Arik Nemtsov

[permalink] [raw]
Subject: Re: [PATCH RFC BlueZ 0/5] Time Profile (server) improvements

On Thu, Feb 2, 2012 at 15:07, Anderson Lizardo
<[email protected]> wrote:
> Hi Arik,
>
> On Thu, Feb 2, 2012 at 8:19 AM, Arik Nemtsov <[email protected]> wrote:
>> Does this mean the server-application operating over D-Bus would be
>> able to register read/write callbacks on specific attributes?
>
> Actually the API will be more high level, and hopefully Profile
> agnostic, so it can be reused between profiles.

Maybe you have some preliminary suggested documentation? It would be
interesting to take a look

>
>> It would be nice to get a sense of the API soon. We're planning on
>> implementing several GATT servers. Namely - ANS, PASS, IAS, LLS and
>> TPS. This can obviously effect the design.
>
> It would be interesting for us to cooperate on this then. IAS/LLS/TPS
> are implemented on BlueZ upstream already (check proximity/* files).

It would indeed be nice to cooperate :)
As for IAS/LLS/TPS - I think maybe a rewrite using the higher-level
gatt_service_add() API is in order.

For IAS/LLS the notification to an upper-level app is missing
(something the new D-Bus API will probably address). For TPS,
returning the RSSI is missing (in a read_cb).

>
> ANS and PASS have skeleton code and initial implementation (which I
> will send soon to the list once I clean it up) on my development tree
> (warning: it is currently messy and outdated, and needs cleanup):
>
> git://gitorious.org/~lizardo/bluez/lizardo-bluez.git (branch
> for-upstream-phone-alert)

It seems I can't get to gitorious right now (seems to be some planned
maintenance). I'll definitely take a look once I can.

>
> Our current design is to have both ANS and PASS grouped into a
> altert/* directory.

Sounds good.

> I plan to send initial "dummy" implementations of NDCS and Local Time
> Information as well, but if you already have them implemented, feel
> free to send at least some RFC here.
>
> But you can extend with further functionality after we have the
> initial services upstream.

NDCS adds very little code. My main concern here is updating the
DST-change time periodically from the server-app.
Seems to me it's better to wait for your proposed skeleton implementations.

Regards,
Arik

2012-02-02 13:07:17

by Anderson Lizardo

[permalink] [raw]
Subject: Re: [PATCH RFC BlueZ 0/5] Time Profile (server) improvements

Hi Arik,

On Thu, Feb 2, 2012 at 8:19 AM, Arik Nemtsov <[email protected]> wrote:
> Does this mean the server-application operating over D-Bus would be
> able to register read/write callbacks on specific attributes?

Actually the API will be more high level, and hopefully Profile
agnostic, so it can be reused between profiles.

> It would be nice to get a sense of the API soon. We're planning on
> implementing several GATT servers. Namely - ANS, PASS, IAS, LLS and
> TPS. This can obviously effect the design.

It would be interesting for us to cooperate on this then. IAS/LLS/TPS
are implemented on BlueZ upstream already (check proximity/* files).

ANS and PASS have skeleton code and initial implementation (which I
will send soon to the list once I clean it up) on my development tree
(warning: it is currently messy and outdated, and needs cleanup):

git://gitorious.org/~lizardo/bluez/lizardo-bluez.git (branch
for-upstream-phone-alert)

Our current design is to have both ANS and PASS grouped into a
altert/* directory.

>> We will send a RFC for this Time Agent API real soon. Please comment :)
>
> Will do. I am interested in adding an implementation of an NDCS server
> to the BlueZ time server. It would be nice if you take this into
> account in the Time Agent API (updating the DST offset from D-Bus).
> The same is also required for the Local Time Information characteristic in CTS.

Indeed the Time Agent API is supposed to handle that as well.

I plan to send initial "dummy" implementations of NDCS and Local Time
Information as well, but if you already have them implemented, feel
free to send at least some RFC here.

But you can extend with further functionality after we have the
initial services upstream.

Best Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil

2012-02-02 12:19:37

by Arik Nemtsov

[permalink] [raw]
Subject: Re: [PATCH RFC BlueZ 0/5] Time Profile (server) improvements

On Thu, Feb 2, 2012 at 01:12, Anderson Lizardo
<[email protected]> wrote:
> Hi Arik,
>> This series looks good overall. Are you planning to go ahead with it
>> (with a non-RFC series)?
>
> Sure. This will happen in the very near future (at most next week).
> But for now we will drop the "providers" patches, because we are about
> to also send D-Bus API that implements the functionality externally.

Does this mean the server-application operating over D-Bus would be
able to register read/write callbacks on specific attributes?

It would be nice to get a sense of the API soon. We're planning on
implementing several GATT servers. Namely - ANS, PASS, IAS, LLS and
TPS. This can obviously effect the design.

>
> But even with the initial implementation, most Time clients will be
> supported just fine. They will just not be able to update the phone's
> own time or be notified of manual changes to the phone time (this will
> be supported with the D-Bus API).

Ok.

> We plan to have everything which was in "providers" implemented on
> external a Agent which communicates over D-Bus. This is necessary to
> avoid introducing extra dependency on BlueZ for each platform we may
> support.
>
> We will send a RFC for this Time Agent API real soon. Please comment :)

Will do. I am interested in adding an implementation of an NDCS server
to the BlueZ time server. It would be nice if you take this into
account in the Time Agent API (updating the DST offset from D-Bus).
The same is also required for the Local Time Information characteristic in CTS.

Regards,
Arik

2012-02-01 23:12:27

by Anderson Lizardo

[permalink] [raw]
Subject: Re: [PATCH RFC BlueZ 0/5] Time Profile (server) improvements

Hi Arik,

On Wed, Feb 1, 2012 at 6:48 PM, Arik Nemtsov <[email protected]> wrote:
> Hey Anderson,
>
> On Fri, Dec 2, 2011 at 20:34, Anderson Lizardo
> <[email protected]> wrote:
>> This series implements two new features for GATT Time Profile (server role):
>>
>> * Reference Time Update Service (RTUS), with two drivers (called "providers"
>> ?here): dummy (for testing) and timed (for N9/harmattan)
>> * Support for current time notifications
>
> This series looks good overall. Are you planning to go ahead with it
> (with a non-RFC series)?

Sure. This will happen in the very near future (at most next week).
But for now we will drop the "providers" patches, because we are about
to also send D-Bus API that implements the functionality externally.

But even with the initial implementation, most Time clients will be
supported just fine. They will just not be able to update the phone's
own time or be notified of manual changes to the phone time (this will
be supported with the D-Bus API).

>> We are aware of the current plan of moving platform specific code out of BlueZ
>> (to agents communicating over D-Bus). Is it feasible to be done now for GATT
>> servers as well?
>
> It seems this is handled well in your series. Or did you want to move
> some more functionality to D-Bus?

We plan to have everything which was in "providers" implemented on
external a Agent which communicates over D-Bus. This is necessary to
avoid introducing extra dependency on BlueZ for each platform we may
support.

We will send a RFC for this Time Agent API real soon. Please comment :)

Best Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil

2012-02-01 22:48:31

by Arik Nemtsov

[permalink] [raw]
Subject: Re: [PATCH RFC BlueZ 0/5] Time Profile (server) improvements

Hey Anderson,

On Fri, Dec 2, 2011 at 20:34, Anderson Lizardo
<[email protected]> wrote:
> This series implements two new features for GATT Time Profile (server role):
>
> * Reference Time Update Service (RTUS), with two drivers (called "providers"
> ?here): dummy (for testing) and timed (for N9/harmattan)
> * Support for current time notifications

This series looks good overall. Are you planning to go ahead with it
(with a non-RFC series)?

>
> We are aware of the current plan of moving platform specific code out of BlueZ
> (to agents communicating over D-Bus). Is it feasible to be done now for GATT
> servers as well?

It seems this is handled well in your series. Or did you want to move
some more functionality to D-Bus?

Regards,
Arik

2012-05-17 14:50:41

by Anderson Lizardo

[permalink] [raw]
Subject: Re: [PATCH RFC BlueZ 0/5] Time Profile (server) improvements

Hi Arun,

On Wed, May 16, 2012 at 7:40 AM, Arun K. Singh <[email protected]> wrote:
> Hi Anderson,
>
> On Thu, Feb 2, 2012 at 4:42 AM, Anderson Lizardo
> <[email protected]> wrote:
>
> <snip>
> ..
>
>> But even with the initial implementation, most Time clients will be
>> supported just fine. They will just not be able to update the phone's
>> own time or be notified of manual changes to the phone time (this will
>> be supported with the D-Bus API).
>
> Unless I missed such discussions on Time client support, could you
> comment on plans to support it. From what I figure is a time client
> will need to configure few things on the server such as notifying on
> time udpates/reference time etc. which may need dedicated API's. Do
> you have plans to support time client API's as well?

The current code (and the relevant discussion) is only related to Time
Server D-BUS API. It is needed so the platform specific stuff (e.g.
system clock update) can be done outside of BlueZ, by a Time "agent".

If you are interested on implementing Time Client support, you will
need to propose a separate API. I am not aware of anyone working on
client side support.

>
> Thanks,
> Arun

Best Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil

2012-05-16 11:40:44

by Arun K. Singh

[permalink] [raw]
Subject: Re: [PATCH RFC BlueZ 0/5] Time Profile (server) improvements

Hi Anderson,

On Thu, Feb 2, 2012 at 4:42 AM, Anderson Lizardo
<[email protected]> wrote:

<snip>
..

> But even with the initial implementation, most Time clients will be
> supported just fine. They will just not be able to update the phone's
> own time or be notified of manual changes to the phone time (this will
> be supported with the D-Bus API).

Unless I missed such discussions on Time client support, could you
comment on plans to support it. From what I figure is a time client
will need to configure few things on the server such as notifying on
time udpates/reference time etc. which may need dedicated API's. Do
you have plans to support time client API's as well?

Thanks,
Arun