* RE: Which software is responsible for bringing the devices (hci0 .. hcix) up ?
From: Vellemans, Noel @ 2012-08-29 7:20 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth
In-Reply-To: <20120829071455.GB3937@aemeltch-MOBL1>
Hi,
It is an EXTERNAL USB-device plugged in manually, and if it is plugged
in, the device is recognized.
Regards Noel
<< log>>
Plug in device ... Results in....
# usb wakeup is here
usb 2-1: new full speed USB device using fsl-ehci and address 4
usb 2-1: New USB device found, idVendor=0a12, idProduct=0001
usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
#
# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0eef:7304 D-WAV Scientific Co., Ltd
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 004: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth
Dongle (HCI mode)
# hciconfig
hci0: Type: BR/EDR Bus: USB
BD Address: 00:00:00:00:00:00 ACL MTU: 0:0 SCO MTU: 0:0
DOWN
RX bytes:0 acl:0 sco:0 events:0 errors:0
TX bytes:0 acl:0 sco:0 commands:0 errors:0
-----Original Message-----
From: Andrei Emeltchenko [mailto:andrei.emeltchenko.news@gmail.com]
Sent: 29Aug12 09:15
To: Vellemans, Noel
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: Which software is responsible for bringing the devices
(hci0 .. hcix) up ?
Hi Noel,
On Wed, Aug 29, 2012 at 09:12:18AM +0200, Vellemans, Noel wrote:
> Hi Andrei,
>
> Any clue what the reason can be, that the device is not comming 'UP'
> automatically ?
It is powered off automatically.
Best regards
Andrei Emeltchenko
>
>
> Regards Noel
>
>
> -----Original Message-----
> From: Andrei Emeltchenko [mailto:andrei.emeltchenko.news@gmail.com]
> Sent: 29Aug12 09:09
> To: Vellemans, Noel
> Cc: linux-bluetooth@vger.kernel.org
> Subject: Re: Which software is responsible for bringing the devices
> (hci0 .. hcix) up ?
>
> Hi Noel,
>
> On Wed, Aug 29, 2012 at 08:58:12AM +0200, Vellemans, Noel wrote:
> > Hi,
> >
> >
> > I have a simple question, I think, But I do not manage to find the
> > answer into the old mailing-list-posts.
> >
> > I'm using bluez-4.99 and Linux kernel 2.6.35.3.
> >
> > When plugging in a device (CSR-device) the device is recognized but
> > it
>
> > is not 'UP'.
> >
> > Can someone tell me what piece of software is NORMALLY setting the
> > device into the 'UP' state?
> > (so that I do not have to type hciconfig hci0 up)
>
> bluetoothd
>
> Best regards
> Andrei Emeltchenko
>
^ permalink raw reply
* [PATCH] Bluetooth: Make hci_chan_del return void
From: Andrei Emeltchenko @ 2012-08-29 7:20 UTC (permalink / raw)
To: linux-bluetooth
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Return code is not needed in hci_chan_del
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
---
include/net/bluetooth/hci_core.h | 2 +-
net/bluetooth/hci_conn.c | 4 +---
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 0964954..36720f0 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -573,7 +573,7 @@ void hci_conn_hash_flush(struct hci_dev *hdev);
void hci_conn_check_pending(struct hci_dev *hdev);
struct hci_chan *hci_chan_create(struct hci_conn *conn);
-int hci_chan_del(struct hci_chan *chan);
+void hci_chan_del(struct hci_chan *chan);
void hci_chan_list_flush(struct hci_conn *conn);
struct hci_chan *hci_chan_lookup_handle(struct hci_conn *hcon, __u16 handle);
struct hci_chan *hci_chan_lookup_handle_all(struct hci_dev *hdev,
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 1c79a76..4695880 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -935,7 +935,7 @@ struct hci_chan *hci_chan_create(struct hci_conn *conn)
return chan;
}
-int hci_chan_del(struct hci_chan *chan)
+void hci_chan_del(struct hci_chan *chan)
{
struct hci_conn *conn = chan->conn;
struct hci_dev *hdev = conn->hdev;
@@ -948,8 +948,6 @@ int hci_chan_del(struct hci_chan *chan)
skb_queue_purge(&chan->data_q);
kfree(chan);
-
- return 0;
}
void hci_chan_list_flush(struct hci_conn *conn)
--
1.7.9.5
^ permalink raw reply related
* Re: Which software is responsible for bringing the devices (hci0 .. hcix) up ?
From: Andrei Emeltchenko @ 2012-08-29 7:37 UTC (permalink / raw)
To: Vellemans, Noel; +Cc: linux-bluetooth
In-Reply-To: <1531E53627F1F749B4FE809BF2A4EB67036F2FB2@WETMEX10.loepfe.com>
Hi,
On Wed, Aug 29, 2012 at 09:20:34AM +0200, Vellemans, Noel wrote:
> Hi,
>
> It is an EXTERNAL USB-device plugged in manually, and if it is plugged
> in, the device is recognized.
Do you have bluetoothd running?
Best regards
Andrei Emeltchenko
>
>
> Regards Noel
>
> << log>>
>
> Plug in device ... Results in....
>
>
> # usb wakeup is here
> usb 2-1: new full speed USB device using fsl-ehci and address 4
> usb 2-1: New USB device found, idVendor=0a12, idProduct=0001
> usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
>
> #
>
> # lsusb
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 001 Device 002: ID 0eef:7304 D-WAV Scientific Co., Ltd
> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 004: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth
> Dongle (HCI mode)
>
>
> # hciconfig
> hci0: Type: BR/EDR Bus: USB
> BD Address: 00:00:00:00:00:00 ACL MTU: 0:0 SCO MTU: 0:0
> DOWN
> RX bytes:0 acl:0 sco:0 events:0 errors:0
> TX bytes:0 acl:0 sco:0 commands:0 errors:0
>
>
> -----Original Message-----
> From: Andrei Emeltchenko [mailto:andrei.emeltchenko.news@gmail.com]
> Sent: 29Aug12 09:15
> To: Vellemans, Noel
> Cc: linux-bluetooth@vger.kernel.org
> Subject: Re: Which software is responsible for bringing the devices
> (hci0 .. hcix) up ?
>
> Hi Noel,
>
> On Wed, Aug 29, 2012 at 09:12:18AM +0200, Vellemans, Noel wrote:
> > Hi Andrei,
> >
> > Any clue what the reason can be, that the device is not comming 'UP'
> > automatically ?
>
> It is powered off automatically.
>
> Best regards
> Andrei Emeltchenko
>
> >
> >
> > Regards Noel
> >
> >
> > -----Original Message-----
> > From: Andrei Emeltchenko [mailto:andrei.emeltchenko.news@gmail.com]
> > Sent: 29Aug12 09:09
> > To: Vellemans, Noel
> > Cc: linux-bluetooth@vger.kernel.org
> > Subject: Re: Which software is responsible for bringing the devices
> > (hci0 .. hcix) up ?
> >
> > Hi Noel,
> >
> > On Wed, Aug 29, 2012 at 08:58:12AM +0200, Vellemans, Noel wrote:
> > > Hi,
> > >
> > >
> > > I have a simple question, I think, But I do not manage to find the
> > > answer into the old mailing-list-posts.
> > >
> > > I'm using bluez-4.99 and Linux kernel 2.6.35.3.
> > >
> > > When plugging in a device (CSR-device) the device is recognized but
> > > it
> >
> > > is not 'UP'.
> > >
> > > Can someone tell me what piece of software is NORMALLY setting the
> > > device into the 'UP' state?
> > > (so that I do not have to type hciconfig hci0 up)
> >
> > bluetoothd
> >
> > Best regards
> > Andrei Emeltchenko
> >
^ permalink raw reply
* RE: Which software is responsible for bringing the devices (hci0 .. hcix) up ?
From: Vellemans, Noel @ 2012-08-29 7:49 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth
In-Reply-To: <20120829073733.GC3937@aemeltch-MOBL1>
Hi,
>> Do you have bluetoothd running?
OK : You've got it.. I think.
When looking into the process-list with ps , I don't see bluetoothd.
When starting Bluetoothd on the command line .. . before plugging in the
device ..
the the device is 'UP' like it should be... (you are guiding/pointing me
in the GOOD direction, thankx)
Next question (Sorry) ? Isn't bluetoothd supposed to be launched by udev
?
Or I'm I missing some startup-script (/etc/init.d/... ) ?
I just wonder is there somewhere a description on how bleuz (bluetooth)
is started at boot ?
Regards Noel
-----Original Message-----
From: Andrei Emeltchenko [mailto:andrei.emeltchenko.news@gmail.com]
Sent: 29Aug12 09:38
To: Vellemans, Noel
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: Which software is responsible for bringing the devices
(hci0 .. hcix) up ?
Hi,
On Wed, Aug 29, 2012 at 09:20:34AM +0200, Vellemans, Noel wrote:
> Hi,
>
> It is an EXTERNAL USB-device plugged in manually, and if it is plugged
> in, the device is recognized.
Do you have bluetoothd running?
Best regards
Andrei Emeltchenko
>
>
> Regards Noel
>
> << log>>
>
> Plug in device ... Results in....
>
>
> # usb wakeup is here
> usb 2-1: new full speed USB device using fsl-ehci and address 4 usb
> 2-1: New USB device found, idVendor=0a12, idProduct=0001 usb 2-1: New
> USB device strings: Mfr=0, Product=0, SerialNumber=0
>
> #
>
> # lsusb
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002
> Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device
> 002: ID 0eef:7304 D-WAV Scientific Co., Ltd Bus 003 Device 001: ID
> 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 004: ID
> 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
>
>
> # hciconfig
> hci0: Type: BR/EDR Bus: USB
> BD Address: 00:00:00:00:00:00 ACL MTU: 0:0 SCO MTU: 0:0
> DOWN
> RX bytes:0 acl:0 sco:0 events:0 errors:0
> TX bytes:0 acl:0 sco:0 commands:0 errors:0
>
>
> -----Original Message-----
> From: Andrei Emeltchenko [mailto:andrei.emeltchenko.news@gmail.com]
> Sent: 29Aug12 09:15
> To: Vellemans, Noel
> Cc: linux-bluetooth@vger.kernel.org
> Subject: Re: Which software is responsible for bringing the devices
> (hci0 .. hcix) up ?
>
> Hi Noel,
>
> On Wed, Aug 29, 2012 at 09:12:18AM +0200, Vellemans, Noel wrote:
> > Hi Andrei,
> >
> > Any clue what the reason can be, that the device is not comming 'UP'
> > automatically ?
>
> It is powered off automatically.
>
> Best regards
> Andrei Emeltchenko
>
> >
> >
> > Regards Noel
> >
> >
> > -----Original Message-----
> > From: Andrei Emeltchenko [mailto:andrei.emeltchenko.news@gmail.com]
> > Sent: 29Aug12 09:09
> > To: Vellemans, Noel
> > Cc: linux-bluetooth@vger.kernel.org
> > Subject: Re: Which software is responsible for bringing the devices
> > (hci0 .. hcix) up ?
> >
> > Hi Noel,
> >
> > On Wed, Aug 29, 2012 at 08:58:12AM +0200, Vellemans, Noel wrote:
> > > Hi,
> > >
> > >
> > > I have a simple question, I think, But I do not manage to find the
> > > answer into the old mailing-list-posts.
> > >
> > > I'm using bluez-4.99 and Linux kernel 2.6.35.3.
> > >
> > > When plugging in a device (CSR-device) the device is recognized
> > > but it
> >
> > > is not 'UP'.
> > >
> > > Can someone tell me what piece of software is NORMALLY setting the
> > > device into the 'UP' state?
> > > (so that I do not have to type hciconfig hci0 up)
> >
> > bluetoothd
> >
> > Best regards
> > Andrei Emeltchenko
> >
^ permalink raw reply
* [PATCH v3 1/2] Bluetooth: mgmt: Fix enabling SSP while powered off
From: Andrzej Kaczmarek @ 2012-08-29 8:02 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Andrzej Kaczmarek, stable
When new BT USB adapter is plugged in it's configured while still being powered
off (HCI_AUTO_OFF flag is set), thus Set SSP will only set dev_flags but won't
write changes to controller. As a result remote devices won't use Secure Simple
Pairing with our device due to SSP Host Support flag disabled in extended
features and may also reject SSP attempt from our side (with possible fallback
to legacy pairing).
This patch ensures HCI Write Simple Pairing Mode is sent when Set Powered is
called to power on controller and clear HCI_AUTO_OFF flag.
Signed-off-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
Cc: stable@vger.kernel.org
---
net/bluetooth/mgmt.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index 05d4b83..ccc6716 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -2891,6 +2891,12 @@ int mgmt_powered(struct hci_dev *hdev, u8 powered)
if (scan)
hci_send_cmd(hdev, HCI_OP_WRITE_SCAN_ENABLE, 1, &scan);
+ if (test_bit(HCI_SSP_ENABLED, &hdev->dev_flags)) {
+ u8 ssp = 1;
+
+ hci_send_cmd(hdev, HCI_OP_WRITE_SSP_MODE, 1, &ssp);
+ }
+
update_class(hdev);
update_name(hdev, hdev->dev_name);
update_eir(hdev);
--
1.7.11.3
^ permalink raw reply related
* [PATCH v3 2/2] Bluetooth: mgmt: Fix enabling LE while powered off
From: Andrzej Kaczmarek @ 2012-08-29 8:02 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Andrzej Kaczmarek, stable
In-Reply-To: <1346227329-1686-1-git-send-email-andrzej.kaczmarek@tieto.com>
When new BT USB adapter is plugged in it's configured while still being powered
off (HCI_AUTO_OFF flag is set), thus Set LE will only set dev_flags but won't
write changes to controller. As a result it's not possible to start device
discovery session on LE controller as it uses interleaved discovery which
requires LE Supported Host flag in extended features.
This patch ensures HCI Write LE Host Supported is sent when Set Powered is
called to power on controller and clear HCI_AUTO_OFF flag.
Signed-off-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
Cc: stable@vger.kernel.org
---
net/bluetooth/mgmt.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index ccc6716..57ce7cd 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -2897,6 +2897,16 @@ int mgmt_powered(struct hci_dev *hdev, u8 powered)
hci_send_cmd(hdev, HCI_OP_WRITE_SSP_MODE, 1, &ssp);
}
+ if (test_bit(HCI_LE_ENABLED, &hdev->dev_flags)) {
+ struct hci_cp_write_le_host_supported cp;
+
+ cp.le = 1;
+ cp.simul = !!(hdev->features[6] & LMP_SIMUL_LE_BR);
+
+ hci_send_cmd(hdev, HCI_OP_WRITE_LE_HOST_SUPPORTED,
+ sizeof(cp), &cp);
+ }
+
update_class(hdev);
update_name(hdev, hdev->dev_name);
update_eir(hdev);
--
1.7.11.3
^ permalink raw reply related
* Re: [PATCH] client: Fix crash on map module
From: Luiz Augusto von Dentz @ 2012-08-29 8:23 UTC (permalink / raw)
To: Srinivasa Ragavan; +Cc: linux-bluetooth
In-Reply-To: <1346217303-21521-1-git-send-email-srinivasa.ragavan.venkateswaran@intel.com>
Hi,
On Wed, Aug 29, 2012 at 8:15 AM, Srinivasa Ragavan
<srinivasa.ragavan.venkateswaran@intel.com> wrote:
> gboolean is expected to hold 0/1. But it is holding int return from strcasecmp
> which crashes DBusMessage at _dbus_return_val_if_fail
> (*bool_p == 0 || *bool_p == 1, FALSE);
>
> Trace:
> 0 0x00007ffff7328d95 in __GI_raise (sig=6) at raise.c:64
> 1 0x00007ffff732a2ab in __GI_abort () at abort.c:93
> 2 0x00007ffff78d0655 in _dbus_abort () at dbus-sysdeps.c:94
> 3 0x00007ffff78c75f1 in _dbus_warn_check_failed at dbus-internals.c:289
> 4 0x00007ffff78ba28b in dbus_message_iter_append_basic at dbus-message.c:2538
> 5 0x00000000004201c3 in append_variant at client/dbus.c:44
> 6 0x000000000042024e in obex_dbus_dict_append at client/dbus.c:65
> 7 0x000000000041dcc9 in parse_read at client/map.c:423
> 8 0x000000000041dfa7 in msg_element at client/map.c:518
> 9 0x00007ffff7b323b9 in emit_start_element at gmarkup.c:986
> 10 0x00007ffff7b33b44 in g_markup_parse_context_parse at gmarkup.c:1323
> 11 0x000000000041e1ad in message_listing_cb at client/map.c:586
> 12 0x000000000041744c in session_terminate_transfer client/session.c:743
> 13 0x00000000004174d7 in session_notify_complete at client/session.c:758
> 14 0x000000000041755a in transfer_complete at client/session.c:778
> 15 0x000000000041f57b in xfer_complete at client/transfer.c:521
> 16 0x000000000040efdf in transfer_complete at gobex/gobex-transfer.c:102
> 17 0x000000000040f418 in transfer_response at gobex/gobex-transfer.c:221
> 18 0x000000000040b320 in handle_response at gobex/gobex.c:948
> 19 0x000000000040bbc1 in incoming_data at gobex/gobex.c:1191
> 20 0x00007ffff7b2f94a in g_main_dispatch (context=0x62f130) at gmain.c:2515
> 21 g_main_context_dispatch (context=0x62f130) at gmain.c:3052
> 22 0x00007ffff7b2fd10 in g_main_context_iterate at gmain.c:3123
> 23 g_main_context_iterate at gmain.c:3060
> 24 0x00007ffff7b3010a in g_main_loop_run (loop=0x62e1b0) at gmain.c:3317
> 25 0x000000000041527d in main at client/main.c:175
> ---
> client/map.c | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/client/map.c b/client/map.c
> index e606cb2..4f07fcb 100644
> --- a/client/map.c
> +++ b/client/map.c
> @@ -400,7 +400,7 @@ static void parse_size(struct map_msg *msg, const char *value,
> static void parse_priority(struct map_msg *msg, const char *value,
> DBusMessageIter *iter)
> {
> - gboolean flag = strcasecmp(value, "no");
> + gboolean flag = strcasecmp(value, "no") != 0;
>
> if (flag)
> msg->flags |= MAP_MSG_FLAG_PRIORITY;
> @@ -413,7 +413,7 @@ static void parse_priority(struct map_msg *msg, const char *value,
> static void parse_read(struct map_msg *msg, const char *value,
> DBusMessageIter *iter)
> {
> - gboolean flag = strcasecmp(value, "no");
> + gboolean flag = strcasecmp(value, "no") != 0;
>
> if (flag)
> msg->flags |= MAP_MSG_FLAG_READ;
> @@ -426,7 +426,7 @@ static void parse_read(struct map_msg *msg, const char *value,
> static void parse_sent(struct map_msg *msg, const char *value,
> DBusMessageIter *iter)
> {
> - gboolean flag = strcasecmp(value, "no");
> + gboolean flag = strcasecmp(value, "no") != 0;
>
> if (flag)
> msg->flags |= MAP_MSG_FLAG_SENT;
> @@ -439,7 +439,7 @@ static void parse_sent(struct map_msg *msg, const char *value,
> static void parse_protected(struct map_msg *msg, const char *value,
> DBusMessageIter *iter)
> {
> - gboolean flag = strcasecmp(value, "no");
> + gboolean flag = strcasecmp(value, "no") != 0;
>
> if (flag)
> msg->flags |= MAP_MSG_FLAG_PROTECTED;
> --
> 1.7.7
Applied, thanks.
--
Luiz Augusto von Dentz
^ permalink raw reply
* [PATCH] gatt: Translate Characteristic names
From: chen.ganir @ 2012-08-29 9:06 UTC (permalink / raw)
To: linux-bluetooth; +Cc: chen.ganir
From: Chen Ganir <chen.ganir@ti.com>
Translate Characteristic UUID's to name. This list was taken from
the Bluetooth SIG developer site.
---
attrib/client.c | 77 +++++++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 75 insertions(+), 2 deletions(-)
diff --git a/attrib/client.c b/attrib/client.c
index bb6adf8..fc6a717 100644
--- a/attrib/client.c
+++ b/attrib/client.c
@@ -105,8 +105,79 @@ struct watcher {
struct gatt_service *gatt;
};
+struct CharacteristicNames {
+ char uuid[MAX_LEN_UUID_STR + 1];
+ char name[50];
+};
+
+static struct CharacteristicNames charNames[] = {
+ {"00002a43-0000-1000-8000-00805f9b34fb","Alert Category ID" },
+ {"00002a42-0000-1000-8000-00805f9b34fb","Alert Category ID Bit Mask" },
+ {"00002a06-0000-1000-8000-00805f9b34fb","Alert Level" },
+ {"00002a44-0000-1000-8000-00805f9b34fb","Alert Notification Control Point" },
+ {"00002a3f-0000-1000-8000-00805f9b34fb","Alert Status" },
+ {"00002a01-0000-1000-8000-00805f9b34fb","Appearance" },
+ {"00002a49-0000-1000-8000-00805f9b34fb","Blood Pressure Feature" },
+ {"00002a35-0000-1000-8000-00805f9b34fb","Blood Pressure Measurement" },
+ {"00002a38-0000-1000-8000-00805f9b34fb","Body Sensor Location" },
+ {"00002a2b-0000-1000-8000-00805f9b34fb","Current Time" },
+ {"00002a08-0000-1000-8000-00805f9b34fb","Date Time" },
+ {"00002a0a-0000-1000-8000-00805f9b34fb","Day Date Time" },
+ {"00002a09-0000-1000-8000-00805f9b34fb","Day of Week" },
+ {"00002a00-0000-1000-8000-00805f9b34fb","Device Name" },
+ {"00002a0d-0000-1000-8000-00805f9b34fb","DST Offset" },
+ {"00002a0c-0000-1000-8000-00805f9b34fb","Exact Time 256" },
+ {"00002a26-0000-1000-8000-00805f9b34fb","Firmware Revision String" },
+ {"00002a27-0000-1000-8000-00805f9b34fb","Hardware Revision String" },
+ {"00002a39-0000-1000-8000-00805f9b34fb","Heart Rate Control Point" },
+ {"00002a37-0000-1000-8000-00805f9b34fb","Heart Rate Measurement" },
+ {"00002a2a-0000-1000-8000-00805f9b34fb","IEEE 11073-20601 Regulatory" },
+ {"00002a36-0000-1000-8000-00805f9b34fb","Intermediate Cuff Pressure" },
+ {"00002a1e-0000-1000-8000-00805f9b34fb","Intermediate Temperature" },
+ {"00002a0f-0000-1000-8000-00805f9b34fb","Local Time Information" },
+ {"00002a29-0000-1000-8000-00805f9b34fb","Manufacturer Name String" },
+ {"00002a21-0000-1000-8000-00805f9b34fb","Measurement Interval" },
+ {"00002a24-0000-1000-8000-00805f9b34fb","Model Number String" },
+ {"00002a46-0000-1000-8000-00805f9b34fb","New Alert" },
+ {"00002a04-0000-1000-8000-00805f9b34fb","Peripheral Preferred Connection Parameters" },
+ {"00002a02-0000-1000-8000-00805f9b34fb","Peripheral Privacy Flag" },
+ {"00002a03-0000-1000-8000-00805f9b34fb","Reconnection Address" },
+ {"00002a14-0000-1000-8000-00805f9b34fb","Reference Time Information" },
+ {"00002a40-0000-1000-8000-00805f9b34fb","Ringer Control Point" },
+ {"00002a41-0000-1000-8000-00805f9b34fb","Ringer Setting" },
+ {"00002a25-0000-1000-8000-00805f9b34fb","Serial Number String" },
+ {"00002a05-0000-1000-8000-00805f9b34fb","Service Changed" },
+ {"00002a28-0000-1000-8000-00805f9b34fb","Software Revision String" },
+ {"00002a47-0000-1000-8000-00805f9b34fb","Supported New Alert Category" },
+ {"00002a48-0000-1000-8000-00805f9b34fb","Supported Unread Alert Category" },
+ {"00002a23-0000-1000-8000-00805f9b34fb","System ID" },
+ {"00002a1c-0000-1000-8000-00805f9b34fb","Temperature Measurement" },
+ {"00002a1d-0000-1000-8000-00805f9b34fb","Temperature Type" },
+ {"00002a12-0000-1000-8000-00805f9b34fb","Time Accuracy" },
+ {"00002a13-0000-1000-8000-00805f9b34fb","Time Source" },
+ {"00002a16-0000-1000-8000-00805f9b34fb","Time Update Control Point" },
+ {"00002a17-0000-1000-8000-00805f9b34fb","Time Update State" },
+ {"00002a11-0000-1000-8000-00805f9b34fb","Time with DST" },
+ {"00002a0e-0000-1000-8000-00805f9b34fb","Time Zone" },
+ {"00002a07-0000-1000-8000-00805f9b34fb","Tx Power Level" },
+ {"00002a45-0000-1000-8000-00805f9b34fb","Unread Alert Status" },
+};
+
static GSList *gatt_services = NULL;
+static const char* get_char_name(const char* uuid)
+{
+ uint8_t i = 0;
+ uint8_t count = sizeof(charNames) / sizeof(struct CharacteristicNames);
+
+ for (i = 0; i < count; i++) {
+ if(g_strcmp0(charNames[i].uuid, uuid) == 0) {
+ return charNames[i].name;
+ }
+ }
+ return NULL;
+}
+
static void characteristic_free(void *user_data)
{
struct characteristic *chr = user_data;
@@ -202,8 +273,10 @@ static void append_char_dict(DBusMessageIter *iter, struct characteristic *chr)
dict_append_entry(&dict, "UUID", DBUS_TYPE_STRING, &uuid);
g_free(uuid);
- /* FIXME: Translate UUID to name. */
- dict_append_entry(&dict, "Name", DBUS_TYPE_STRING, &name);
+ name = get_char_name(chr->type);
+
+ if (name != NULL)
+ dict_append_entry(&dict, "Name", DBUS_TYPE_STRING, &name);
if (chr->desc)
dict_append_entry(&dict, "Description", DBUS_TYPE_STRING,
--
1.7.9.5
^ permalink raw reply related
* [PATCH obexd] client: Add parameters to get message in map module
From: Frédéric Danis @ 2012-08-29 9:39 UTC (permalink / raw)
To: linux-bluetooth
GetMessage function needs attachment and charset application params
---
client/map.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/client/map.c b/client/map.c
index 4f07fcb..fa27c21 100644
--- a/client/map.c
+++ b/client/map.c
@@ -29,6 +29,8 @@
#include <glib.h>
#include <gdbus.h>
+#include <gobex/gobex-apparam.h>
+
#include "dbus.h"
#include "log.h"
@@ -36,6 +38,7 @@
#include "transfer.h"
#include "session.h"
#include "driver.h"
+#include "map_ap.h"
#define OBEX_MAS_UUID \
"\xBB\x58\x2B\x40\x42\x0C\x11\xDB\xB0\xDE\x08\x00\x20\x0C\x9A\x66"
@@ -258,6 +261,9 @@ static DBusMessage *map_msg_get(DBusConnection *connection,
struct map_msg *msg = user_data;
struct obc_transfer *transfer;
const char *target_file;
+ GObexApparam *apparam;
+ guint8 buf[6];
+ gsize len;
GError *err = NULL;
DBusMessage *reply;
@@ -272,6 +278,14 @@ static DBusMessage *map_msg_get(DBusConnection *connection,
if (transfer == NULL)
goto fail;
+ apparam = g_obex_apparam_set_uint8(NULL, MAP_AP_ATTACHMENT, 0);
+ apparam = g_obex_apparam_set_uint8(apparam, MAP_AP_CHARSET, 1);
+ len = g_obex_apparam_encode(apparam, buf, sizeof(buf));
+
+ obc_transfer_set_params(transfer, buf, len);
+
+ g_obex_apparam_free(apparam);
+
if (!obc_session_queue(msg->data->session, transfer, NULL, NULL, &err))
goto fail;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v2 01/13] Heart Rate Profile API
From: Garbat Rafal @ 2012-08-29 9:42 UTC (permalink / raw)
To: Anderson Lizardo
Cc: linux-bluetooth@vger.kernel.org, Santiago Carot-Nemesio,
Johan Hedberg
In-Reply-To: <CAJdJm_NTTyaKhmgnYJc40xpPLTRwAJ9EkLKCH67nmMJU8KvE+w@mail.gmail.com>
Hi,
On 08/28/2012 09:21 PM, Anderson Lizardo wrote:
> Hi,
>
> After some discussion with Johan on IRC, I think I understand what he
> is proposing, and it makes sense IMHO. The idea is to simply replace
> the object path for RegisterWatcher/UnregisterWatcher to [variable
> prefix]/{hci0,hci1,...} (adapter path) and have the watcher object
> methods accept a "object device" as first argument.
>
> This way, the application that wants to register wacthers will monitor
> only for new adapters (and not new devices) and register watchers on
> them. The D-Bus interface for RegisterWatcher() will still be profile
> specific (e.g. org.bluez.HeartRate in this case).
>
> One issue with this idea (and which still needs to be sorted out if we
> proceed with this), is that other methods specific to the profile
> (like Reset() for Heart Rate and EnableIntermediateMeasurement() for
> Thermometer) need to be in different interfaces.
>
> Johan, do you have any ideas for this?
>
> Regards,
I guess, that with such approach, the HeartRate API could look something
like this :
BlueZ D-Bus Heart Rate API description
****************************************
Copyright (C) 2012 Santiago Carot-Nemesio <sancane@gmail.com>
Heart Rate Manager hierarchy
============================
Service org.bluez
Interface org.bluez.HeartRateManager
Object path [variable prefix]/{hci0,hci1,...}
Methods RegisterWatcher(object agent)
Registers a watcher to monitor heart rate
measurements.
Possible Errors: org.bluez.Error.InvalidArguments
UnregisterWatcher(object agent)
Unregisters a watcher.
Heart Rate Profile hierarchy
============================
Service org.bluez
Interface org.bluez.HeartRate
Object path [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX
Methods dict GetProperties()
Returns all properties for the interface. See the
Properties section for the available properties.
Reset()
Restart the accumulation of energy expended
from zero.
Possible Errors: org.bluez.Error.NotSupported
Properties boolean ResetSupported [readonly]
True if energy expended is supported.
Heart Rate Watcher hierarchy
============================
Service unique name
Interface org.bluez.HeartRateWatcher
Object path freely definable
Methods void MeasurementReceived(object device, dict measure)
This callback is called whenever a heart rate
measurement is received from the heart rate device.
The unit for the Value is expressed in beats per
minute (bpm). The energy field is optional and
represents the accumulated energy expended in
kilo Joules since last time it was reset. Furthermore,
the device will be automatically reset when it
is needed.
The Contact field, if present, indicates
that the device supports contact sensor, besides it
will be true if skin contact is detected. The optional
interval field is an array containing RR-Interval
values which represent the time between two R-Wave
detections, where the RR-Interval value 0 is older
than the value 1 and so on.
Dict is defined as below:
{
"Value" : uint16,
"Energy" : uint16,
"Contact" : boolean,
"Location" : ("Other", "Chest", "Wrist","Finger",
"Hand", "Earlobe", "Foot"),
"Interval" : array{uint16}
}
Just a proposal, please comment.
Rafal
^ permalink raw reply
* Re: [PATCH] gatt: Translate Characteristic names
From: Szymon Janc @ 2012-08-29 10:09 UTC (permalink / raw)
To: chen.ganir@ti.com; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1346231191-16708-1-git-send-email-chen.ganir@ti.com>
On Wednesday 29 of August 2012 12:06:31 chen.ganir@ti.com wrote:
> From: Chen Ganir <chen.ganir@ti.com>
Hi Chen,
> +struct CharacteristicNames {
> + char uuid[MAX_LEN_UUID_STR + 1];
> + char name[50];
> +};
I would make it
struct CharacteristicNames {
const char *uuid;
const char *name;
};
> +
> +static struct CharacteristicNames charNames[] = {
constify charNames[]
> + {"00002a43-0000-1000-8000-00805f9b34fb","Alert Category ID" },
> + {"00002a42-0000-1000-8000-00805f9b34fb","Alert Category ID Bit Mask" },
> + {"00002a06-0000-1000-8000-00805f9b34fb","Alert Level" },
> + {"00002a44-0000-1000-8000-00805f9b34fb","Alert Notification Control Point" },
> + {"00002a3f-0000-1000-8000-00805f9b34fb","Alert Status" },
> + {"00002a01-0000-1000-8000-00805f9b34fb","Appearance" },
> + {"00002a49-0000-1000-8000-00805f9b34fb","Blood Pressure Feature" },
> + {"00002a35-0000-1000-8000-00805f9b34fb","Blood Pressure Measurement" },
> + {"00002a38-0000-1000-8000-00805f9b34fb","Body Sensor Location" },
> + {"00002a2b-0000-1000-8000-00805f9b34fb","Current Time" },
> + {"00002a08-0000-1000-8000-00805f9b34fb","Date Time" },
> + {"00002a0a-0000-1000-8000-00805f9b34fb","Day Date Time" },
> + {"00002a09-0000-1000-8000-00805f9b34fb","Day of Week" },
> + {"00002a00-0000-1000-8000-00805f9b34fb","Device Name" },
> + {"00002a0d-0000-1000-8000-00805f9b34fb","DST Offset" },
> + {"00002a0c-0000-1000-8000-00805f9b34fb","Exact Time 256" },
> + {"00002a26-0000-1000-8000-00805f9b34fb","Firmware Revision String" },
> + {"00002a27-0000-1000-8000-00805f9b34fb","Hardware Revision String" },
> + {"00002a39-0000-1000-8000-00805f9b34fb","Heart Rate Control Point" },
> + {"00002a37-0000-1000-8000-00805f9b34fb","Heart Rate Measurement" },
> + {"00002a2a-0000-1000-8000-00805f9b34fb","IEEE 11073-20601 Regulatory" },
> + {"00002a36-0000-1000-8000-00805f9b34fb","Intermediate Cuff Pressure" },
> + {"00002a1e-0000-1000-8000-00805f9b34fb","Intermediate Temperature" },
> + {"00002a0f-0000-1000-8000-00805f9b34fb","Local Time Information" },
> + {"00002a29-0000-1000-8000-00805f9b34fb","Manufacturer Name String" },
> + {"00002a21-0000-1000-8000-00805f9b34fb","Measurement Interval" },
> + {"00002a24-0000-1000-8000-00805f9b34fb","Model Number String" },
> + {"00002a46-0000-1000-8000-00805f9b34fb","New Alert" },
> + {"00002a04-0000-1000-8000-00805f9b34fb","Peripheral Preferred Connection Parameters" },
> + {"00002a02-0000-1000-8000-00805f9b34fb","Peripheral Privacy Flag" },
> + {"00002a03-0000-1000-8000-00805f9b34fb","Reconnection Address" },
> + {"00002a14-0000-1000-8000-00805f9b34fb","Reference Time Information" },
> + {"00002a40-0000-1000-8000-00805f9b34fb","Ringer Control Point" },
> + {"00002a41-0000-1000-8000-00805f9b34fb","Ringer Setting" },
> + {"00002a25-0000-1000-8000-00805f9b34fb","Serial Number String" },
> + {"00002a05-0000-1000-8000-00805f9b34fb","Service Changed" },
> + {"00002a28-0000-1000-8000-00805f9b34fb","Software Revision String" },
> + {"00002a47-0000-1000-8000-00805f9b34fb","Supported New Alert Category" },
> + {"00002a48-0000-1000-8000-00805f9b34fb","Supported Unread Alert Category" },
> + {"00002a23-0000-1000-8000-00805f9b34fb","System ID" },
> + {"00002a1c-0000-1000-8000-00805f9b34fb","Temperature Measurement" },
> + {"00002a1d-0000-1000-8000-00805f9b34fb","Temperature Type" },
> + {"00002a12-0000-1000-8000-00805f9b34fb","Time Accuracy" },
> + {"00002a13-0000-1000-8000-00805f9b34fb","Time Source" },
> + {"00002a16-0000-1000-8000-00805f9b34fb","Time Update Control Point" },
> + {"00002a17-0000-1000-8000-00805f9b34fb","Time Update State" },
> + {"00002a11-0000-1000-8000-00805f9b34fb","Time with DST" },
> + {"00002a0e-0000-1000-8000-00805f9b34fb","Time Zone" },
> + {"00002a07-0000-1000-8000-00805f9b34fb","Tx Power Level" },
> + {"00002a45-0000-1000-8000-00805f9b34fb","Unread Alert Status" },
> +};
> +
I would add { } at the end...
> static GSList *gatt_services = NULL;
>
> +static const char* get_char_name(const char* uuid)
this should be static const char *get_char_name(const char *uuid)
> +{
> + uint8_t i = 0;
> + uint8_t count = sizeof(charNames) / sizeof(struct CharacteristicNames);
> +
> + for (i = 0; i < count; i++) {
> + if(g_strcmp0(charNames[i].uuid, uuid) == 0) {
> + return charNames[i].name;
> + }
> + }
... and change this loop into to:
const struct CharacteristicNames *c;
for (c = charNames; c->uuid; c++) {
...
}
This will keep convention used.
> + return NULL;
> +}
> +
> static void characteristic_free(void *user_data)
> {
> struct characteristic *chr = user_data;
> @@ -202,8 +273,10 @@ static void append_char_dict(DBusMessageIter *iter, struct characteristic *chr)
> dict_append_entry(&dict, "UUID", DBUS_TYPE_STRING, &uuid);
> g_free(uuid);
>
> - /* FIXME: Translate UUID to name. */
> - dict_append_entry(&dict, "Name", DBUS_TYPE_STRING, &name);
> + name = get_char_name(chr->type);
> +
> + if (name != NULL)
> + dict_append_entry(&dict, "Name", DBUS_TYPE_STRING, &name);
With that there is no need to initialize name to "" so this could be also
part of a patch.
If get_char_name() returned empty string instead of NULL if matching uuid is
not found we could append empty string as Name (as it is now), but not sure
what is better - append empty name or not append.
>
> if (chr->desc)
> dict_append_entry(&dict, "Description", DBUS_TYPE_STRING,
>
--
BR
Szymon Janc
^ permalink raw reply
* [PATCH v2] gatt: Translate Characteristic names
From: chen.ganir @ 2012-08-29 10:56 UTC (permalink / raw)
To: linux-bluetooth; +Cc: chen.ganir
From: Chen Ganir <chen.ganir@ti.com>
Translate Characteristic UUID's to name. This list was taken from
the Bluetooth SIG developer site.
---
attrib/client.c | 83 +++++++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 80 insertions(+), 3 deletions(-)
diff --git a/attrib/client.c b/attrib/client.c
index bb6adf8..4ef74b5 100644
--- a/attrib/client.c
+++ b/attrib/client.c
@@ -105,8 +105,79 @@ struct watcher {
struct gatt_service *gatt;
};
+struct characteristic_info {
+ const char *uuid;
+ const char *name;
+};
+
+static const struct characteristic_info charInfo[] = {
+ {"00002a43-0000-1000-8000-00805f9b34fb","Alert Category ID" },
+ {"00002a42-0000-1000-8000-00805f9b34fb","Alert Category ID Bit Mask" },
+ {"00002a06-0000-1000-8000-00805f9b34fb","Alert Level" },
+ {"00002a44-0000-1000-8000-00805f9b34fb","Alert Notification Control Point" },
+ {"00002a3f-0000-1000-8000-00805f9b34fb","Alert Status" },
+ {"00002a01-0000-1000-8000-00805f9b34fb","Appearance" },
+ {"00002a49-0000-1000-8000-00805f9b34fb","Blood Pressure Feature" },
+ {"00002a35-0000-1000-8000-00805f9b34fb","Blood Pressure Measurement" },
+ {"00002a38-0000-1000-8000-00805f9b34fb","Body Sensor Location" },
+ {"00002a2b-0000-1000-8000-00805f9b34fb","Current Time" },
+ {"00002a08-0000-1000-8000-00805f9b34fb","Date Time" },
+ {"00002a0a-0000-1000-8000-00805f9b34fb","Day Date Time" },
+ {"00002a09-0000-1000-8000-00805f9b34fb","Day of Week" },
+ {"00002a00-0000-1000-8000-00805f9b34fb","Device Name" },
+ {"00002a0d-0000-1000-8000-00805f9b34fb","DST Offset" },
+ {"00002a0c-0000-1000-8000-00805f9b34fb","Exact Time 256" },
+ {"00002a26-0000-1000-8000-00805f9b34fb","Firmware Revision String" },
+ {"00002a27-0000-1000-8000-00805f9b34fb","Hardware Revision String" },
+ {"00002a39-0000-1000-8000-00805f9b34fb","Heart Rate Control Point" },
+ {"00002a37-0000-1000-8000-00805f9b34fb","Heart Rate Measurement" },
+ {"00002a2a-0000-1000-8000-00805f9b34fb","IEEE 11073-20601 Regulatory" },
+ {"00002a36-0000-1000-8000-00805f9b34fb","Intermediate Cuff Pressure" },
+ {"00002a1e-0000-1000-8000-00805f9b34fb","Intermediate Temperature" },
+ {"00002a0f-0000-1000-8000-00805f9b34fb","Local Time Information" },
+ {"00002a29-0000-1000-8000-00805f9b34fb","Manufacturer Name String" },
+ {"00002a21-0000-1000-8000-00805f9b34fb","Measurement Interval" },
+ {"00002a24-0000-1000-8000-00805f9b34fb","Model Number String" },
+ {"00002a46-0000-1000-8000-00805f9b34fb","New Alert" },
+ {"00002a04-0000-1000-8000-00805f9b34fb","Peripheral Preferred Connection Parameters" },
+ {"00002a02-0000-1000-8000-00805f9b34fb","Peripheral Privacy Flag" },
+ {"00002a03-0000-1000-8000-00805f9b34fb","Reconnection Address" },
+ {"00002a14-0000-1000-8000-00805f9b34fb","Reference Time Information" },
+ {"00002a40-0000-1000-8000-00805f9b34fb","Ringer Control Point" },
+ {"00002a41-0000-1000-8000-00805f9b34fb","Ringer Setting" },
+ {"00002a25-0000-1000-8000-00805f9b34fb","Serial Number String" },
+ {"00002a05-0000-1000-8000-00805f9b34fb","Service Changed" },
+ {"00002a28-0000-1000-8000-00805f9b34fb","Software Revision String" },
+ {"00002a47-0000-1000-8000-00805f9b34fb","Supported New Alert Category" },
+ {"00002a48-0000-1000-8000-00805f9b34fb","Supported Unread Alert Category" },
+ {"00002a23-0000-1000-8000-00805f9b34fb","System ID" },
+ {"00002a1c-0000-1000-8000-00805f9b34fb","Temperature Measurement" },
+ {"00002a1d-0000-1000-8000-00805f9b34fb","Temperature Type" },
+ {"00002a12-0000-1000-8000-00805f9b34fb","Time Accuracy" },
+ {"00002a13-0000-1000-8000-00805f9b34fb","Time Source" },
+ {"00002a16-0000-1000-8000-00805f9b34fb","Time Update Control Point" },
+ {"00002a17-0000-1000-8000-00805f9b34fb","Time Update State" },
+ {"00002a11-0000-1000-8000-00805f9b34fb","Time with DST" },
+ {"00002a0e-0000-1000-8000-00805f9b34fb","Time Zone" },
+ {"00002a07-0000-1000-8000-00805f9b34fb","Tx Power Level" },
+ {"00002a45-0000-1000-8000-00805f9b34fb","Unread Alert Status" },
+ { }
+};
+
static GSList *gatt_services = NULL;
+static const struct characteristic_info *get_char_info(const char* uuid)
+{
+ const struct characteristic_info *c;
+
+ for (c = charInfo; c->uuid; c++) {
+ if(g_strcmp0(c->uuid, uuid) == 0) {
+ return c;
+ }
+ }
+ return NULL;
+}
+
static void characteristic_free(void *user_data)
{
struct characteristic *chr = user_data;
@@ -190,7 +261,7 @@ static int watcher_cmp(gconstpointer a, gconstpointer b)
static void append_char_dict(DBusMessageIter *iter, struct characteristic *chr)
{
DBusMessageIter dict;
- const char *name = "";
+ const struct characteristic_info *char_info;
char *uuid;
dbus_message_iter_open_container(iter, DBUS_TYPE_ARRAY,
@@ -202,8 +273,14 @@ static void append_char_dict(DBusMessageIter *iter, struct characteristic *chr)
dict_append_entry(&dict, "UUID", DBUS_TYPE_STRING, &uuid);
g_free(uuid);
- /* FIXME: Translate UUID to name. */
- dict_append_entry(&dict, "Name", DBUS_TYPE_STRING, &name);
+ char_info = get_char_info(chr->type);
+
+ if (char_info != NULL) {
+ const char *name = char_info->name;
+ if (name != NULL)
+ dict_append_entry(&dict, "Name", DBUS_TYPE_STRING, &name);
+ }
+
if (chr->desc)
dict_append_entry(&dict, "Description", DBUS_TYPE_STRING,
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] gatt: Translate Characteristic names
From: Chen Ganir @ 2012-08-29 10:56 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <2328157.cIbN4hMyx7@uw000953>
Szymon,
On 08/29/2012 01:09 PM, Szymon Janc wrote:
> On Wednesday 29 of August 2012 12:06:31 chen.ganir@ti.com wrote:
>> From: Chen Ganir <chen.ganir@ti.com>
>
> Hi Chen,
>
>
>> +struct CharacteristicNames {
>> + char uuid[MAX_LEN_UUID_STR + 1];
>> + char name[50];
>> +};
>
> I would make it
> struct CharacteristicNames {
> const char *uuid;
> const char *name;
> };
>
Ok.
>> +
>> +static struct CharacteristicNames charNames[] = {
>
> constify charNames[]
>
>> + {"00002a43-0000-1000-8000-00805f9b34fb","Alert Category ID" },
>> + {"00002a42-0000-1000-8000-00805f9b34fb","Alert Category ID Bit Mask" },
>> + {"00002a06-0000-1000-8000-00805f9b34fb","Alert Level" },
>> + {"00002a44-0000-1000-8000-00805f9b34fb","Alert Notification Control Point" },
>> + {"00002a3f-0000-1000-8000-00805f9b34fb","Alert Status" },
>> + {"00002a01-0000-1000-8000-00805f9b34fb","Appearance" },
>> + {"00002a49-0000-1000-8000-00805f9b34fb","Blood Pressure Feature" },
>> + {"00002a35-0000-1000-8000-00805f9b34fb","Blood Pressure Measurement" },
>> + {"00002a38-0000-1000-8000-00805f9b34fb","Body Sensor Location" },
>> + {"00002a2b-0000-1000-8000-00805f9b34fb","Current Time" },
>> + {"00002a08-0000-1000-8000-00805f9b34fb","Date Time" },
>> + {"00002a0a-0000-1000-8000-00805f9b34fb","Day Date Time" },
>> + {"00002a09-0000-1000-8000-00805f9b34fb","Day of Week" },
>> + {"00002a00-0000-1000-8000-00805f9b34fb","Device Name" },
>> + {"00002a0d-0000-1000-8000-00805f9b34fb","DST Offset" },
>> + {"00002a0c-0000-1000-8000-00805f9b34fb","Exact Time 256" },
>> + {"00002a26-0000-1000-8000-00805f9b34fb","Firmware Revision String" },
>> + {"00002a27-0000-1000-8000-00805f9b34fb","Hardware Revision String" },
>> + {"00002a39-0000-1000-8000-00805f9b34fb","Heart Rate Control Point" },
>> + {"00002a37-0000-1000-8000-00805f9b34fb","Heart Rate Measurement" },
>> + {"00002a2a-0000-1000-8000-00805f9b34fb","IEEE 11073-20601 Regulatory" },
>> + {"00002a36-0000-1000-8000-00805f9b34fb","Intermediate Cuff Pressure" },
>> + {"00002a1e-0000-1000-8000-00805f9b34fb","Intermediate Temperature" },
>> + {"00002a0f-0000-1000-8000-00805f9b34fb","Local Time Information" },
>> + {"00002a29-0000-1000-8000-00805f9b34fb","Manufacturer Name String" },
>> + {"00002a21-0000-1000-8000-00805f9b34fb","Measurement Interval" },
>> + {"00002a24-0000-1000-8000-00805f9b34fb","Model Number String" },
>> + {"00002a46-0000-1000-8000-00805f9b34fb","New Alert" },
>> + {"00002a04-0000-1000-8000-00805f9b34fb","Peripheral Preferred Connection Parameters" },
>> + {"00002a02-0000-1000-8000-00805f9b34fb","Peripheral Privacy Flag" },
>> + {"00002a03-0000-1000-8000-00805f9b34fb","Reconnection Address" },
>> + {"00002a14-0000-1000-8000-00805f9b34fb","Reference Time Information" },
>> + {"00002a40-0000-1000-8000-00805f9b34fb","Ringer Control Point" },
>> + {"00002a41-0000-1000-8000-00805f9b34fb","Ringer Setting" },
>> + {"00002a25-0000-1000-8000-00805f9b34fb","Serial Number String" },
>> + {"00002a05-0000-1000-8000-00805f9b34fb","Service Changed" },
>> + {"00002a28-0000-1000-8000-00805f9b34fb","Software Revision String" },
>> + {"00002a47-0000-1000-8000-00805f9b34fb","Supported New Alert Category" },
>> + {"00002a48-0000-1000-8000-00805f9b34fb","Supported Unread Alert Category" },
>> + {"00002a23-0000-1000-8000-00805f9b34fb","System ID" },
>> + {"00002a1c-0000-1000-8000-00805f9b34fb","Temperature Measurement" },
>> + {"00002a1d-0000-1000-8000-00805f9b34fb","Temperature Type" },
>> + {"00002a12-0000-1000-8000-00805f9b34fb","Time Accuracy" },
>> + {"00002a13-0000-1000-8000-00805f9b34fb","Time Source" },
>> + {"00002a16-0000-1000-8000-00805f9b34fb","Time Update Control Point" },
>> + {"00002a17-0000-1000-8000-00805f9b34fb","Time Update State" },
>> + {"00002a11-0000-1000-8000-00805f9b34fb","Time with DST" },
>> + {"00002a0e-0000-1000-8000-00805f9b34fb","Time Zone" },
>> + {"00002a07-0000-1000-8000-00805f9b34fb","Tx Power Level" },
>> + {"00002a45-0000-1000-8000-00805f9b34fb","Unread Alert Status" },
>> +};
>> +
>
> I would add { } at the end...
Ok.
>
>> static GSList *gatt_services = NULL;
>>
>> +static const char* get_char_name(const char* uuid)
>
> this should be static const char *get_char_name(const char *uuid)
>
Ok.
>> +{
>> + uint8_t i = 0;
>> + uint8_t count = sizeof(charNames) / sizeof(struct CharacteristicNames);
>> +
>> + for (i = 0; i < count; i++) {
>> + if(g_strcmp0(charNames[i].uuid, uuid) == 0) {
>> + return charNames[i].name;
>> + }
>> + }
>
> ... and change this loop into to:
>
> const struct CharacteristicNames *c;
>
> for (c = charNames; c->uuid; c++) {
> ...
> }
>
Ok.
> This will keep convention used.
>
>> + return NULL;
>> +}
>> +
>> static void characteristic_free(void *user_data)
>> {
>> struct characteristic *chr = user_data;
>> @@ -202,8 +273,10 @@ static void append_char_dict(DBusMessageIter *iter, struct characteristic *chr)
>> dict_append_entry(&dict, "UUID", DBUS_TYPE_STRING, &uuid);
>> g_free(uuid);
>>
>> - /* FIXME: Translate UUID to name. */
>> - dict_append_entry(&dict, "Name", DBUS_TYPE_STRING, &name);
>> + name = get_char_name(chr->type);
>> +
>> + if (name != NULL)
>> + dict_append_entry(&dict, "Name", DBUS_TYPE_STRING, &name);
>
> With that there is no need to initialize name to "" so this could be also
> part of a patch.
>
> If get_char_name() returned empty string instead of NULL if matching uuid is
> not found we could append empty string as Name (as it is now), but not sure
> what is better - append empty name or not append.
>
I will remove the initialization of name. I believe not appending an
empty string is much more suitable than sending a property with an empty
string.
>>
>> if (chr->desc)
>> dict_append_entry(&dict, "Description", DBUS_TYPE_STRING,
>>
>
BR,
Chen Ganir
^ permalink raw reply
* Re: Which software is responsible for bringing the devices (hci0 .. hcix) up ?
From: Andrei Emeltchenko @ 2012-08-29 10:58 UTC (permalink / raw)
To: Vellemans, Noel; +Cc: linux-bluetooth
In-Reply-To: <1531E53627F1F749B4FE809BF2A4EB67036F2FD3@WETMEX10.loepfe.com>
Hi,
On Wed, Aug 29, 2012 at 09:49:14AM +0200, Vellemans, Noel wrote:
> Hi,
>
> >> Do you have bluetoothd running?
>
> OK : You've got it.. I think.
>
> When looking into the process-list with ps , I don't see bluetoothd.
>
> When starting Bluetoothd on the command line .. . before plugging in the
> device ..
> the the device is 'UP' like it should be... (you are guiding/pointing me
> in the GOOD direction, thankx)
>
>
> Next question (Sorry) ? Isn't bluetoothd supposed to be launched by udev
> ?
>
> Or I'm I missing some startup-script (/etc/init.d/... ) ?
>
> I just wonder is there somewhere a description on how bleuz (bluetooth)
> is started at boot ?
This depends on your distro, I personally run it manually. I think you
need to enable it via some bluetooth-applet.
Best regards
Andrei Emeltchenko
^ permalink raw reply
* [PATCH obexd] MAP: Add SetMessageStatus function
From: Sunil Kumar Behera @ 2012-08-29 11:18 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Sunil Kumar Behera
SetMessageStatus function allows the MCE to modify the status
of a message on the MSE. This function modifies the read and
delete status of the message.
---
plugins/mas.c | 52 +++++++++++++++++++++++++++++++++++++++++++-
plugins/messages-dummy.c | 8 +++++++
plugins/messages-tracker.c | 8 +++++++
plugins/messages.h | 20 +++++++++++++++++
4 files changed, 87 insertions(+), 1 deletion(-)
diff --git a/plugins/mas.c b/plugins/mas.c
index 1c9199d..26e8f7d 100644
--- a/plugins/mas.c
+++ b/plugins/mas.c
@@ -499,6 +499,20 @@ static void update_inbox_cb(void *session, int err, void *user_data)
obex_object_set_io_flags(mas, G_IO_OUT, 0);
}
+static void message_status_cb(void *session, int err, void *user_data)
+{
+ struct mas_session *mas = user_data;
+
+ DBG("");
+
+ mas->finished = TRUE;
+
+ if (err < 0)
+ obex_object_set_io_flags(mas, G_IO_ERR, err);
+ else
+ obex_object_set_io_flags(mas, G_IO_OUT, 0);
+}
+
static int mas_setpath(struct obex_session *os, void *user_data)
{
const char *name;
@@ -649,6 +663,42 @@ static void *message_update_open(const char *name, int oflag, mode_t mode,
return mas;
}
+static void *message_status_open(const char *name, int oflag, mode_t mode,
+ void *driver_data, size_t *size,
+ int *err)
+
+{
+ struct mas_session *mas = driver_data;
+ uint8_t indicator;
+ uint8_t value;
+
+ DBG("");
+
+ if (oflag == O_RDONLY) {
+ *err = -EBADR;
+ return NULL;
+ }
+
+ if (!g_obex_apparam_get_uint8(mas->inparams, MAP_AP_STATUSINDICATOR,
+ &indicator)) {
+ *err = -EBADR;
+ return NULL;
+ }
+
+ if (!g_obex_apparam_get_uint8(mas->inparams, MAP_AP_STATUSVALUE,
+ &value)) {
+ *err = -EBADR;
+ return NULL;
+ }
+
+ *err = messages_set_message_status(mas->backend_data, name, indicator,
+ value, message_status_cb, mas);
+ if (*err < 0)
+ return NULL;
+ else
+ return mas;
+}
+
static ssize_t any_get_next_header(void *object, void *buf, size_t mtu,
uint8_t *hi)
{
@@ -784,7 +834,7 @@ static struct obex_mime_type_driver mime_message_status = {
.target = MAS_TARGET,
.target_size = TARGET_SIZE,
.mimetype = "x-bt/messageStatus",
- .open = any_open,
+ .open = message_status_open,
.close = any_close,
.read = any_read,
.write = any_write,
diff --git a/plugins/messages-dummy.c b/plugins/messages-dummy.c
index a47f143..1a38d0d 100644
--- a/plugins/messages-dummy.c
+++ b/plugins/messages-dummy.c
@@ -347,6 +347,14 @@ int messages_get_message(void *session, const char *handle,
return -ENOSYS;
}
+int messages_set_message_status(void *session, const char *handle,
+ int indicator, int value,
+ messages_set_message_status_cb callback,
+ void *user_data)
+{
+ return -ENOSYS;
+}
+
int messages_update_inbox(void *session, messages_update_inbox_cb callback,
void *user_data)
{
diff --git a/plugins/messages-tracker.c b/plugins/messages-tracker.c
index 92c1767..7bdba1b 100644
--- a/plugins/messages-tracker.c
+++ b/plugins/messages-tracker.c
@@ -321,6 +321,14 @@ int messages_get_message(void *session, const char *handle,
return -ENOSYS;
}
+int messages_set_message_status(void *session, const char *handle,
+ int indicator, int value,
+ messages_set_message_status_cb callback,
+ void *user_data)
+{
+ return -ENOSYS;
+}
+
int messages_update_inbox(void *session, messages_update_inbox_cb callback,
void *user_data)
{
diff --git a/plugins/messages.h b/plugins/messages.h
index 669f7c2..9805bb0 100644
--- a/plugins/messages.h
+++ b/plugins/messages.h
@@ -268,6 +268,26 @@ int messages_get_message(void *session, const char *handle,
messages_get_message_cb callback,
void *user_data);
+/* Informs Message Server to modify status of a given message.
+ *
+ * session: Backend session.
+ * handle: Unique identifier to the message.
+ * indicator: To indicate which status information is to be modified,
+ * "readStatus" or "deleteStatus".
+ * value: To indicate the value of the indicator
+ * read/unread for "readstatus" and deleted/undeleted for "deleteStatus".
+ * Callback shall be called for every message status update request
+ * recieved from MCE.
+ * user_data: User data if any to be sent.
+ */
+typedef void (*messages_set_message_status_cb)(void *session, int err,
+ void *user_data);
+
+int messages_set_message_status(void *session, const char *handle,
+ int indicator, int value,
+ messages_set_message_status_cb callback,
+ void *user_data);
+
/* Informs Message Server to Update Inbox via network.
*
* session: Backend session.
--
1.7.9.5
^ permalink raw reply related
* [PATCH 4/7] net/bluetooth/rfcomm/core.c: fix error return code
From: Julia Lawall @ 2012-08-29 16:49 UTC (permalink / raw)
To: Marcel Holtmann
Cc: kernel-janitors, Gustavo Padovan, Johan Hedberg, David S. Miller,
linux-bluetooth, netdev, linux-kernel
In-Reply-To: <1346258957-7649-1-git-send-email-Julia.Lawall@lip6.fr>
From: Julia Lawall <Julia.Lawall@lip6.fr>
Initialize return variable before exiting on an error path.
A simplified version of the semantic match that finds this problem is as
follows: (http://coccinelle.lip6.fr/)
// <smpl>
(
if@p1 (\(ret < 0\|ret != 0\))
{ ... return ret; }
|
ret@p1 = 0
)
... when != ret = e1
when != &ret
*if(...)
{
... when != ret = e2
when forall
return ret;
}
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
net/bluetooth/rfcomm/core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index c75107e..30141c0 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -2010,8 +2010,10 @@ static int rfcomm_add_listener(bdaddr_t *ba)
/* Add listening session */
s = rfcomm_session_add(sock, BT_LISTEN);
- if (!s)
+ if (!s) {
+ err = -ENOMEM;
goto failed;
+ }
rfcomm_session_hold(s);
return 0;
^ permalink raw reply related
* Re: [RFC 4/5] Bluetooth: Add set broadcaster MGMT command
From: Aloisio Almeida @ 2012-08-29 17:42 UTC (permalink / raw)
To: Jefferson Delfes, linux-bluetooth
In-Reply-To: <20120814091317.GA1083@x220>
Hi Johan,
It was decided to have broadcaster/observer in BR/EDR also. I think it
was decided in the Bluez meeting, right?
For now we're thinking in use this on BR/EDR only controllers. Dual
mode controllers would use LE for broadcasting.
I'm working on adding this feature right now. Further I'll send the v2.
Aloisio
On Tue, Aug 14, 2012 at 6:13 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Jefferson,
>
> On Fri, Aug 10, 2012, Jefferson Delfes wrote:
>> --- a/net/bluetooth/mgmt.c
>> +++ b/net/bluetooth/mgmt.c
>> @@ -379,6 +379,7 @@ static u32 get_supported_settings(struct hci_dev *hdev)
>> settings |= MGMT_SETTING_FAST_CONNECTABLE;
>> settings |= MGMT_SETTING_DISCOVERABLE;
>> settings |= MGMT_SETTING_PAIRABLE;
>> + settings |= MGMT_SETTING_BROADCASTER;
>
> Shouldn't this be behind the same conditional as MGMT_SETTING_LE? I.e.
> only when hdev->features indicates LE support.
>
> Johan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 01/13] Heart Rate Profile API
From: Anderson Lizardo @ 2012-08-29 17:54 UTC (permalink / raw)
To: Garbat Rafal
Cc: linux-bluetooth@vger.kernel.org, Santiago Carot-Nemesio,
Johan Hedberg
In-Reply-To: <503DE40F.1050008@tieto.com>
Hi Rafal,
> I guess, that with such approach, the HeartRate API could look something
> like this :
> [snip]
> Just a proposal, please comment.
This is my understanding as well. But I'll wait for Johan to comment
to make sure we fully understood the idea.
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
^ permalink raw reply
* Re: [PATCH v2 01/13] Heart Rate Profile API
From: Johan Hedberg @ 2012-08-29 17:57 UTC (permalink / raw)
To: Anderson Lizardo
Cc: Garbat Rafal, linux-bluetooth@vger.kernel.org,
Santiago Carot-Nemesio
In-Reply-To: <CAJdJm_O2KyJ=2Rw6BcA2By_7W=Bqt_EzCwNJKcqZjWy+3W3HDQ@mail.gmail.com>
Hi Lizardo,
On Wed, Aug 29, 2012, Anderson Lizardo wrote:
> Hi Rafal,
>
> > I guess, that with such approach, the HeartRate API could look something
> > like this :
> > [snip]
> > Just a proposal, please comment.
>
> This is my understanding as well. But I'll wait for Johan to comment
> to make sure we fully understood the idea.
Looks more or less good to me.
Johan
^ permalink raw reply
* Re: [PATCH 4/7] net/bluetooth/rfcomm/core.c: fix error return code
From: Marcel Holtmann @ 2012-08-29 18:23 UTC (permalink / raw)
To: Julia Lawall
Cc: kernel-janitors, Gustavo Padovan, Johan Hedberg, David S. Miller,
linux-bluetooth, netdev, linux-kernel
In-Reply-To: <1346258957-7649-5-git-send-email-Julia.Lawall@lip6.fr>
Hi Julia,
> Initialize return variable before exiting on an error path.
>
> A simplified version of the semantic match that finds this problem is as
> follows: (http://coccinelle.lip6.fr/)
>
> // <smpl>
> (
> if@p1 (\(ret < 0\|ret != 0\))
> { ... return ret; }
> |
> ret@p1 = 0
> )
> ... when != ret = e1
> when != &ret
> *if(...)
> {
> ... when != ret = e2
> when forall
> return ret;
> }
>
> // </smpl>
>
> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
>
> ---
> net/bluetooth/rfcomm/core.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* [PATCH BlueZ v1 0/6] HoG Suspend/Resume
From: Claudio Takahasi @ 2012-08-29 20:53 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1345237703-15342-1-git-send-email-claudio.takahasi@openbossa.org>
This patch series adds HID Control Point support. This control point
allows the report host(BlueZ) to notify the report device(HoG device)
when the host is entering or leaving the Suspend Mode.
The low power Suspend Mode concept is implementation specific. This
proposal adds a selectable back-end for HoG Suspend/Resume control.
Each platform is free to write it's own HoG suspend back-end.
A dummy back-end based on a FIFO (/tmp/hogsuspend) is proposed for
reference and testing purpose only. Writting "suspend" or "resume"
in this FIFO will trigger the update of the HID Control Point.
Notify the HoG device is useful to save power. Devices can implement
different actions (diff than disconnect) when commands are written
on the HID control point. The HoG capable device cab reduce the key
press detection frequency or disable LEDs.
*** Changes from previous version:
Replaces UPower by a dummy selectable back-end. As discussed in IRC
tracking UPower "suspending" or "resuming" signals are not suitable
for desktops since the connection is dropped right after detecting
suspend.
Claudio Takahasi (6):
hog: Add initial files for suspend support
hog: Add suspend back-end selection
hog: Add suspend/resume callbacks declaration
hog: Create a FIFO for dummy suspend
hog: Move HoG device list to manager
hog: Add writting Control Point
Makefile.am | 6 +-
acinclude.m4 | 7 ++
profiles/input/hog_device.c | 73 ++++++++++++++-------
profiles/input/hog_device.h | 9 ++-
profiles/input/hog_manager.c | 62 ++++++++++++++++-
profiles/input/suspend-dummy.c | 146 +++++++++++++++++++++++++++++++++++++++++
profiles/input/suspend.h | 29 ++++++++
7 files changed, 302 insertions(+), 30 deletions(-)
create mode 100644 profiles/input/suspend-dummy.c
create mode 100644 profiles/input/suspend.h
--
1.7.12
^ permalink raw reply
* [PATCH BlueZ v1 1/6] hog: Add initial files for suspend support
From: Claudio Takahasi @ 2012-08-29 20:53 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1346273590-16693-1-git-send-email-claudio.takahasi@openbossa.org>
This patch adds the initial files to support HoG suspend. The suspend
concept for HoG is implementation specific. The proposal is allowing
back-end selection at build time. Each Linux distribution/platform is
responsible for defining and writting their own policy to manage suspend
on HoG capable devices.
When setting the Control Point, the report device can execute actions to
save power. eg: Reduce the cycle of the key press detection or disable
LEDs.
---
Makefile.am | 3 ++-
profiles/input/hog_manager.c | 14 ++++++++++++++
profiles/input/suspend-dummy.c | 38 ++++++++++++++++++++++++++++++++++++++
profiles/input/suspend.h | 26 ++++++++++++++++++++++++++
4 files changed, 80 insertions(+), 1 deletion(-)
create mode 100644 profiles/input/suspend-dummy.c
create mode 100644 profiles/input/suspend.h
diff --git a/Makefile.am b/Makefile.am
index 4977a05..f6eb96b 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -184,7 +184,8 @@ endif
if HOGPLUGIN
builtin_modules += hog
builtin_sources += profiles/input/hog_manager.c profiles/input/hog_device.h \
- profiles/input/hog_device.c profiles/input/uhid_copy.h
+ profiles/input/hog_device.c profiles/input/uhid_copy.h \
+ profiles/input/suspend-dummy.c profiles/input/suspend.h
endif
if NETWORKPLUGIN
diff --git a/profiles/input/hog_manager.c b/profiles/input/hog_manager.c
index c544e79..149ed34 100644
--- a/profiles/input/hog_manager.c
+++ b/profiles/input/hog_manager.c
@@ -35,8 +35,11 @@
#include "plugin.h"
#include "hcid.h"
#include "device.h"
+#include "suspend.h"
#include "hog_device.h"
+static gboolean suspend_supported = FALSE;
+
static int hog_device_probe(struct btd_device *device, GSList *uuids)
{
const char *path = device_get_path(device);
@@ -64,11 +67,22 @@ static struct btd_device_driver hog_driver = {
static int hog_manager_init(void)
{
+ int err;
+
+ err = suspend_init();
+ if (err < 0)
+ DBG("Suspend: %s(%d)", strerror(-err), -err);
+ else
+ suspend_supported = TRUE;
+
return btd_register_device_driver(&hog_driver);
}
static void hog_manager_exit(void)
{
+ if (suspend_supported)
+ suspend_exit();
+
btd_unregister_device_driver(&hog_driver);
}
diff --git a/profiles/input/suspend-dummy.c b/profiles/input/suspend-dummy.c
new file mode 100644
index 0000000..0a97158
--- /dev/null
+++ b/profiles/input/suspend-dummy.c
@@ -0,0 +1,38 @@
+/*
+ *
+ * BlueZ - Bluetooth protocol stack for Linux
+ *
+ * Copyright (C) 2012 Nordic Semiconductor Inc.
+ * Copyright (C) 2012 Instituto Nokia de Tecnologia - INdT
+ *
+ *
+ * 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 "suspend.h"
+
+int suspend_init(void)
+{
+ return 0;
+}
+
+void suspend_exit(void)
+{
+}
diff --git a/profiles/input/suspend.h b/profiles/input/suspend.h
new file mode 100644
index 0000000..3f37a29
--- /dev/null
+++ b/profiles/input/suspend.h
@@ -0,0 +1,26 @@
+/*
+ *
+ * BlueZ - Bluetooth protocol stack for Linux
+ *
+ * Copyright (C) 2012 Nordic Semiconductor Inc.
+ * Copyright (C) 2012 Instituto Nokia de Tecnologia - INdT
+ *
+ *
+ * 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
+ *
+ */
+
+int suspend_init(void);
+void suspend_exit(void);
--
1.7.12
^ permalink raw reply related
* [PATCH BlueZ v1 2/6] hog: Add suspend back-end selection
From: Claudio Takahasi @ 2012-08-29 20:53 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1346273590-16693-1-git-send-email-claudio.takahasi@openbossa.org>
This patch series introduces back-end selection for HoG suspend drivers.
The default back-end is called "dummy", added for testing purpose only.
---
Makefile.am | 3 +++
acinclude.m4 | 7 +++++++
2 files changed, 10 insertions(+)
diff --git a/Makefile.am b/Makefile.am
index f6eb96b..198515b 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -439,6 +439,9 @@ audio/telephony.c: audio/@TELEPHONY_DRIVER@
profiles/sap/sap.c: profiles/sap/@SAP_DRIVER@
$(AM_V_GEN)$(LN_S) $(abs_top_srcdir)/$< $@
+profiles/input/suspend.c: profiles/input/@HOG_SUSPEND_DRIVER@
+ $(AM_V_GEN)$(LN_S) $(abs_top_srcdir)/$< $@
+
scripts/%.rules:
$(AM_V_GEN)cp $(subst 97-,,$@) $@
diff --git a/acinclude.m4 b/acinclude.m4
index 39b0a18..ed2d011 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -185,6 +185,7 @@ AC_DEFUN([AC_ARG_BLUEZ], [
datafiles_enable=yes
telephony_driver=dummy
sap_driver=dummy
+ hog_suspend_driver=dummy
dbusoob_enable=no
wiimote_enable=no
gatt_enable=no
@@ -288,6 +289,12 @@ AC_DEFUN([AC_ARG_BLUEZ], [
wiimote_enable=${enableval}
])
+ AC_ARG_WITH(gatt, AC_HELP_STRING([--with-hog-suspend=DRIVER], [select HoG suspend driver]), [
+ hog_suspend_driver=${withval}
+ ])
+
+ AC_SUBST([HOG_SUSPEND_DRIVER], [suspend-${hog_suspend_driver}.c])
+
AC_ARG_ENABLE(gatt, AC_HELP_STRING([--enable-gatt], [enable gatt module]), [
gatt_enable=${enableval}
])
--
1.7.12
^ permalink raw reply related
* [PATCH BlueZ v1 3/6] hog: Add suspend/resume callbacks declaration
From: Claudio Takahasi @ 2012-08-29 20:53 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1346273590-16693-1-git-send-email-claudio.takahasi@openbossa.org>
This patch declares the callbacks functions that intend to be used
by the suspend back-ends.
---
profiles/input/hog_manager.c | 12 +++++++++++-
profiles/input/suspend-dummy.c | 10 +++++++++-
profiles/input/suspend.h | 5 ++++-
3 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/profiles/input/hog_manager.c b/profiles/input/hog_manager.c
index 149ed34..9c23980 100644
--- a/profiles/input/hog_manager.c
+++ b/profiles/input/hog_manager.c
@@ -40,6 +40,16 @@
static gboolean suspend_supported = FALSE;
+static void suspend_callback(void)
+{
+ DBG("Suspending ...");
+}
+
+static void resume_callback(void)
+{
+ DBG("Resuming ...");
+}
+
static int hog_device_probe(struct btd_device *device, GSList *uuids)
{
const char *path = device_get_path(device);
@@ -69,7 +79,7 @@ static int hog_manager_init(void)
{
int err;
- err = suspend_init();
+ err = suspend_init(suspend_callback, resume_callback);
if (err < 0)
DBG("Suspend: %s(%d)", strerror(-err), -err);
else
diff --git a/profiles/input/suspend-dummy.c b/profiles/input/suspend-dummy.c
index 0a97158..282d3fb 100644
--- a/profiles/input/suspend-dummy.c
+++ b/profiles/input/suspend-dummy.c
@@ -26,10 +26,18 @@
#include <config.h>
#endif
+#include <stdlib.h>
+
#include "suspend.h"
-int suspend_init(void)
+static suspend_event suspend_cb = NULL;
+static resume_event resume_cb = NULL;
+
+int suspend_init(suspend_event suspend, resume_event resume)
{
+ suspend_cb = suspend;
+ resume_cb = resume;
+
return 0;
}
diff --git a/profiles/input/suspend.h b/profiles/input/suspend.h
index 3f37a29..bfee3cf 100644
--- a/profiles/input/suspend.h
+++ b/profiles/input/suspend.h
@@ -22,5 +22,8 @@
*
*/
-int suspend_init(void);
+typedef void (*suspend_event) (void);
+typedef void (*resume_event) (void);
+
+int suspend_init(suspend_event suspend, resume_event resume);
void suspend_exit(void);
--
1.7.12
^ permalink raw reply related
* [PATCH BlueZ v1 4/6] hog: Create a FIFO for dummy suspend
From: Claudio Takahasi @ 2012-08-29 20:53 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1346273590-16693-1-git-send-email-claudio.takahasi@openbossa.org>
This patch creates a FIFO on "/tmp/hogsuspend" to allow the users to
test the HoG suspend(HID Control Point) when the dummy back-end is
enabled.
---
profiles/input/suspend-dummy.c | 102 ++++++++++++++++++++++++++++++++++++++++-
1 file changed, 101 insertions(+), 1 deletion(-)
diff --git a/profiles/input/suspend-dummy.c b/profiles/input/suspend-dummy.c
index 282d3fb..f2941fe 100644
--- a/profiles/input/suspend-dummy.c
+++ b/profiles/input/suspend-dummy.c
@@ -26,21 +26,121 @@
#include <config.h>
#endif
+#include <errno.h>
#include <stdlib.h>
+#include <stdio.h>
+#include <string.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <fcntl.h>
+#include <unistd.h>
+#include <glib.h>
+
+#include "log.h"
#include "suspend.h"
+#define HOG_SUSPEND_FIFO "/tmp/hogsuspend"
+
static suspend_event suspend_cb = NULL;
static resume_event resume_cb = NULL;
+static GIOChannel *fifoio = NULL;
+
+static int fifo_open(void);
+
+static gboolean read_fifo(GIOChannel *io, GIOCondition cond, gpointer user_data)
+{
+ gchar buffer[12];
+ gsize offset, left, bread;
+ GIOStatus iostatus;
+
+ if (cond & (G_IO_ERR | G_IO_HUP))
+ goto failed;
+
+ offset = 0;
+ left = sizeof(buffer) - 1;
+ memset(buffer, 0, sizeof(buffer));
+
+ do {
+ iostatus = g_io_channel_read_chars(io, &buffer[offset], left,
+ &bread, NULL);
+
+ offset += bread;
+ left -= bread;
+ if (left == 0)
+ break;
+ } while (iostatus == G_IO_STATUS_NORMAL);
+
+ if (g_ascii_strncasecmp("suspend", buffer, 7) == 0)
+ suspend_cb();
+ else if (g_ascii_strncasecmp("resume", buffer, 6) == 0)
+ resume_cb();
+
+ return TRUE;
+
+failed:
+ /*
+ * Both ends needs to be open simultaneously before proceeding any input
+ * or output operation. When the remote closes the channel, hup signal is
+ * received on this end.
+ */
+
+ g_io_channel_unref(fifoio);
+ fifoio = NULL;
+
+ fifo_open();
+
+ return FALSE;
+}
+
+static int fifo_open(void)
+{
+ GIOCondition condition = G_IO_IN | G_IO_ERR | G_IO_HUP;
+ int fd;
+
+ fd = open(HOG_SUSPEND_FIFO, O_RDONLY | O_NONBLOCK);
+ if (fd < 0) {
+ int err = -errno;
+ error("Can't open FIFO (%s): %s(%d)", HOG_SUSPEND_FIFO,
+ strerror(-err), -err);
+ return err;
+ }
+
+ fifoio = g_io_channel_unix_new(fd);
+ g_io_channel_set_close_on_unref(fifoio, TRUE);
+
+ g_io_add_watch(fifoio, condition, read_fifo, NULL);
+
+ return 0;
+}
int suspend_init(suspend_event suspend, resume_event resume)
{
+ int ret;
+
suspend_cb = suspend;
resume_cb = resume;
- return 0;
+ if (mkfifo(HOG_SUSPEND_FIFO, S_IRWXU) < 0) {
+ int err = -errno;
+ error("Can't create FIFO (%s) : %s(%d)", HOG_SUSPEND_FIFO,
+ strerror(-err), -err);
+ return err;
+ }
+
+ ret = fifo_open();
+ if (ret < 0)
+ remove(HOG_SUSPEND_FIFO);
+
+ return ret;
}
void suspend_exit(void)
{
+ if (fifoio) {
+ g_io_channel_shutdown(fifoio, FALSE, NULL);
+ g_io_channel_unref(fifoio);
+ }
+
+ remove(HOG_SUSPEND_FIFO);
}
--
1.7.12
^ 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