* Re: a2dp, myth, pulse
From: Brad Midgley @ 2010-09-28 7:05 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <AANLkTingVh3OaAGQzsxWJQddqrPwgFssMeOq5Rp_DbS6@mail.gmail.com>
Hey
> can avrcp be used to drive mythtv? I've got a setup where the myth
> frontend is rarely the foreground app
So if avrcp were to present events in a /dev/input/eventX device, I
could use inputlircd to connect those events to lirc clients. It might
make it easier if a udev rule created something like /dev/input/avrcp0
so we could find it more easily for the inputlircd config.
And I see now that it is by virtue of the use of liblirc that myth can
get remote events even if it's not the foreground app.
Control is enabled by default in 4.60, is there anything I can check
to see why I don't see any log messages about avrcp, no input device
appear, nothing logged, etc? The main connection is initiated by the
headset and the audio connection is initiated by the computer. If I
remember tinkering with this stuff, bluez would need to initiate the
control connection in this case.
hcidump -X -V shows messages going across when I tap avrcp buttons...
> ACL data: handle 42 flags 0x02 dlen 12
L2CAP(d): cid 0x0043 len 8 [psm 0]
0000: a0 11 0e 00 48 7c 4b 00 ....H|K.
< ACL data: handle 42 flags 0x02 dlen 12
L2CAP(d): cid 0x0053 len 8 [psm 0]
0000: a2 11 0e 09 48 7c 4b 00 ....H|K.
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> HCI Event: Mode Change (0x14) plen 6
status 0x00 handle 42 mode 0x00 interval 0
Mode: Active
> ACL data: handle 42 flags 0x02 dlen 12
L2CAP(d): cid 0x0043 len 8 [psm 0]
0000: b0 11 0e 00 48 7c cb 00 ....H|..
< ACL data: handle 42 flags 0x02 dlen 12
L2CAP(d): cid 0x0053 len 8 [psm 0]
0000: b2 11 0e 09 48 7c cb 00 ....H|..
> HCI Event: Number of Completed Packets (0x13) plen 5
handle 42 packets 1
> HCI Event: Mode Change (0x14) plen 6
status 0x00 handle 42 mode 0x02 interval 200
Mode: Sniff
--
Brad Midgley
^ permalink raw reply
* Re: [PATCH] Fix headset disconnecting via device disconnect
From: Johan Hedberg @ 2010-09-28 7:47 UTC (permalink / raw)
To: Radoslaw Jablonski; +Cc: linux-bluetooth
In-Reply-To: <1285237951-4271-1-git-send-email-ext-jablonski.radoslaw@nokia.com>
Hi Radek,
On Thu, Sep 23, 2010, Radoslaw Jablonski wrote:
> Headsets for proper disconnecting need to disconnect profiles in specified
> order(by ex. disconnect a2dp, then sink and hfp at the end). Instead of
> adding separate callbacks for disconnecting each profile, now adding only
> one callback in audio/device.c for calling audio disconnect functions in
> correct order. New disconnect callback works similarly to dev_disconnect
> from audio/device.c
> ---
> audio/device.c | 138 +++++++++++++++++++++++++++++++++++++------------------
> audio/headset.c | 19 --------
> audio/sink.c | 29 ------------
> audio/source.c | 33 -------------
> 4 files changed, 93 insertions(+), 126 deletions(-)
Thanks for the patch. It has been pushed upstream with a couple of minor
modifications (which we already discussed offline):
> + }
> + else if (new_state == AUDIO_STATE_CONNECTED) {
> + priv->disconnecting = FALSE;
> + priv->dc_id = device_add_disconnect_watch(dev->btd_dev,
> + disconnect_cb, dev, NULL);
> + }
First of all, coding style: the else if goes on the same line as the {
Secondly, I don't see how disconnecting could be TRUE when going to
CONNECTED state so I removed setting it explicitly to FALSE here.
> + if (new_state == AUDIO_STATE_DISCONNECTED) {
> + if (priv->dc_req) {
> + reply = dbus_message_new_method_return(priv->dc_req);
> + dbus_message_unref(priv->dc_req);
> + priv->dc_req = NULL;
> + g_dbus_send_message(dev->conn, reply);
> + }
> + else if (priv->disconnecting)
> + priv->disconnecting = FALSE;
Again coding style with the else if, and setting the disconnecting flag
to FALSE can be unconditional here in my opinion.
Johan
^ permalink raw reply
* [PATCH] Fix not detecting errors when transferring the last part of the buffer
From: Luiz Augusto von Dentz @ 2010-09-28 7:52 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
The last part has to be flushed in order to sent the remaining buffer as
a obex packet and detect possible errors.
---
client/transfer.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/client/transfer.c b/client/transfer.c
index 58ac265..8ceb36f 100644
--- a/client/transfer.c
+++ b/client/transfer.c
@@ -379,8 +379,10 @@ static void put_xfer_progress(GwObexXfer *xfer, gpointer user_data)
transfer->filled += len;
- if (transfer->filled == 0)
+ if (transfer->filled == 0) {
+ gw_obex_xfer_flush(xfer, &err);
goto done;
+ }
if (gw_obex_xfer_write(xfer, transfer->buffer,
transfer->filled,
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] Fix problem with EIR data when setting the name
From: Johan Hedberg @ 2010-09-28 7:53 UTC (permalink / raw)
To: Lukasz Pawlik; +Cc: linux-bluetooth
In-Reply-To: <AANLkTi=6ORUZLTY28iHn4q6gAi1mMZjqb=Nt7B6zQN2R@mail.gmail.com>
Hi Lukasz,
On Thu, Sep 23, 2010, Lukasz Pawlik wrote:
> Subject: [PATCH] Fix problem with EIR data when setting the name
>
> Previously changed BT fiendly name was not reflected until BT adapter reboot.
> This patch fix this problem. Now changed name is reflected without need of
> rebooting adapter.
> ---
> src/adapter.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/src/adapter.c b/src/adapter.c
> index 9b638cf..0e9be5f 100644
> --- a/src/adapter.c
> +++ b/src/adapter.c
> @@ -1031,6 +1031,7 @@ static DBusMessage *set_name(DBusConnection *conn, DBusMessage *msg,
> return failed_strerror(msg, err);
>
> adapter->name_stored = TRUE;
> + update_ext_inquiry_response(adapter);
> }
>
> done:
Thanks for the patch. It has now been pushed upstream.
Johan
^ permalink raw reply
* Re: [PATCH] Fix not detecting errors when transferring the last part of the buffer
From: Johan Hedberg @ 2010-09-28 8:10 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1285660345-1819-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Tue, Sep 28, 2010, Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
>
> The last part has to be flushed in order to sent the remaining buffer as
> a obex packet and detect possible errors.
> ---
> client/transfer.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
Thanks. The patch has been pushed upstream.
Johan
^ permalink raw reply
* Re: Spurious authentication request?
From: Johan Hedberg @ 2010-09-28 8:15 UTC (permalink / raw)
To: Daniel Örstadius; +Cc: linux-bluetooth
In-Reply-To: <AANLkTikrQ2fAHDZwMncOpNRadjm=tdobvDoas=v5eyxH@mail.gmail.com>
Hi Daniel,
On Mon, Sep 27, 2010, Daniel Örstadius wrote:
> Occasionally when pairing with a headset BlueZ issues what looks
> to be an unnecessary "Authentication Requested" after
> receiving "Auth Complete" and "Simple Pairing Complete".
>
> 2010-09-22 11:23:45.282348 > HCI Event: Auth Complete (0x06) plen 3
> status 0x00 handle 2
> 2010-09-22 11:23:45.282378 < HCI Command: Set Connection Encryption
> (0x01|0x0013) plen 3
> handle 2 encrypt 0x01
> [..]
> 2010-09-22 11:23:45.363646 < HCI Command: Authentication Requested
> (0x01|0x0011) plen 2
> handle 2
>
> This request is coming from bonding_connect_cb and occurs if that
> callback happens to be executed before the function
> hcid_dbus_bonding_process_complete (triggered by the auth complete
> event). The order between those functions might have been affected
> by this patch
>
> http://git.kernel.org/?p=bluetooth/bluez.git;a=commit;h=be35d00671519b8d92361c2caad9abeedda151f8
>
> The request for authentication seems to be used for legacy pairing and
> should probably not be made for simple pairing. Also, it might be
> inconsistent that the kernel issues "Authentication Requested" for
> simple pairing, but bluetoothd does it for legacy?
>
> I guess enclosing the call in a check for legacy pairing would
> work, if that information is or can be made available to
> bluetoothd.
>
> Have I understood the situation correctly and if so, what would
> be a good way to fix this issue?
The reason why the extra authentication request is there is to deal with
old kernels that do not initiate authentication by themselves. So
checking for SSP vs legacy pairing wouldn't work.
Johan
^ permalink raw reply
* Re: [PATCH 6/6] This patch adds support for using the ST-Ericsson CG2900
From: Par-Gunnar Hjalmdahl @ 2010-09-28 9:14 UTC (permalink / raw)
To: Gustavo F. Padovan
Cc: linux-bluetooth, linux-kernel, linus.walleij, Pavan Savoy
In-Reply-To: <20100927164502.GB30310@vigoh>
Hi Gustavo,
Thanks for your comments. See below for answers.
/P-G
2010/9/27 Gustavo F. Padovan <padovan@profusion.mobi>:
> Hi Par-Gunnar,
>
> * Par-Gunnar Hjalmdahl <par-gunnar.p.hjalmdahl@stericsson.com> [2010-09-24 15:52:16 +0200]:
>
>> This patch adds support for using the ST-Ericsson CG2900
>> connectivity controller as a driver for the BlueZ Bluetooth
>> stack.
>> This patch registers as a driver into the BlueZ framework and, when
>> opened by BlueZ, it registers as user for bt_cmd, bt_acl, and bt_evt
>> channels.
>
> First of all your your commit message and subject should be improved.
> The subject should bee something like:
>
> "Bluetooth: Add support for ST-Ericsson CG2900"
>
> and in the commit message you explain the details of the patch.
> And normally we do not use the BlueZ word in kernelspace.
>
OK. This is the first patch I've created within the community and of
course there are bound to be errors... ;-)
Since it was part of a big patch delivery I used quite similar names
across the different patches and I understand that this is an error
since the different patches are targeting different communities.
>>
>> Signed-off-by: Par-Gunnar Hjalmdahl <par-gunnar.p.hjalmdahl@stericsson.com>
>> ---
>> drivers/bluetooth/Kconfig | 7 +
>> drivers/bluetooth/Makefile | 2 +
>> drivers/bluetooth/cg2900_hci.c | 896 ++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 905 insertions(+), 0 deletions(-)
>> create mode 100644 drivers/bluetooth/cg2900_hci.c
>
> Your patch looks a way complicated to a UART driver. Look at the others
> drivers at drivers/bluetooth/ and see how we implemented other UART
> drivers.
>
Well, mainly that's because it is not a UART driver. It is a driver
against CG2900 which currently have only UART as transport but quite
soon will get SPI as transport as well. For this Bluetooth driver the
actual physical transport used is not known. It just knows it has a
reliable transport below which delivers complete Bluetooth packets.
>>
>> diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
>> index 02deef4..9ca8d69 100644
>> --- a/drivers/bluetooth/Kconfig
>> +++ b/drivers/bluetooth/Kconfig
>> @@ -219,4 +219,11 @@ config BT_ATH3K
>> Say Y here to compile support for "Atheros firmware download driver"
>> into the kernel or say M to compile it as module (ath3k).
>>
>> +config BT_CG2900
>> + tristate "ST-Ericsson CG2900 driver"
>> + depends on MFD_CG2900 && BT
>> + help
>> + Select if ST-Ericsson CG2900 Connectivity controller shall be used as
>> + Bluetooth controller for BlueZ.
>> +
>> endmenu
>> diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
>> index 71bdf13..a479c16 100644
>> --- a/drivers/bluetooth/Makefile
>> +++ b/drivers/bluetooth/Makefile
>> @@ -19,6 +19,8 @@ obj-$(CONFIG_BT_ATH3K) += ath3k.o
>> obj-$(CONFIG_BT_MRVL) += btmrvl.o
>> obj-$(CONFIG_BT_MRVL_SDIO) += btmrvl_sdio.o
>>
>> +obj-$(CONFIG_BT_CG2900) += cg2900_hci.o
>> +
>> btmrvl-y := btmrvl_main.o
>> btmrvl-$(CONFIG_DEBUG_FS) += btmrvl_debugfs.o
>>
>> diff --git a/drivers/bluetooth/cg2900_hci.c b/drivers/bluetooth/cg2900_hci.c
>> new file mode 100644
>> index 0000000..de1ada8
>> --- /dev/null
>> +++ b/drivers/bluetooth/cg2900_hci.c
>> @@ -0,0 +1,896 @@
>> +/*
>> + * drivers/bluetooth/cg2900_hci.c
>> + *
>> + * Copyright (C) ST-Ericsson SA 2010
>> + * Authors:
>> + * Par-Gunnar Hjalmdahl (par-gunnar.p.hjalmdahl@stericsson.com) for
>> ST-Ericsson.
>> + * Henrik Possung (henrik.possung@stericsson.com) for ST-Ericsson.
>> + * Josef Kindberg (josef.kindberg@stericsson.com) for ST-Ericsson.
>> + * Dariusz Szymszak (dariusz.xd.szymczak@stericsson.com) for ST-Ericsson.
>> + * Kjell Andersson (kjell.k.andersson@stericsson.com) for ST-Ericsson.
>> + * License terms: GNU General Public License (GPL), version 2
>> + *
>> + * Linux Bluetooth HCI H:4 Driver for ST-Ericsson CG2900 connectivity
>> controller
>> + * towards the BlueZ Bluetooth stack.
>> + */
>> +
>> +#include <linux/module.h>
>> +#include <linux/types.h>
>> +#include <linux/skbuff.h>
>> +#include <asm/byteorder.h>
>> +#include <net/bluetooth/bluetooth.h>
>> +#include <net/bluetooth/hci.h>
>> +#include <net/bluetooth/hci_core.h>
>> +
>> +#include <linux/workqueue.h>
>> +#include <linux/wait.h>
>> +#include <linux/time.h>
>> +#include <linux/jiffies.h>
>> +#include <linux/sched.h>
>> +#include <linux/timer.h>
>> +
>> +#include <linux/mfd/cg2900.h>
>> +#include <mach/cg2900_devices.h>
>> +
>> +/* module_param declared in cg2900_core.c */
>> +extern int cg2900_debug_level;
>
> You don't need that, just use dynamic debug instead
>
Regarding the debug we know we have made an debug implementation that
might be controversial. We have used defines to output debug at
different levels and a module param to control the debug level in
runtime. I know that rest of the Kernel use other ways for debug and
if our way is not accepted we will of course modify the debug in the
driver to use standard Kernel methods.
I personally prefer to use defines because it makes it easy to add a
file name or similar at the start of the printout and also always use
'\n' in the end of each debug line. But if you don't like it that way
we will of course change that as well.
>> +
>> +#define NAME "CG2900 HCI"
>> +
>> +/* Debug defines */
>> +#define CG2900_DBG_DATA(fmt, arg...) \
>> +do { \
>> + if (cg2900_debug_level >= 25) \
>> + printk(KERN_DEBUG NAME " %s: " fmt "\n" , __func__ , ## arg); \
>> +} while (0)
>> +
>> +#define CG2900_DBG(fmt, arg...) \
>> +do { \
>> + if (cg2900_debug_level >= 20) \
>> + printk(KERN_DEBUG NAME " %s: " fmt "\n" , __func__ , ## arg); \
>> +} while (0)
>> +
>> +#define CG2900_INFO(fmt, arg...) \
>> +do { \
>> + if (cg2900_debug_level >= 10) \
>> + printk(KERN_INFO NAME ": " fmt "\n" , ## arg); \
>> +} while (0)
>> +
>> +#define CG2900_ERR(fmt, arg...) \
>> +do { \
>> + if (cg2900_debug_level >= 1) \
>> + printk(KERN_ERR NAME " %s: " fmt "\n" , __func__ , ## arg); \
>> +} while (0)i
>
> and BT_DBG, BT_INFO, BT_ERR instead of these macros.
OK.
>
>> +
>> +#define CG2900_SET_STATE(__name, __var, __new_state) \
>> +do { \
>> + CG2900_DBG("New %s: 0x%X", __name, (uint32_t)__new_state); \
>> + __var = __new_state; \
>> +} while (0)
>
> Don't hide your operation with a macro, that is a simple attribution, so
> no need for a macro for that.
>
OK. I prefer to be able to get a printout 'automatically' every time
state is changed, but it is no big issue to do this directly in the
code instead.
>> +
>> +/* HCI device type */
>> +#define HCI_CG2900 HCI_VIRTUAL
>> +
>> +/* Wait for 5 seconds for a response to our requests */
>> +#define RESP_TIMEOUT 5000
>> +
>> +/* State-setting defines */
>> +#define SET_RESET_STATE(__hci_reset_new_state) \
>> + CG2900_SET_STATE("reset_state", hci_info->reset_state, \
>> + __hci_reset_new_state)
>> +#define SET_ENABLE_STATE(__hci_enable_new_state) \
>> + CG2900_SET_STATE("enable_state", hci_info->enable_state, \
>> + __hci_enable_new_state)
>
> Same here.
>
OK.
> --
> Gustavo F. Padovan
> ProFUSION embedded systems - http://profusion.mobi
>
^ permalink raw reply
* [PATCH] Add checking for agent reply state in adapter
From: Radoslaw Jablonski @ 2010-09-28 9:17 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Radoslaw Jablonski
Added checking for agent reply state before cancelling agent in
session_free(..). This check is needed to ensure that memory for
agent request will be freed only once (In that case, free on this
request is called later in the end of agent_reply func)
---
src/adapter.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index 0e9be5f..c122f82 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -82,6 +82,7 @@ struct session_req {
guint id; /* Listener id */
uint8_t mode; /* Requested mode */
int refcount; /* Session refcount */
+ gboolean is_reply; /* Agent reply is present */
};
struct service_auth {
@@ -757,7 +758,9 @@ static void session_free(struct session_req *req)
if (req->msg) {
dbus_message_unref(req->msg);
- if (req->mode && req->adapter->agent)
+ /* if initial reply is present, we shouldn't cancel agent,
+ * because it will be done later in agent_reply function */
+ if (!req->is_reply && req->mode && req->adapter->agent)
agent_cancel(req->adapter->agent);
}
@@ -794,6 +797,7 @@ static void confirm_mode_cb(struct agent *agent, DBusError *derr, void *data)
int err;
DBusMessage *reply;
+ req->is_reply = TRUE;
if (derr && dbus_error_is_set(derr)) {
reply = dbus_message_new_error(req->msg, derr->name,
derr->message);
--
1.7.0.4
^ permalink raw reply related
* How to send stream via obexd without ending request
From: Lukasz Pawlik @ 2010-09-28 10:14 UTC (permalink / raw)
To: linux-bluetooth
Hi,
I want to stream data immediately after they appear and wait for next
part. So far I didn't manage to find a way how to do this properly.
Returning error EAGAIN from my read function leads to canceling request
and this is something I don't want to do. The other way I was able to
find is returning value > 0 from read function until last part of data
appear. Obexd will stream data when buffer exceed allocated memory chunk
and return to read more data. This is no solution because it forces
obexd to send empty streams. Does anyone knows how to solve this problem ?
--
Łukasz Pawlik
^ permalink raw reply
* [PATCH 1/6] Changing default type of call from call log
From: Rafał Michalski @ 2010-09-28 10:56 UTC (permalink / raw)
To: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: 0001-Changing-default-type-of-call-from-call-log.patch --]
[-- Type: text/x-patch, Size: 11078 bytes --]
From e93ee56b1322c4fbf37885b99bc4e976b760b12d Mon Sep 17 00:00:00 2001
From: Rafal Michalski <michalski.raf@gmail.com>
Date: Tue, 28 Sep 2010 11:03:22 +0200
Subject: [PATCH 1/6] Changing default type of call from call log
Previously after downloading call log all calls had HOME type as default.
Now this type is OTHER - it will be used when connection is made
with number which is out of phonebook. To solve this issue extending
number of columns and queries of database was needed especially
(one field in database query was added).
---
plugins/phonebook-tracker.c | 140 ++++++++++++-------------------------------
plugins/vcard.c | 4 +-
2 files changed, 40 insertions(+), 104 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 3161927..5aaa9a8 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -43,16 +43,17 @@
#define TRACKER_RESOURCES_INTERFACE "org.freedesktop.Tracker1.Resources"
#define TRACKER_DEFAULT_CONTACT_ME "http://www.semanticdesktop.org/ontologies/2007/03/22/nco#default-contact-me"
-#define CONTACTS_ID_COL 37
-#define PULL_QUERY_COL_AMOUNT 38
+#define CONTACTS_ID_COL 38
+#define PULL_QUERY_COL_AMOUNT 39
#define COL_HOME_NUMBER 0
#define COL_HOME_EMAIL 7
#define COL_WORK_NUMBER 8
#define COL_FAX_NUMBER 16
#define COL_WORK_EMAIL 17
-#define COL_DATE 34
-#define COL_SENT 35
-#define COL_ANSWERED 36
+#define COL_OTHER_NUMBER 34
+#define COL_DATE 35
+#define COL_SENT 36
+#define COL_ANSWERED 37
#define ADDR_FIELD_AMOUNT 7
#define CONTACTS_QUERY_ALL \
@@ -68,7 +69,8 @@
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(?c) " \
- "nco:title(?a) \"NOTACALL\" \"false\" \"false\" ?c " \
+ "nco:title(?a) nco:phoneNumber(?t) " \
+ "\"NOTACALL\" \"false\" \"false\" ?c " \
"WHERE { " \
"?c a nco:PersonContact . " \
"OPTIONAL { ?c nco:hasPhoneNumber ?h . \
@@ -113,35 +115,21 @@
"nco:nameHonorificSuffix(?c) nco:emailAddress(?e) " \
"nco:phoneNumber(?w) nco:pobox(?p) nco:extendedAddress(?p) " \
"nco:streetAddress(?p) nco:locality(?p) nco:region(?p) " \
- "nco:postalcode(?p) nco:country(?p) ?f nco:emailAddress(?ew) " \
+ "nco:postalcode(?p) nco:country(?p) \"\" nco:emailAddress(?ew) "\
"nco:birthDate(?c) nco:nickname(?c) nco:websiteUrl(?c) " \
"nco:photo(?c) nco:fullname(?o) nco:department(?a) " \
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(?c) " \
- "nco:title(?a) nmo:receivedDate(?call) " \
- "nmo:isSent(?call) nmo:isAnswered(?call) ?c " \
+ "nco:title(?a) nco:phoneNumber(?t) nmo:receivedDate(?call) " \
+ "nmo:isSent(?call) nmo:isAnswered(?call) ?x " \
"WHERE { " \
+ "?x a nco:Contact . " \
+ "?x nco:hasPhoneNumber ?t . " \
"?call a nmo:Call ; " \
- "nmo:from ?c ; " \
+ "nmo:from ?x ; " \
"nmo:isSent false ; " \
"nmo:isAnswered false ." \
- "?c a nco:Contact . " \
- "OPTIONAL { ?c nco:hasPhoneNumber ?h . " \
- "OPTIONAL {" \
- "?h a nco:FaxNumber ; " \
- "nco:phoneNumber ?f . " \
- "}" \
- "} " \
- "OPTIONAL { ?c nco:hasEmailAddress ?e . } " \
- "OPTIONAL { ?c nco:hasPostalAddress ?p . } " \
- "OPTIONAL { " \
- "?c nco:hasAffiliation ?a . " \
- "OPTIONAL { ?a nco:hasPhoneNumber ?w . } " \
- "OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
- "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
- "OPTIONAL { ?a nco:org ?o . } " \
- "} " \
"} ORDER BY DESC(nmo:receivedDate(?call))"
#define MISSED_CALLS_LIST \
@@ -165,35 +153,21 @@
"nco:nameHonorificSuffix(?c) nco:emailAddress(?e) " \
"nco:phoneNumber(?w) nco:pobox(?p) nco:extendedAddress(?p) " \
"nco:streetAddress(?p) nco:locality(?p) nco:region(?p) " \
- "nco:postalcode(?p) nco:country(?p) ?f nco:emailAddress(?ew) " \
+ "nco:postalcode(?p) nco:country(?p) \"\" nco:emailAddress(?ew) "\
"nco:birthDate(?c) nco:nickname(?c) nco:websiteUrl(?c) " \
"nco:photo(?c) nco:fullname(?o) nco:department(?a) " \
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(?c) " \
- "nco:title(?a) nmo:receivedDate(?call) " \
- "nmo:isSent(?call) nmo:isAnswered(?call) ?c " \
+ "nco:title(?a) nco:phoneNumber(?t) nmo:receivedDate(?call) " \
+ "nmo:isSent(?call) nmo:isAnswered(?call) ?x " \
"WHERE { " \
+ "?x a nco:Contact . " \
+ "?x nco:hasPhoneNumber ?t . " \
"?call a nmo:Call ; " \
- "nmo:from ?c ; " \
+ "nmo:from ?x ; " \
"nmo:isSent false ; " \
"nmo:isAnswered true ." \
- "?c a nco:Contact . " \
- "OPTIONAL { ?c nco:hasPhoneNumber ?h . " \
- "OPTIONAL {" \
- "?h a nco:FaxNumber ; " \
- "nco:phoneNumber ?f . " \
- "}" \
- "} " \
- "OPTIONAL { ?c nco:hasEmailAddress ?e . } " \
- "OPTIONAL { ?c nco:hasPostalAddress ?p . } " \
- "OPTIONAL { " \
- "?c nco:hasAffiliation ?a . " \
- "OPTIONAL { ?a nco:hasPhoneNumber ?w . } " \
- "OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
- "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
- "OPTIONAL { ?a nco:org ?o . } " \
- "} " \
"} ORDER BY DESC(nmo:receivedDate(?call))"
#define INCOMING_CALLS_LIST \
@@ -217,34 +191,20 @@
"nco:nameHonorificSuffix(?c) nco:emailAddress(?e) " \
"nco:phoneNumber(?w) nco:pobox(?p) nco:extendedAddress(?p) " \
"nco:streetAddress(?p) nco:locality(?p) nco:region(?p) " \
- "nco:postalcode(?p) nco:country(?p) ?f nco:emailAddress(?ew)" \
+ "nco:postalcode(?p) nco:country(?p) \"\" nco:emailAddress(?ew)" \
"nco:birthDate(?c) nco:nickname(?c) nco:websiteUrl(?c) " \
"nco:photo(?c) nco:fullname(?o) nco:department(?a) " \
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(?c) " \
- "nco:title(?a) nmo:receivedDate(?call) " \
- "nmo:isSent(?call) nmo:isAnswered(?call) ?c " \
+ "nco:title(?a) nco:phoneNumber(?t) nmo:receivedDate(?call) " \
+ "nmo:isSent(?call) nmo:isAnswered(?call) ?x " \
"WHERE { " \
+ "?x a nco:Contact . " \
+ "?x nco:hasPhoneNumber ?t . " \
"?call a nmo:Call ; " \
- "nmo:to ?c ; " \
+ "nmo:to ?x ; " \
"nmo:isSent true . " \
- "?c a nco:Contact . " \
- "OPTIONAL { ?c nco:hasPhoneNumber ?h . " \
- "OPTIONAL {" \
- "?h a nco:FaxNumber ; " \
- "nco:phoneNumber ?f . " \
- "}" \
- "} " \
- "OPTIONAL { ?c nco:hasEmailAddress ?e . } " \
- "OPTIONAL { ?c nco:hasPostalAddress ?p . } " \
- "OPTIONAL { " \
- "?c nco:hasAffiliation ?a . " \
- "OPTIONAL { ?a nco:hasPhoneNumber ?w . } " \
- "OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
- "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
- "OPTIONAL { ?a nco:org ?o . } " \
- "} " \
"} ORDER BY DESC(nmo:sentDate(?call))"
#define OUTGOING_CALLS_LIST \
@@ -267,53 +227,27 @@
"nco:nameHonorificSuffix(?c) nco:emailAddress(?e) " \
"nco:phoneNumber(?w) nco:pobox(?p) nco:extendedAddress(?p) " \
"nco:streetAddress(?p) nco:locality(?p) nco:region(?p) " \
- "nco:postalcode(?p) nco:country(?p) ?f nco:emailAddress(?ew) " \
+ "nco:postalcode(?p) nco:country(?p) \"\" nco:emailAddress(?ew) "\
"nco:birthDate(?c) nco:nickname(?c) nco:websiteUrl(?c) " \
"nco:photo(?c) nco:fullname(?o) nco:department(?a) " \
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(?c) " \
- "nco:title(?a) nmo:receivedDate(?call) " \
- "nmo:isSent(?call) nmo:isAnswered(?call) ?c " \
+ "nco:title(?a) nco:phoneNumber(?t) nmo:receivedDate(?call) " \
+ "nmo:isSent(?call) nmo:isAnswered(?call) ?x " \
"WHERE { " \
"{ " \
+ "?x a nco:Contact . " \
+ "?x nco:hasPhoneNumber ?t . " \
"?call a nmo:Call ; " \
- "nmo:to ?c ; " \
+ "nmo:to ?x ; " \
"nmo:isSent true . " \
- "?c a nco:Contact . " \
- "OPTIONAL { ?c nco:hasPhoneNumber ?h . " \
- "OPTIONAL {" \
- "?h a nco:FaxNumber ; " \
- "nco:phoneNumber ?f . " \
- "}" \
- "} " \
- "OPTIONAL { ?c nco:hasEmailAddress ?e . } " \
- "OPTIONAL { ?c nco:hasPostalAddress ?p . } " \
- "OPTIONAL { ?c nco:hasAffiliation ?a . " \
- "OPTIONAL { ?a nco:hasPhoneNumber ?w . } " \
- "OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
- "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
- "OPTIONAL { ?a nco:org ?o . } " \
- "} " \
"} UNION { " \
+ "?x a nco:Contact . " \
+ "?x nco:hasPhoneNumber ?t . " \
"?call a nmo:Call ; " \
- "nmo:from ?c ; " \
+ "nmo:from ?x ; " \
"nmo:isSent false . " \
- "?c a nco:Contact . " \
- "OPTIONAL { ?c nco:hasPhoneNumber ?h . " \
- "OPTIONAL {" \
- "?h a nco:FaxNumber ; " \
- "nco:phoneNumber ?f . " \
- "}" \
- "} " \
- "OPTIONAL { ?c nco:hasEmailAddress ?e . } " \
- "OPTIONAL { ?c nco:hasPostalAddress ?p . } " \
- "OPTIONAL { ?c nco:hasAffiliation ?a . " \
- "OPTIONAL { ?a nco:hasPhoneNumber ?w . } " \
- "OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
- "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
- "OPTIONAL { ?a nco:org ?o . } " \
- "} " \
"} } ORDER BY DESC(nmo:receivedDate(?call))"
#define COMBINED_CALLS_LIST \
@@ -349,7 +283,8 @@
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(<%s>) " \
- "nco:title(?a) \"NOTACALL\" \"false\" \"false\" <%s> " \
+ "nco:title(?a) nco:phoneNumber(?t) " \
+ "\"NOTACALL\" \"false\" \"false\" <%s> " \
"WHERE { " \
"<%s> a nco:Contact . " \
"OPTIONAL { <%s> nco:hasPhoneNumber ?h . \
@@ -875,6 +810,7 @@ add_numbers:
add_phone_number(contact, reply[COL_HOME_NUMBER], TEL_TYPE_HOME);
add_phone_number(contact, reply[COL_WORK_NUMBER], TEL_TYPE_WORK);
add_phone_number(contact, reply[COL_FAX_NUMBER], TEL_TYPE_FAX);
+ add_phone_number(contact, reply[COL_OTHER_NUMBER], TEL_TYPE_OTHER);
/* Adding emails */
add_email(contact, reply[COL_HOME_EMAIL], EMAIL_TYPE_HOME);
diff --git a/plugins/vcard.c b/plugins/vcard.c
index bc22177..c720954 100644
--- a/plugins/vcard.c
+++ b/plugins/vcard.c
@@ -241,9 +241,9 @@ static void vcard_printf_number(GString *vcards, uint8_t format,
break;
case TEL_TYPE_OTHER:
if (format == FORMAT_VCARD21)
- category_string = "VOICE";
+ category_string = "OTHER;VOICE";
else if (format == FORMAT_VCARD30)
- category_string = "TYPE=VOICE";
+ category_string = "TYPE=OTHER;TYPE=VOICE";
break;
}
--
1.6.3.3
^ permalink raw reply related
* [PATCH 2/6] Binding mch call log with phonebook
From: Rafał Michalski @ 2010-09-28 10:59 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Rafał Michalski
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: 0002-Binding-mch-call-log-with-phonebook.patch --]
[-- Type: text/x-patch, Size: 2437 bytes --]
From e5a8c8ae9923fefc358f7e9e9a1ba88f30ed4662 Mon Sep 17 00:00:00 2001
From: Rafal Michalski <michalski.raf@gmail.com>
Date: Tue, 28 Sep 2010 11:04:21 +0200
Subject: [PATCH 2/6] Binding mch call log with phonebook
After missed call is done by number from phonebook then missed call
history will be shown with data about caller - downloaded in vCard
structure.
---
plugins/phonebook-tracker.c | 38 ++++++++++++++++++++++++++++++++++++--
1 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 5aaa9a8..faa3281 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -124,13 +124,47 @@
"nco:title(?a) nco:phoneNumber(?t) nmo:receivedDate(?call) " \
"nmo:isSent(?call) nmo:isAnswered(?call) ?x " \
"WHERE { " \
+ "{ " \
+ "?x a nco:Contact . " \
+ "?x nco:hasPhoneNumber ?h . " \
+ "?call a nmo:Call ; " \
+ "nmo:from ?x ; " \
+ "nmo:isSent false ; " \
+ "nmo:isAnswered false . " \
+ "?c a nco:PersonContact . " \
+ "?c nco:hasPhoneNumber ?h . " \
+ "OPTIONAL { ?c nco:hasEmailAddress ?e . } " \
+ "OPTIONAL { ?c nco:hasPostalAddress ?p . } " \
+ "OPTIONAL { " \
+ "?c nco:hasAffiliation ?a . " \
+ "OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
+ "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
+ "OPTIONAL { ?a nco:org ?o . } " \
+ "} " \
+ "} UNION { " \
+ "?x a nco:Contact . " \
+ "?x nco:hasPhoneNumber ?w . " \
+ "?call a nmo:Call ; " \
+ "nmo:from ?x ; " \
+ "nmo:isSent false ; " \
+ "nmo:isAnswered false . " \
+ "?c a nco:PersonContact . " \
+ "OPTIONAL { ?c nco:hasEmailAddress ?e . } " \
+ "OPTIONAL { ?c nco:hasPostalAddress ?p . } " \
+ "?c nco:hasAffiliation ?a . " \
+ "?a nco:hasPhoneNumber ?w . " \
+ "OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
+ "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
+ "OPTIONAL { ?a nco:org ?o . } " \
+ "} UNION { " \
"?x a nco:Contact . " \
"?x nco:hasPhoneNumber ?t . " \
"?call a nmo:Call ; " \
"nmo:from ?x ; " \
"nmo:isSent false ; " \
- "nmo:isAnswered false ." \
- "} ORDER BY DESC(nmo:receivedDate(?call))"
+ "nmo:isAnswered false . " \
+ "} " \
+ "} ORDER BY DESC(nmo:receivedDate(?call)) "
#define MISSED_CALLS_LIST \
"SELECT ?c nco:nameFamily(?c) " \
--
1.6.3.3
^ permalink raw reply related
* [PATCH 3/6] Binding ich call log with phonebook
From: Rafał Michalski @ 2010-09-28 11:01 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Rafał Michalski
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: 0003-Binding-ich-call-log-with-phonebook.patch --]
[-- Type: text/x-patch, Size: 2440 bytes --]
From d54b95be067fad58674730c5dee78f413ea3ae5e Mon Sep 17 00:00:00 2001
From: Rafal Michalski <michalski.raf@gmail.com>
Date: Tue, 28 Sep 2010 11:05:12 +0200
Subject: [PATCH 3/6] Binding ich call log with phonebook
After incoming call is done by number from phonebook then incoming call
history will be shown with data about caller - downloaded in vCard
structure.
---
plugins/phonebook-tracker.c | 38 ++++++++++++++++++++++++++++++++++++--
1 files changed, 36 insertions(+), 2 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index faa3281..50b2896 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -196,13 +196,47 @@
"nco:title(?a) nco:phoneNumber(?t) nmo:receivedDate(?call) " \
"nmo:isSent(?call) nmo:isAnswered(?call) ?x " \
"WHERE { " \
+ "{ " \
+ "?x a nco:Contact . " \
+ "?x nco:hasPhoneNumber ?h . " \
+ "?call a nmo:Call ; " \
+ "nmo:from ?x ; " \
+ "nmo:isSent false ; " \
+ "nmo:isAnswered true . " \
+ "?c a nco:PersonContact . " \
+ "?c nco:hasPhoneNumber ?h . " \
+ "OPTIONAL { ?c nco:hasEmailAddress ?e . } " \
+ "OPTIONAL { ?c nco:hasPostalAddress ?p . } " \
+ "OPTIONAL { " \
+ "?c nco:hasAffiliation ?a . " \
+ "OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
+ "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
+ "OPTIONAL { ?a nco:org ?o . } " \
+ "} " \
+ "} UNION { " \
+ "?x a nco:Contact . " \
+ "?x nco:hasPhoneNumber ?w . " \
+ "?call a nmo:Call ; " \
+ "nmo:from ?x ; " \
+ "nmo:isSent false ; " \
+ "nmo:isAnswered true . " \
+ "?c a nco:PersonContact . " \
+ "OPTIONAL { ?c nco:hasEmailAddress ?e . } " \
+ "OPTIONAL { ?c nco:hasPostalAddress ?p . } " \
+ "?c nco:hasAffiliation ?a . " \
+ "?a nco:hasPhoneNumber ?w . " \
+ "OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
+ "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
+ "OPTIONAL { ?a nco:org ?o . } " \
+ "} UNION { " \
"?x a nco:Contact . " \
"?x nco:hasPhoneNumber ?t . " \
"?call a nmo:Call ; " \
"nmo:from ?x ; " \
"nmo:isSent false ; " \
- "nmo:isAnswered true ." \
- "} ORDER BY DESC(nmo:receivedDate(?call))"
+ "nmo:isAnswered true . " \
+ "} " \
+ "} ORDER BY DESC(nmo:receivedDate(?call)) "
#define INCOMING_CALLS_LIST \
"SELECT ?c nco:nameFamily(?c) " \
--
1.6.3.3
^ permalink raw reply related
* [PATCH 4/6] Binding och call log with phonebook
From: Rafał Michalski @ 2010-09-28 11:02 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Rafał Michalski
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: 0004-Binding-och-call-log-with-phonebook.patch --]
[-- Type: text/x-patch, Size: 2290 bytes --]
From 08079d74cd123ae62e250425ec46496e23635e55 Mon Sep 17 00:00:00 2001
From: Rafal Michalski <michalski.raf@gmail.com>
Date: Tue, 28 Sep 2010 11:05:52 +0200
Subject: [PATCH 4/6] Binding och call log with phonebook
After outgoing call is done to number from phonebook then outgoing call
history will be shown with data about caller - downloaded in vCard
structure.
---
plugins/phonebook-tracker.c | 34 +++++++++++++++++++++++++++++++++-
1 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 50b2896..5752536 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -268,12 +268,44 @@
"nco:title(?a) nco:phoneNumber(?t) nmo:receivedDate(?call) " \
"nmo:isSent(?call) nmo:isAnswered(?call) ?x " \
"WHERE { " \
+ "{ " \
+ "?x a nco:Contact . " \
+ "?x nco:hasPhoneNumber ?h . " \
+ "?call a nmo:Call ; " \
+ "nmo:to ?x ; " \
+ "nmo:isSent true . " \
+ "?c a nco:PersonContact . " \
+ "?c nco:hasPhoneNumber ?h . " \
+ "OPTIONAL { ?c nco:hasEmailAddress ?e . } " \
+ "OPTIONAL { ?c nco:hasPostalAddress ?p . } " \
+ "OPTIONAL { " \
+ "?c nco:hasAffiliation ?a . " \
+ "OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
+ "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
+ "OPTIONAL { ?a nco:org ?o . } " \
+ "} " \
+ "} UNION { " \
+ "?x a nco:Contact . " \
+ "?x nco:hasPhoneNumber ?w . " \
+ "?call a nmo:Call ; " \
+ "nmo:to ?x ; " \
+ "nmo:isSent true . " \
+ "?c a nco:PersonContact . " \
+ "OPTIONAL { ?c nco:hasEmailAddress ?e . } " \
+ "OPTIONAL { ?c nco:hasPostalAddress ?p . } " \
+ "?c nco:hasAffiliation ?a . " \
+ "?a nco:hasPhoneNumber ?w . " \
+ "OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
+ "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
+ "OPTIONAL { ?a nco:org ?o . } " \
+ "} UNION { " \
"?x a nco:Contact . " \
"?x nco:hasPhoneNumber ?t . " \
"?call a nmo:Call ; " \
"nmo:to ?x ; " \
"nmo:isSent true . " \
- "} ORDER BY DESC(nmo:sentDate(?call))"
+ "} " \
+ "} ORDER BY DESC(nmo:sentDate(?call)) "
#define OUTGOING_CALLS_LIST \
"SELECT ?c nco:nameFamily(?c) " \
--
1.6.3.3
^ permalink raw reply related
* [PATCH 5/6] Binding cch call log with phonebook
From: Rafał Michalski @ 2010-09-28 11:05 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Rafał Michalski
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: 0005-Binding-cch-call-log-with-phonebook.patch --]
[-- Type: text/x-patch, Size: 3634 bytes --]
From 394300a522192fb40629c966ce7ac2c6d4b7d322 Mon Sep 17 00:00:00 2001
From: Rafal Michalski <michalski.raf@gmail.com>
Date: Tue, 28 Sep 2010 11:06:47 +0200
Subject: [PATCH 5/6] Binding cch call log with phonebook
After incoming/missed/outgoing call is done by/to number from phonebook
then combined call history will be shown with data about caller -
downloaded in vCard structure.
---
plugins/phonebook-tracker.c | 67 ++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 66 insertions(+), 1 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 5752536..ab874e5 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -337,18 +337,83 @@
"nmo:isSent(?call) nmo:isAnswered(?call) ?x " \
"WHERE { " \
"{ " \
+ "{ " \
+ "?x a nco:Contact . " \
+ "?x nco:hasPhoneNumber ?h . " \
+ "?call a nmo:Call ; " \
+ "nmo:to ?x ; " \
+ "nmo:isSent true . " \
+ "?c a nco:PersonContact . " \
+ "?c nco:hasPhoneNumber ?h . " \
+ "OPTIONAL { ?c nco:hasEmailAddress ?e . } " \
+ "OPTIONAL { ?c nco:hasPostalAddress ?p . } " \
+ "OPTIONAL { " \
+ "?c nco:hasAffiliation ?a . " \
+ "OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
+ "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
+ "OPTIONAL { ?a nco:org ?o . } " \
+ "} " \
+ "} UNION { " \
+ "?x a nco:Contact . " \
+ "?x nco:hasPhoneNumber ?w . " \
+ "?call a nmo:Call ; " \
+ "nmo:to ?x ; " \
+ "nmo:isSent true . " \
+ "?c a nco:PersonContact . " \
+ "OPTIONAL { ?c nco:hasEmailAddress ?e . } " \
+ "OPTIONAL { ?c nco:hasPostalAddress ?p . } " \
+ "?c nco:hasAffiliation ?a . " \
+ "?a nco:hasPhoneNumber ?w . " \
+ "OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
+ "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
+ "OPTIONAL { ?a nco:org ?o . } " \
+ "} UNION { " \
"?x a nco:Contact . " \
"?x nco:hasPhoneNumber ?t . " \
"?call a nmo:Call ; " \
"nmo:to ?x ; " \
"nmo:isSent true . " \
+ "} " \
"} UNION { " \
+ "{ " \
+ "?x a nco:Contact . " \
+ "?x nco:hasPhoneNumber ?h . " \
+ "?call a nmo:Call ; " \
+ "nmo:from ?x ; " \
+ "nmo:isSent false . " \
+ "?c a nco:PersonContact . " \
+ "?c nco:hasPhoneNumber ?h . " \
+ "OPTIONAL { ?c nco:hasEmailAddress ?e . } " \
+ "OPTIONAL { ?c nco:hasPostalAddress ?p . } " \
+ "OPTIONAL { " \
+ "?c nco:hasAffiliation ?a . " \
+ "OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
+ "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
+ "OPTIONAL { ?a nco:org ?o . } " \
+ "} " \
+ "} UNION { " \
+ "?x a nco:Contact . " \
+ "?x nco:hasPhoneNumber ?w . " \
+ "?call a nmo:Call ; " \
+ "nmo:from ?x ; " \
+ "nmo:isSent false . " \
+ "?c a nco:PersonContact . " \
+ "OPTIONAL { ?c nco:hasEmailAddress ?e . } " \
+ "OPTIONAL { ?c nco:hasPostalAddress ?p . } " \
+ "?c nco:hasAffiliation ?a . " \
+ "?a nco:hasPhoneNumber ?w . " \
+ "OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
+ "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
+ "OPTIONAL { ?a nco:org ?o . } " \
+ "} UNION { " \
"?x a nco:Contact . " \
"?x nco:hasPhoneNumber ?t . " \
"?call a nmo:Call ; " \
"nmo:from ?x ; " \
"nmo:isSent false . " \
- "} } ORDER BY DESC(nmo:receivedDate(?call))"
+ "} " \
+ "} " \
+ "} ORDER BY DESC(nmo:receivedDate(?call)) "
#define COMBINED_CALLS_LIST \
"SELECT ?c nco:nameFamily(?c) nco:nameGiven(?c) " \
--
1.6.3.3
^ permalink raw reply related
* [PATCH 6/6] Fix problem with double numer in call log
From: Rafał Michalski @ 2010-09-28 11:09 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Rafał Michalski
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: 0006-Fix-problem-with-double-number-in-call-log.patch --]
[-- Type: text/x-patch, Size: 2013 bytes --]
From be0a6ef8affbc3c1d0b1fbd94b1e78cd2c94f17c Mon Sep 17 00:00:00 2001
From: Rafal Michalski <michalski.raf@gmail.com>
Date: Tue, 28 Sep 2010 11:07:48 +0200
Subject: [PATCH 6/6] Fix problem with double number in call log
Previously after downloading call log there was two times the same number
for call binded with phonebook - one HOME/WORK type and second OTHER type
in downloaded vCard structure. Now there is only one number with proper
type (HOME or WORK).
---
plugins/phonebook-tracker.c | 18 ++++++++++++++++--
plugins/vcard.c | 1 -
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index ab874e5..2d94bc6 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -774,10 +774,24 @@ static struct phonebook_contact *find_contact(GSList *contacts, const char *id)
static struct phonebook_number *find_phone(GSList *numbers, const char *phone,
int type)
{
- GSList *l;
+ GSList *l = numbers;
struct phonebook_number *pb_num;
- for (l = numbers; l; l = l->next) {
+ if (g_slist_length(l) == 1 && (pb_num = l->data) &&
+ g_strcmp0(pb_num->tel, phone) == 0) {
+
+ if ((type == TEL_TYPE_HOME || type == TEL_TYPE_WORK) &&
+ pb_num->type == TEL_TYPE_OTHER) {
+ pb_num->type = type;
+ return pb_num;
+ }
+
+ if (type == TEL_TYPE_OTHER && (pb_num->type == TEL_TYPE_HOME ||
+ pb_num->type == TEL_TYPE_WORK))
+ return pb_num;
+ }
+
+ for (; l; l = l->next) {
pb_num = l->data;
/* Returning phonebook number if phone values and type values
* are equal */
diff --git a/plugins/vcard.c b/plugins/vcard.c
index c720954..41f9fbd 100644
--- a/plugins/vcard.c
+++ b/plugins/vcard.c
@@ -452,7 +452,6 @@ static void vcard_printf_datetime(GString *vcards,
static void vcard_printf_end(GString *vcards)
{
vcard_printf(vcards, "END:VCARD");
- vcard_printf(vcards, "");
}
void phonebook_add_contact(GString *vcards, struct phonebook_contact *contact,
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] Add checking for agent reply state in adapter
From: Johan Hedberg @ 2010-09-28 11:18 UTC (permalink / raw)
To: Radoslaw Jablonski; +Cc: linux-bluetooth
In-Reply-To: <1285665470-5261-1-git-send-email-ext-jablonski.radoslaw@nokia.com>
Hi Radek,
On Tue, Sep 28, 2010, Radoslaw Jablonski wrote:
> Added checking for agent reply state before cancelling agent in
> session_free(..). This check is needed to ensure that memory for
> agent request will be freed only once (In that case, free on this
> request is called later in the end of agent_reply func)
> ---
> src/adapter.c | 6 +++++-
> 1 files changed, 5 insertions(+), 1 deletions(-)
Thanks. The patch has been pushed upstream with s/is_reply/got_reply/
which is more intuitive imho.
Johan
^ permalink raw reply
* Re: [PATCH 1/6] Changing default type of call from call log
From: Johan Hedberg @ 2010-09-28 11:25 UTC (permalink / raw)
To: Rafał Michalski; +Cc: linux-bluetooth
In-Reply-To: <AANLkTikPZSD64x_Cvz3EDG9ippUwYwA4zFQBOmaU7DK-@mail.gmail.com>
Hi Rafal,
All six patches have been pushed upstream. Please try keep the commit
messages consistent format in the future. I now had to change
Changing->Change and Binding->Bind for you.
Johan
^ permalink raw reply
* Re: How to send stream via obexd without ending request
From: Luiz Augusto von Dentz @ 2010-09-28 11:25 UTC (permalink / raw)
To: Lukasz Pawlik; +Cc: linux-bluetooth
In-Reply-To: <4CA1C01A.3040403@comarch.com>
Hi Lukasz,
On Tue, Sep 28, 2010 at 1:14 PM, Lukasz Pawlik
<lukasz.pawlik@comarch.com> wrote:
> Hi,
>
> I want to stream data immediately after they appear and wait for next part.
> So far I didn't manage to find a way how to do this properly. Returning
> error EAGAIN from my read function leads to canceling request and this is
> something I don't want to do. The other way I was able to find is returning
> value > 0 from read function until last part of data appear. Obexd will
> stream data when buffer exceed allocated memory chunk and return to read
> more data. This is no solution because it forces obexd to send empty
> streams. Does anyone knows how to solve this problem ?
You should probably handle -EAGAIN to handle_async_io in src/obex.c,
so that it doesn't cancel the request for this specific error, also it
should return TRUE so that the callback doesn't get automatically
unregistered.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: How to send stream via obexd without ending request
From: Luiz Augusto von Dentz @ 2010-09-28 13:06 UTC (permalink / raw)
To: Lukasz Pawlik; +Cc: linux-bluetooth
In-Reply-To: <AANLkTinV-E_GOw1ppN5WJ+KzOvgnY-tiAABLWvZ91ANg@mail.gmail.com>
Hi,
On Tue, Sep 28, 2010 at 2:25 PM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi Lukasz,
>
> On Tue, Sep 28, 2010 at 1:14 PM, Lukasz Pawlik
> <lukasz.pawlik@comarch.com> wrote:
>> Hi,
>>
>> I want to stream data immediately after they appear and wait for next part.
>> So far I didn't manage to find a way how to do this properly. Returning
>> error EAGAIN from my read function leads to canceling request and this is
>> something I don't want to do. The other way I was able to find is returning
>> value > 0 from read function until last part of data appear. Obexd will
>> stream data when buffer exceed allocated memory chunk and return to read
>> more data. This is no solution because it forces obexd to send empty
>> streams. Does anyone knows how to solve this problem ?
>
> You should probably handle -EAGAIN to handle_async_io in src/obex.c,
> so that it doesn't cancel the request for this specific error, also it
> should return TRUE so that the callback doesn't get automatically
> unregistered.
Actually this doesn't work, if we do fetch all the data in a single
query than a lot of memory is already allocated for that, in
DBusMessage, so this only fix the extra buffer for translating tracker
contacts to vcards, so we probably need to fix the way we fetch the
data from tracker before changing anything in core. Also it is good to
notice that read takes the amount of data available in core buffer,
which is probably what is left to fill a packet, so when the driver
asks to resume it is suppose to to have enough data to fill that or it
is the end of the stream.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* [PATCH] Fix emitting TransferCompleted twice
From: Luiz Augusto von Dentz @ 2010-09-28 13:19 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
This is caused by REQDONE and latter disconnect generating duplicate
signals in case of opp.
To fix this now we check if the object is valid before proceeding.
---
src/manager.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/src/manager.c b/src/manager.c
index 78a329c..80140b6 100644
--- a/src/manager.c
+++ b/src/manager.c
@@ -648,7 +648,8 @@ void manager_emit_transfer_progress(struct obex_session *os)
void manager_emit_transfer_completed(struct obex_session *os)
{
- emit_transfer_completed(os->cid, !os->aborted);
+ if (os->object)
+ emit_transfer_completed(os->cid, !os->aborted);
}
DBusConnection *obex_dbus_get_connection(void)
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v4 1/2] HID: Add Support for Setting and Getting Feature Reports from hidraw
From: Antonio Ospite @ 2010-09-28 13:30 UTC (permalink / raw)
To: Alan Ott
Cc: Jiri Kosina, Stefan Achatz, Alexey Dobriyan, Tejun Heo,
Alan Stern, Greg Kroah-Hartman, Marcel Holtmann, Stephane Chatty,
Michael Poole, David S. Miller, Bastien Nocera, Eric Dumazet,
linux-input, linux-kernel, linux-usb, linux-bluetooth, netdev
In-Reply-To: <1281990059-3562-2-git-send-email-alan@signal11.us>
[-- Attachment #1.1: Type: text/plain, Size: 2624 bytes --]
On Mon, 16 Aug 2010 16:20:58 -0400
Alan Ott <alan@signal11.us> wrote:
> Per the HID Specification, Feature reports must be sent and received on
> the Configuration endpoint (EP 0) through the Set_Report/Get_Report
> interfaces. This patch adds two ioctls to hidraw to set and get feature
> reports to and from the device. Modifications were made to hidraw and
> usbhid.
>
> New hidraw ioctls:
> HIDIOCSFEATURE - Perform a Set_Report transfer of a Feature report.
> HIDIOCGFEATURE - Perform a Get_Report transfer of a Feature report.
>
> Signed-off-by: Alan Ott <alan@signal11.us>
Hi Alan, I am doing some stress testing on hidraw, if I have a loop with
HIDIOCGFEATURE on a given report and I disconnect the device while the
loop is running I get this:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
IP: [<ffffffffa02c66b4>] hidraw_ioctl+0xfc/0x32c [hid]
Full log attached along with the test program, the device is a Sony PS3
Controller (sixaxis).
If my objdump analysis is right, hidraw_ioctl+0xfc should be around line
361 in hidraw.c (with your patch applied):
struct hid_device *hid = dev->hid;
It looks like 'dev' (which is hidraw_table[minor]) can be NULL
sometimes, can't it?
This is not introduced by your changes tho.
Just as a side note, the bug does not show up if the userspace program
handles return values properly and exits as soon as it gets an error
from the HID layer, see the XXX comment in test_hidraw_feature.c.
This fixes it, if it looks ok I will resend the patch rebased on
mainline code:
diff --git a/drivers/hid/hidraw.c b/drivers/hid/hidraw.c
index 7df1310..3c040c6 100644
--- a/drivers/hid/hidraw.c
+++ b/drivers/hid/hidraw.c
@@ -322,6 +322,10 @@ static long hidraw_ioctl(struct file *file, unsigned int cmd,
mutex_lock(&minors_lock);
dev = hidraw_table[minor];
+ if (!dev) {
+ ret = -ENODEV;
+ goto out;
+ }
switch (cmd) {
case HIDIOCGRDESCSIZE:
@@ -412,6 +416,7 @@ static long hidraw_ioctl(struct file *file, unsigned int cmd,
ret = -ENOTTY;
}
+out:
mutex_unlock(&minors_lock);
return ret;
}
this change covers also the other uses of hidraw_table[minor] in
hidraw_send_report/hidraw_get_report.
Regards,
Antonio
--
Antonio Ospite
http://ao2.it
PGP public key ID: 0x4553B001
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
[-- Attachment #1.2: dmesg_hidraw_feature_bug.log --]
[-- Type: application/octet-stream, Size: 3914 bytes --]
[ 111.645836] usb 4-1: USB disconnect, address 2
[ 111.669466] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028
[ 111.669484] IP: [<ffffffffa02c66b4>] hidraw_ioctl+0xfc/0x32c [hid]
[ 111.669529] PGD 5a953067 PUD 6d741067 PMD 0
[ 111.669539] Oops: 0000 [#1] SMP
[ 111.669545] last sysfs file: /sys/devices/pci0000:00/0000:00:04.0/usb4/idVendor
[ 111.669556] CPU 0
[ 111.669559] Modules linked in: hidp powernow_k8 mperf cpufreq_powersave cpufreq_conservative cpufreq_stats cpufreq_userspace lirc_serial(C) lirc_dev ipt_MASQUERADE bridge stp ppdev lp sco bnep rfcomm l2cap crc16 tun sit tunnel4 kvm_amd kvm binfmt_misc uinput fuse nfsd ip6table_raw ip6table_mangle ip6t_REJECT exportfs nfs ip6t_LOG lockd fscache nf_conntrack_ipv6 nfs_acl auth_rpcgss ip6table_filter sunrpc ip6_tables xt_tcpudp ipt_REJECT ipt_ULOG xt_limit xt_state xt_multiport iptable_filter iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_mangle iptable_raw ip_tables x_tables hwmon_vid loop snd_hda_codec_nvhdmi snd_hda_codec_via snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_midi snd_rawmidi nvidia(P) snd_seq_midi_event snd_seq parport_pc btusb snd_timer snd_seq_device asus_atk0110 joydev video snd bluetooth rfkill hid_sony output wmi parport edac_core i2c_nforce2 tpm_tis shpchp pci_hotplug k8temp edac_mce_amd pcspkr tpm tpm_bios evdev soundcore snd_page_alloc i2c_core button processor ext3 jbd mbcache dm_mod sg sr_mod sd_mod crc_t10dif cdrom ata_generic usbhid hid ahci libahci pata_amd ohci_hcd libata ehci_hcd scsi_mod usbcore thermal forcedeth nls_base thermal_sys floppy [last unloaded: scsi_wait_scan]
[ 111.669736]
[ 111.669746] Pid: 2969, comm: test_hidraw_fea Tainted: P C 2.6.36-rc5-ao2+ #1 M3N78-VM/System Product Name
[ 111.669753] RIP: 0010:[<ffffffffa02c66b4>] [<ffffffffa02c66b4>] hidraw_ioctl+0xfc/0x32c [hid]
[ 111.669771] RSP: 0018:ffff880056831e78 EFLAGS: 00010206
[ 111.669776] RAX: 0000000000000048 RBX: 00000000c02d4807 RCX: 00000000022c7e50
[ 111.669783] RDX: 0000000100000000 RSI: ffffffff810377e0 RDI: ffffffffa02ceaa0
[ 111.669789] RBP: 00000000022c7e50 R08: 00007f983f1cbec8 R09: 0000000000400aca
[ 111.669795] R10: ffffffff8100769f R11: ffff880037a78dd8 R12: ffff88005a85c300
[ 111.669801] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 111.669808] FS: 00007f983f3cc700(0000) GS:ffff880001a00000(0000) knlGS:0000000000000000
[ 111.669815] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 111.669821] CR2: 0000000000000028 CR3: 000000005aba9000 CR4: 00000000000006f0
[ 111.669827] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 111.669833] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 111.669840] Process test_hidraw_fea (pid: 2969, threadinfo ffff880056830000, task ffff88005ab93680)
[ 111.669844] Stack:
[ 111.669848] 00000000010aad14 ffff88005ab936b8 ffff88005a85c300 ffff880037fc6700
[ 111.669857] <0> 00000000022c7e50 00000000022c7e50 0000000000000000 ffffffff810f64a5
[ 111.669865] <0> ffff880001a14880 ffff88005ab93680 ffffffff81302776 0000000000000000
[ 111.669875] Call Trace:
[ 111.669898] [<ffffffff810f64a5>] ? do_vfs_ioctl+0x4a2/0x4ef
[ 111.669915] [<ffffffff81302776>] ? schedule+0x573/0x5b7
[ 111.669923] [<ffffffff810f653d>] ? sys_ioctl+0x4b/0x72
[ 111.669933] [<ffffffff810ea002>] ? sys_write+0x5f/0x6b
[ 111.669947] [<ffffffff81008a02>] ? system_call_fastpath+0x16/0x1b
[ 111.669952] Code: 2c 66 89 44 24 06 e8 1a c2 03 e1 48 89 e6 ba 08 00 00 00 48 89 ef e8 cc 79 ec e0 85 c0 0f 84 18 02 00 00 e9 01 02 00 00 0f b6 c7 <49> 8b 7d 28 83 f8 48 0f 85 fa 01 00 00 0f b6 c3 83 f8 06 75 24
[ 111.670011] RIP [<ffffffffa02c66b4>] hidraw_ioctl+0xfc/0x32c [hid]
[ 111.670025] RSP <ffff880056831e78>
[ 111.670029] CR2: 0000000000000028
[ 111.670036] ---[ end trace 9c7530cfc7009202 ]---
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.3: test_hidraw_feature.c --]
[-- Type: text/x-csrc; name="test_hidraw_feature.c", Size: 1265 bytes --]
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <stdint.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/ioctl.h>
/*
#include <linux/hidraw.h>
*/
#include "/home/ao2/Proj/linux/linux-2.6/include/linux/hidraw.h"
void dump_hex_string(unsigned char *buf, unsigned int len)
{
unsigned int i;
for (i = 0; i < len; i++)
printf("%02x%c", buf[i], i < len - 1 ? ' ' : 0);
}
void dump_feature_report(int fd, uint8_t report_number, unsigned int len)
{
unsigned char *buf;
int ret;
buf = calloc(len, sizeof(*buf));
buf[0] = report_number;
ret = ioctl(fd, HIDIOCGFEATURE(len), buf);
if (ret < 0) {
fprintf(stderr, "report: 0x%02x ret: %d\n", report_number, ret);
/* XXX: if I put exit(1) here the bug is masked */
return;
}
dump_hex_string(buf, len);
printf("\r");
fflush(stdout);
free(buf);
}
int main(int argc, char *argv[])
{
int fd = -1;
if (argc != 2) {
fprintf(stderr, "usage: %s </dev/hidrawX>\n", argv[0]);
exit(1);
}
fd = open(argv[1], O_RDWR);
if (fd < 0) {
perror("hidraw open");
exit(1);
}
while (1)
dump_feature_report(fd, 0x01, 45);
printf("\n");
close(fd);
exit(0);
}
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply related
* Re: [PATCH] Fix emitting TransferCompleted twice
From: Johan Hedberg @ 2010-09-28 13:41 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1285679962-10367-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Tue, Sep 28, 2010, Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
>
> This is caused by REQDONE and latter disconnect generating duplicate
> signals in case of opp.
>
> To fix this now we check if the object is valid before proceeding.
> ---
> src/manager.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
Thanks. The patch has been pushed upstream.
Johan
^ permalink raw reply
* [PATCH 1/4] Add the Attribute interface to the API
From: Claudio Takahasi @ 2010-09-28 17:49 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Vinicius Costa Gomes
From: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
For now the Attribute API will allow users to list all the GATT
services that a device has.
---
doc/attribute-api.txt | 19 +++++++++++++++++++
doc/device-api.txt | 4 ----
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/doc/attribute-api.txt b/doc/attribute-api.txt
index 011691e..0989099 100644
--- a/doc/attribute-api.txt
+++ b/doc/attribute-api.txt
@@ -37,6 +37,25 @@ Methods
Properties
+Attribute Protocol hierarchy
+============================
+
+Service org.bluez
+Interface org.bluez.Attribute
+Object path [prefix]/{hci0}/{device0}
+
+
+Methods dict GetProperties()
+
+ Returns all properties for the interface. See the
+ properties section for available properties.
+
+Properties array{object} Services
+
+ List of all the Primary Services that this device
+ implements.
+
+
Device Service hierarchy
========================
diff --git a/doc/device-api.txt b/doc/device-api.txt
index 95b5b22..b818299 100644
--- a/doc/device-api.txt
+++ b/doc/device-api.txt
@@ -139,10 +139,6 @@ Properties string Address [readonly]
List of 128-bit UUIDs that represents the available
remote services.
- array{object} Services [readonly]
-
- List of characteristics based services.
-
boolean Paired [readonly]
Indicates if the remote device is paired.
--
1.7.3
^ permalink raw reply related
* [PATCH 2/4] Add GetProperties method in the Device service hierarchy
From: Claudio Takahasi @ 2010-09-28 17:49 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1285696155-32766-1-git-send-email-claudio.takahasi@openbossa.org>
Changes the attribute API to become compliant with other BlueZ
APIs. Characteristics properties can be retrieved using GetProperties
method of the Device Characteristic hierarchy. This patch also removes
unneeded characteristic properties description which is already
explained in the next section.
---
doc/attribute-api.txt | 28 +++-------------------------
1 files changed, 3 insertions(+), 25 deletions(-)
diff --git a/doc/attribute-api.txt b/doc/attribute-api.txt
index 0989099..a5e475b 100644
--- a/doc/attribute-api.txt
+++ b/doc/attribute-api.txt
@@ -64,15 +64,10 @@ Interface org.bluez.Characteristic
Object path [prefix]/{hci0}/{device0}/{service0, service1, ...}
[prefix]/{hci0}/{device1}/{service0, service1, ...}
-Methods array[(object, dict)] GetCharacteristics()
+Methods dict GetProperties()
- Array of tuples with object path as identifier. An
- alternative is doing dict of dict since the object
- path is unique and the order of characteristics is
- irrelevant. However it might be good to actually
- present an order here.
-
- See Characteristics properties for dictionary details.
+ Returns all properties for the interface. See the
+ Properties section for the available properties.
RegisterCharacteristicsWatcher(object path)
@@ -109,23 +104,6 @@ Properties string Name (mandatory) [readonly]
includes. That way no complicated service includes array
is needed.
- string UUID
- string Name
- string Description
- struct Format (type, name, exponet etc.)
-
- array{byte} Value
- string Representation (of the binary Value)
-
- object Service (the original service in case of includes)
-
- At this point only GetProperties() method call should be
- supported for simplicity. Changing characteristics is up
- to future support.
-
- The object path of the characteristics might be split
- over multiple service objects, because of includes.
-
Device Characteristic hierarchy
===============================
--
1.7.3
^ permalink raw reply related
* [PATCH 3/4] Add SetProperty in the Device characteristic hierarchy
From: Claudio Takahasi @ 2010-09-28 17:49 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1285696155-32766-1-git-send-email-claudio.takahasi@openbossa.org>
Add SetProperty method to allow characteristic watchers or any other
D-Bus client application to change the value of a given characteristic.
Use cases: Changing sensors thresholds, client characteristic
configuration for notification/indication.
---
doc/attribute-api.txt | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/doc/attribute-api.txt b/doc/attribute-api.txt
index a5e475b..d0ce6f8 100644
--- a/doc/attribute-api.txt
+++ b/doc/attribute-api.txt
@@ -118,6 +118,13 @@ Methods dict GetProperties()
Returns all properties for the characteristic. See the
properties section for available properties.
+ void SetProperty(string name, variant value)
+
+ Changes the value of the specified property. Only
+ read-write properties can be changed. On success
+ this will emit a PropertyChanged signal.
+
+ Possible Errors: org.bluez.Error.InvalidArguments
Properties string UUID [readonly]
--
1.7.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox