* [PATCH BlueZ] core: Fix memory leak
From: Luiz Augusto von Dentz @ 2012-10-26 7:56 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
1,262 (64 direct, 1,198 indirect) bytes in 1 blocks are definitely lost in loss record 280 of 290
at 0x4A0881C: malloc (vg_replace_malloc.c:270)
by 0x4C813FE: g_malloc (in /usr/lib64/libglib-2.0.so.0.3200.4)
by 0x4C95801: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.3200.4)
by 0x4C95D55: g_slice_alloc0 (in /usr/lib64/libglib-2.0.so.0.3200.4)
by 0x4C746AA: g_key_file_new (in /usr/lib64/libglib-2.0.so.0.3200.4)
by 0x18136C: load_config (adapter.c:2620)
by 0x18353B: adapter_init (adapter.c:2708)
by 0x17E62E: btd_manager_register_adapter (manager.c:337)
by 0x191171: mgmt_event.part.36 (mgmt.c:1081)
by 0x4C7B824: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3200.4)
by 0x4C7BB57: ??? (in /usr/lib64/libglib-2.0.so.0.3200.4)
by 0x4C7BF51: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3200.4)
---
src/adapter.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/adapter.c b/src/adapter.c
index c7b8c7f..54b1a64 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -2684,6 +2684,8 @@ static void load_config(struct btd_adapter *adapter)
mgmt_set_connectable(adapter->dev_id, TRUE);
mgmt_set_discoverable(adapter->dev_id, adapter->discoverable,
adapter->discov_timeout);
+
+ g_key_file_free(key_file);
}
gboolean adapter_init(struct btd_adapter *adapter, gboolean up)
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH BlueZ 07/11] AVRCP: Add initial support for controller player
From: Johan Hedberg @ 2012-10-26 7:44 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1351173554-28039-7-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Thu, Oct 25, 2012, Luiz Augusto von Dentz wrote:
> This also bump controller record to 1.3.
> ---
> Makefile.am | 1 +
> audio/avrcp.c | 686 +++++++++++++++++++++++++++++++++++++++++++++++++--------
> audio/player.c | 404 +++++++++++++++++++++++++++++++++
> audio/player.h | 46 ++++
> 4 files changed, 1047 insertions(+), 90 deletions(-)
> create mode 100644 audio/player.c
> create mode 100644 audio/player.h
I've applied patches 1-6 but this one is just huge. Isn't there some
easy way you could split it up a bit? Also, the necessary D-Bus API
documentation changes seem to be missing.
Johan
^ permalink raw reply
* [PATCH v0] network: Remove unnecessary field from connect_req
From: Mikel Astiz @ 2012-10-26 5:55 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Mikel Astiz
From: Mikel Astiz <mikel.astiz@bmw-carit.de>
The device pointer in struct connect_req can be completely removed since
the callback already receives such pointer, and the network_peer takes
care of the device refcounting.
---
profiles/network/manager.c | 7 +------
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/profiles/network/manager.c b/profiles/network/manager.c
index ad52885..8d0dc4d 100644
--- a/profiles/network/manager.c
+++ b/profiles/network/manager.c
@@ -48,7 +48,6 @@
static gboolean conf_security = TRUE;
struct connect_req {
- struct btd_device *device;
struct btd_profile *profile;
btd_profile_cb cb;
};
@@ -84,9 +83,7 @@ static void connect_profile_cb(struct btd_device *device, int err,
{
struct connect_req *req = data;
- req->cb(req->profile, req->device, err);
-
- btd_device_unref(req->device);
+ req->cb(req->profile, device, err);
g_free(req);
}
@@ -100,14 +97,12 @@ static int connect_profile(struct btd_device *dev, struct btd_profile *profile,
DBG("path %s id %u", device_get_path(dev), id);
req = g_new0(struct connect_req, 1);
- req->device = btd_device_ref(dev);
req->profile = profile;
req->cb = cb;
err = connection_connect(dev, BNEP_SVC_PANU, NULL, connect_profile_cb,
req);
if (err < 0) {
- btd_device_unref(req->device);
g_free(req);
return err;
}
--
1.7.11.7
^ permalink raw reply related
* Re: [RFC 10/18] cyclingspeed: Add DBus.Properties for org.bluez.CyclingSpeed interface
From: Lucas De Marchi @ 2012-10-26 4:49 UTC (permalink / raw)
To: Andrzej Kaczmarek; +Cc: linux-bluetooth
In-Reply-To: <1351176228-5789-11-git-send-email-andrzej.kaczmarek@tieto.com>
On Thu, Oct 25, 2012 at 12:43 PM, Andrzej Kaczmarek
<andrzej.kaczmarek@tieto.com> wrote:
> ---
> profiles/cyclingspeed/cyclingspeed.c | 99 +++++++++++++++++++++++++++++++++++-
> 1 file changed, 98 insertions(+), 1 deletion(-)
>
> diff --git a/profiles/cyclingspeed/cyclingspeed.c b/profiles/cyclingspeed/cyclingspeed.c
> index f7ffd2e..4f48121 100644
> --- a/profiles/cyclingspeed/cyclingspeed.c
> +++ b/profiles/cyclingspeed/cyclingspeed.c
> @@ -43,6 +43,7 @@
>
> #define CYCLINGSPEED_MANAGER_INTERFACE "org.bluez.CyclingSpeedManager"
> #define CYCLINGSPEED_WATCHER_INTERFACE "org.bluez.CyclingSpeedWatcher"
> +#define CYCLINGSPEED_INTERFACE "org.bluez.CyclingSpeed"
>
> #define WHEEL_REV_SUPPORT 0x01
> #define CRANK_REV_SUPPORT 0x02
> @@ -102,6 +103,21 @@ struct characteristic {
>
> static GSList *csc_adapters = NULL;
>
> +static const char * const location_enum[] = {
> + "other", "top-of-shoe", "in-shoe", "hip", "front-wheel", "left-crank",
> + "right-crank", "left-pedal", "right-pedal", "front-hub",
> + "rear-dropout", "chainstay", "rear-wheel", "rear-hub"
> +};
> +
> +static const gchar *location2str(uint8_t value)
> +{
> + if (value < G_N_ELEMENTS(location_enum))
> + return location_enum[value];
> +
> + info("Body Sensor Location [%d] is RFU", value);
> + return location_enum[0];
> +}
> +
> static gint cmp_adapter(gconstpointer a, gconstpointer b)
> {
> const struct csc_adapter *cadapter = a;
> @@ -687,6 +703,74 @@ void csc_adapter_unregister(struct btd_adapter *adapter)
> CYCLINGSPEED_MANAGER_INTERFACE);
> }
>
> +static gboolean property_get_location(const GDBusPropertyTable *property,
> + DBusMessageIter *iter, void *data)
> +{
> + struct csc *csc = data;
> + char *loc;
> +
> + if (!csc->has_location)
> + return FALSE;
> +
> + loc = g_strdup(location2str(csc->location));
> +
> + dbus_message_iter_append_basic(iter, DBUS_TYPE_STRING, &loc);
> +
> + g_free(loc);
you don't need to dup/free the string
Lucas De Marchi
^ permalink raw reply
* BLE GATT subscriber example?
From: Couch, Kelly J @ 2012-10-26 4:24 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
Hi,
I'm interested in building a C application that utilizes BLE GATT via DBUS. However, I have been unable to identify a good source of documentation or example that demonstrates how.
I want to enable the following capabilities:
Pairing - Working...
Subscribe to:
Attribute/characteristic change notifications.
Connect/disconnect notifications
Any suggestions are greatly appreciated.
-Kelly
^ permalink raw reply
* Re: [PATCH] systemd: prevent duplicate logging messages in journal
From: Marcel Holtmann @ 2012-10-25 23:30 UTC (permalink / raw)
To: Marti Raudsepp; +Cc: linux-bluetooth
In-Reply-To: <1349884769-5157-1-git-send-email-marti@juffo.org>
Hi Marti,
> By default, both stdout and syslog messages go to the systemd journal,
> which results in duplicate messages being logged.
> ---
> src/bluetooth.service.in | 1 +
> 1 file changed, 1 insertion(+)
patch has been applied.
Regards
Marcel
^ permalink raw reply
* [PATCH] Bluetooth: Fix error status when pairing fails
From: Paulo Sérgio @ 2012-10-25 19:55 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Paulo Sérgio
In-Reply-To: <1351192136-6925-1-git-send-email-paulo.sergio@openbossa.org>
When pairing fails due to wrong confirm value, the management layer
doesn't report a proper error status. It sends
MGMT_STATUS_CONNECT_FAILED instead of MGMT_STATUS_AUTH_FAILED.
Most of management functions that receive a status as a parameter
expects for it to be encoded as a HCI status. But when a SMP pairing
fails, the SMP layer sends the SMP reason as the error status to the
management layer.
This commit maps all SMP reasons to HCI_ERROR_AUTH_FAILURE, which will
be converted to MGMT_STATUS_AUTH_FAILED in the management layer.
Reported-by: Claudio Takahasi <claudio.takahasi@openbossa.org>
Reviewed-by: João Paulo Rechi Vita <jprvita@openbossa.org>
Signed-off-by: Paulo Sérgio <paulo.sergio@openbossa.org>
---
Please, disconsider the previous patch. It had a wrong commit message.
PS: This is my first patch.
net/bluetooth/smp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
index b542c5d..b3b7cc0 100644
--- a/net/bluetooth/smp.c
+++ b/net/bluetooth/smp.c
@@ -266,7 +266,7 @@ static void smp_failure(struct l2cap_conn *conn, u8 reason, u8 send)
clear_bit(HCI_CONN_ENCRYPT_PEND, &conn->hcon->flags);
mgmt_auth_failed(conn->hcon->hdev, conn->dst, hcon->type,
- hcon->dst_type, reason);
+ hcon->dst_type, HCI_ERROR_AUTH_FAILURE);
cancel_delayed_work_sync(&conn->security_timer);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] Bluetooth: Add support for BCM20702A0 [0b05, 17b5]
From: Jeff Cook @ 2012-10-25 19:17 UTC (permalink / raw)
To: Anderson Lizardo, gustavo
Cc: marcel, johan.hedberg, linux-bluetooth, linux-kernel
In-Reply-To: <CAJdJm_NrmfU17aQDmO0hbihV673Of0iFnLqk4=-sPh=g44eixA@mail.gmail.com>
On 10/24/2012 06:20 AM, Anderson Lizardo wrote:
> Hi Jeff,
>
> On Wed, Oct 24, 2012 at 5:29 AM, Jeff Cook <jeff@deserettechnology.com> wrote:
>> Hello all,
>>
>> Please see included patch. First-time submitter so let me know if I did
>> something wrong.
>
> Just one more suggestion (adding to Gustavo's comments), you may want to read:
>
> http://www.kernel.org/doc/Documentation/SubmittingPatches
>
> Specially sections 12 and 15.
Thanks for the help everyone. I did skim SubmittingPatches prior to
submission, but dropped off before sections 12 and 15; the information
seemed outdated since it made no mention of git by the time I stopped
reading (around section 9 or so), so I looked elsewhere.
I will resubmit according to the information in Section 15. Do I need to
add something like "try 2" to the patch's subject line, or is it okay
without that?
^ permalink raw reply
* [PATCH] Bluetooth: Fix error message when pairing fails
From: Paulo Sérgio @ 2012-10-25 19:08 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Paulo Sérgio
When pairing fails due to wrong confirm value, the management layer
doesn't report a proper error message. It sends a
MGMT_STATUS_CONNECT_FAILED instead of a MGMT_STATUS_AUTH_FAILED.
Most of management functions that receive a status as a parameter
expects for it to be encoded as a HCI status. But when a SMP pairing
fails, the SMP layer sends the SMP reason as the error status to the
management layer.
This commit maps all SMP reasons to HCI_ERROR_AUTH_FAILURE, which will
be converted to MGMT_STATUS_AUTH_FAILED in the management layer.
Reported-by: Claudio Takahasi <claudio.takahasi@openbossa.org>
Reviewed-by: João Paulo Rechi Vita <jprvita@openbossa.org>
Signed-off-by: Paulo Sérgio <paulo.sergio@openbossa.org>
---
net/bluetooth/smp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
index b542c5d..b3b7cc0 100644
--- a/net/bluetooth/smp.c
+++ b/net/bluetooth/smp.c
@@ -266,7 +266,7 @@ static void smp_failure(struct l2cap_conn *conn, u8 reason, u8 send)
clear_bit(HCI_CONN_ENCRYPT_PEND, &conn->hcon->flags);
mgmt_auth_failed(conn->hcon->hdev, conn->dst, hcon->type,
- hcon->dst_type, reason);
+ hcon->dst_type, HCI_ERROR_AUTH_FAILURE);
cancel_delayed_work_sync(&conn->security_timer);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH 5/6] Bluetooth: mgmt: Add support for switching to LE peripheral mode
From: Vinicius Costa Gomes @ 2012-10-25 18:48 UTC (permalink / raw)
To: Anderson Lizardo, Marcel Holtmann, linux-bluetooth
In-Reply-To: <20121025150754.GA5845@x220>
Hi Johan,
On 18:07 Thu 25 Oct, Johan Hedberg wrote:
> Hi Vinicius,
>
> On Thu, Oct 25, 2012, Vinicius Costa Gomes wrote:
> > > On Thu, Oct 25, 2012, Johan Hedberg wrote:
> > > > This will need some more thinking. We could add a new mgmt command for
> > > > that, or if you wanna go crazy why not map this to the L2CAP socket
> > > > interface's connect() system call. I.e. if LE GAP is in peripheral mode
> > > > instead of doing HCI_LE_Create_Connection or just failing with "not
> > > > allowed" a socket connect() would simply trigger directed advertising to
> > > > the device in question and deliver the successful connection in the same
> > > > way as a central role triggered connect would do (unless we time out
> > > > waiting for the remote device to connect). Now that I think of this
> > > > second option it actually sounds quite natural and not so crazy after
> > > > all :)
> > >
> > > There's on problem with this though: we'd still be undirected
> > > connectable between doing mgmt_set_le(peripheral) and issuing the socket
> > > connect(). So maybe we might need to introduce a mgmt_set_le_connectable
> > > command and a "le-connectable" setting after all (that could only be set
> > > in peripheral mode).
> >
> > Why not sending undirected connectable events when there's an active
> > listen()?
>
> But we always have that, don't we? (the GATT server socket). Or are you
> saying that bluetoothd could close its GATT server socket before
> switching to peripheral mode and that would ensure that the kernel
> doesn't enable connectable advertising?
Right now bluetoothd always has a listen() active, yes. But remember
that that listen() was added only to help testing, in the case that
BlueZ always initiates connections that listen() is not needed.
What I am thinking is having more control about when to advertise, for
example, each profile that needs the peripheral role would increase the
reference of a listener, when all the references are dropped I stop
advertising.
>
> Johan
Cheers,
--
Vinicius
^ permalink raw reply
* Re: [RFC v0 05/15] network: Add network .connect and .disconnect
From: Johan Hedberg @ 2012-10-25 17:38 UTC (permalink / raw)
To: Mikel Astiz; +Cc: Anderson Lizardo, linux-bluetooth, Mikel Astiz
In-Reply-To: <CANT-zCUSkGJ1SWxUNU7J80WxRpotNbfEhmuQihoXj6WquaBePw@mail.gmail.com>
Hi Mikel,
On Thu, Oct 25, 2012, Mikel Astiz wrote:
> >> > + req = g_new0(struct connect_req, 1);
> >> > + req->device = dev;
> >>
> >> Isn't btd_device_ref() required here?
> >
> > Looks like you're right and I missed this in my initial review. I went
> > ahead and pushed an extra patch to fix this.
>
> I don't think this patch was needed. Actually, the device pointer in
> struct connect_req can be completely removed, since the callback
> already receives such pointer, and the network_peer takes care of the
> device refcounting. Mea culpa for adding this unnecessary field.
Good point. Feel free to send a patch to remove it.
Johan
^ permalink raw reply
* Re: [RFC v0 05/15] network: Add network .connect and .disconnect
From: Mikel Astiz @ 2012-10-25 15:53 UTC (permalink / raw)
To: Anderson Lizardo, Mikel Astiz, linux-bluetooth, Mikel Astiz
In-Reply-To: <20121025104219.GB30500@x220>
Hi,
On Thu, Oct 25, 2012 at 12:42 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Lizardo,
>
> On Wed, Oct 24, 2012, Anderson Lizardo wrote:
>> Hi Mikel,
>>
>> On Fri, Oct 19, 2012 at 11:39 AM, Mikel Astiz <mikel.astiz.oss@gmail.com> wrote:
>> > +static void connect_profile_cb(struct btd_device *device, int err,
>> > + const char *pdev, void *data)
>> > +{
>> > + struct connect_req *req = data;
>> > +
>> > + req->cb(req->profile, req->device, err);
>> > +
>> > + g_free(req);
>> > +}
>> > +
>> > +static int connect_profile(struct btd_device *dev, struct btd_profile *profile,
>> > + uint16_t id, btd_profile_cb cb)
>> > +{
>> > + struct connect_req *req;
>> > + int err;
>> > +
>> > + DBG("path %s id %u", device_get_path(dev), id);
>> > +
>> > + req = g_new0(struct connect_req, 1);
>> > + req->device = dev;
>>
>> Isn't btd_device_ref() required here?
>
> Looks like you're right and I missed this in my initial review. I went
> ahead and pushed an extra patch to fix this.
I don't think this patch was needed. Actually, the device pointer in
struct connect_req can be completely removed, since the callback
already receives such pointer, and the network_peer takes care of the
device refcounting. Mea culpa for adding this unnecessary field.
Cheers,
Mikel
^ permalink raw reply
* Re: [RFC v0 12/15] input: Add profile .disconnect
From: Mikel Astiz @ 2012-10-25 15:49 UTC (permalink / raw)
To: Mikel Astiz, linux-bluetooth, Mikel Astiz
In-Reply-To: <20121025103922.GA30500@x220>
Hi Johan,
On Thu, Oct 25, 2012 at 12:39 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Mikel,
>
> On Fri, Oct 19, 2012, Mikel Astiz wrote:
>> From: Mikel Astiz <mikel.astiz@bmw-carit.de>
>>
>> Add the disconnect hook to the btd_profile.
>> ---
>> profiles/input/manager.c | 1 +
>> 1 file changed, 1 insertion(+)
>
> I've applied the patches up until this one with the exception of the
> audio ones which I'll let Luiz to look at and sync up with the work he's
> doing for audio right now. The last three will still need some
> discussion as I'm not convinced that it's a good idea to have these
> generic profile objects instead or Adapter.Connect/DisconnectProfile.
The problem with Adapter.Connect/DisconnectProfile is that you are not
able to expose the state of the profile. That was the reason to
propose such APIs, since UIs and applications could be interested in
this information.
Cheers,
Mikel
^ permalink raw reply
* Re: [PATCH] Bluetooth: l2cap_physical_cfm() can be static
From: Mat Martineau @ 2012-10-25 15:29 UTC (permalink / raw)
To: Andrei Emeltchenko
Cc: Marcel Holtmann, Fengguang Wu, Gustavo Padovan, linux-bluetooth
In-Reply-To: <20121025071307.GA2502@aemeltch-MOBL1>
Hi -
On Thu, 25 Oct 2012, Andrei Emeltchenko wrote:
> Hi,
>
> On Wed, Oct 24, 2012 at 06:55:34PM -0700, Marcel Holtmann wrote:
>> Hi Fengguang,
>>
>>> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
>>> ---
>>> net/bluetooth/l2cap_core.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> --- linux-next.orig/net/bluetooth/l2cap_core.c 2012-10-25 08:23:52.456742699 +0800
>>> +++ linux-next/net/bluetooth/l2cap_core.c 2012-10-25 08:23:55.056742760 +0800
>>> @@ -4569,7 +4569,7 @@ static void l2cap_do_move_cancel(struct
>>> l2cap_ertm_send(chan);
>>> }
>>>
>>> -void l2cap_physical_cfm(struct l2cap_chan *chan, int result, u8 local_amp_id,
>>> +static void l2cap_physical_cfm(struct l2cap_chan *chan, int result, u8 local_amp_id,
>>> u8 remote_amp_id)
>>
>> I rather wait for Mat to ACK or NACK this one. Maybe it is an oversight
>> or we need that later on to be actually public.
>
> Agree with Marcel here. This shall be public.
Yes, it does need to be public. Andrei will need to call it from the
AMP physical link code, but I'm not sure exactly where (HCI event
handling or somewhere in amp.c or a2mp.c).
--
Mat Martineau
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: [RFCv1 10/11] Bluetooth: Add put(hcon) when deleting hchan
From: Gustavo Padovan @ 2012-10-25 15:22 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth
In-Reply-To: <1351167652-12346-11-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
* Andrei Emeltchenko <Andrei.Emeltchenko.news@gmail.com> [2012-10-25 15:20:51 +0300]:
> From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
>
> When refcnt reaches zero disconnect timeout will run and hci_conn
> will be disconnected.
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
> ---
> net/bluetooth/hci_conn.c | 2 ++
> 1 file changed, 2 insertions(+)
Patches 1-4 and 10 have been applied to bluetooth-next. I'll wait for more
feedback on the others, as this is still an RFC. Thanks.
Gustavo
^ permalink raw reply
* Re: [PATCH 3/6] Bluetooth: Fix sending unnecessary HCI_LE_Host_Enable
From: Gustavo Padovan @ 2012-10-25 15:20 UTC (permalink / raw)
To: Marcel Holtmann, linux-bluetooth
In-Reply-To: <20121025151430.GA6105@x220>
Hi,
* Johan Hedberg <johan.hedberg@gmail.com> [2012-10-25 18:14:30 +0300]:
> Hi,
>
> On Thu, Oct 25, 2012, Marcel Holtmann wrote:
> > > > From: Johan Hedberg <johan.hedberg@intel.com>
> > > >
> > > > This patch fixes sending an unnecessary HCI_LE_Host_Enable command if
> > > > the command has already been sent as part of the default HCI init
> > > > sequence.
> > > >
> > > > Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> > > > ---
> > > > net/bluetooth/mgmt.c | 10 ++++++++--
> > > > 1 file changed, 8 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
> > > > index 02dc5f8..03dc176 100644
> > > > --- a/net/bluetooth/mgmt.c
> > > > +++ b/net/bluetooth/mgmt.c
> > > > @@ -2927,8 +2927,14 @@ int mgmt_powered(struct hci_dev *hdev, u8 powered)
> > > > cp.le = 1;
> > > > cp.simul = !!lmp_le_br_capable(hdev);
> > > >
> > > > - hci_send_cmd(hdev, HCI_OP_WRITE_LE_HOST_SUPPORTED,
> > > > - sizeof(cp), &cp);
> > > > + /* Check first if we already have the right
> > > > + * host state (host features set)
> > > > + */
> > > > + if (cp.le != !!lmp_host_le_capable(hdev) ||
> > > > + cp.simul != !!lmp_host_le_br_capable(hdev))
> > >
> > > Shouldn't the !! be part of the macro itself? Looks we will be using !! always
> > > with these macros.
> >
> > we could do that actually. However I prefer to do that with a separate
> > patch.
>
> I was thinking of the same earlier, and yes a separate patch to convert
> all of the feature test macros would be the cleanest.
I didn't say it needed to be in the same patch. Anyway, I applied this patch
now, I'll do the macro's conversion later today.
Gustavo
^ permalink raw reply
* Re: [PATCH 3/6] Bluetooth: Fix sending unnecessary HCI_LE_Host_Enable
From: Johan Hedberg @ 2012-10-25 15:14 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Gustavo Padovan, linux-bluetooth
In-Reply-To: <1351177676.1785.94.camel@aeonflux>
Hi,
On Thu, Oct 25, 2012, Marcel Holtmann wrote:
> > > From: Johan Hedberg <johan.hedberg@intel.com>
> > >
> > > This patch fixes sending an unnecessary HCI_LE_Host_Enable command if
> > > the command has already been sent as part of the default HCI init
> > > sequence.
> > >
> > > Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> > > ---
> > > net/bluetooth/mgmt.c | 10 ++++++++--
> > > 1 file changed, 8 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
> > > index 02dc5f8..03dc176 100644
> > > --- a/net/bluetooth/mgmt.c
> > > +++ b/net/bluetooth/mgmt.c
> > > @@ -2927,8 +2927,14 @@ int mgmt_powered(struct hci_dev *hdev, u8 powered)
> > > cp.le = 1;
> > > cp.simul = !!lmp_le_br_capable(hdev);
> > >
> > > - hci_send_cmd(hdev, HCI_OP_WRITE_LE_HOST_SUPPORTED,
> > > - sizeof(cp), &cp);
> > > + /* Check first if we already have the right
> > > + * host state (host features set)
> > > + */
> > > + if (cp.le != !!lmp_host_le_capable(hdev) ||
> > > + cp.simul != !!lmp_host_le_br_capable(hdev))
> >
> > Shouldn't the !! be part of the macro itself? Looks we will be using !! always
> > with these macros.
>
> we could do that actually. However I prefer to do that with a separate
> patch.
I was thinking of the same earlier, and yes a separate patch to convert
all of the feature test macros would be the cleanest.
Johan
^ permalink raw reply
* Re: [PATCH 4/6] Bluetooth: Fix unnecessary EIR update during powering on
From: Gustavo Padovan @ 2012-10-25 15:08 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <1351112996-9597-5-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
* Johan Hedberg <johan.hedberg@gmail.com> [2012-10-25 00:09:54 +0300]:
> From: Johan Hedberg <johan.hedberg@intel.com>
>
> When powered on the EIR data gets updated as the last step by mgmt.
> Therefore avoid an update when getting a local name update as that's
> part of the normal HCI init sequence.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> net/bluetooth/mgmt.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
Patch 1, 2 and 4 have been applied to bluetooth-next. Thanks.
Gustavo
^ permalink raw reply
* Re: [PATCH 3/6] Bluetooth: Fix sending unnecessary HCI_LE_Host_Enable
From: Marcel Holtmann @ 2012-10-25 15:07 UTC (permalink / raw)
To: Gustavo Padovan; +Cc: Johan Hedberg, linux-bluetooth
In-Reply-To: <20121025150520.GA1764@joana>
Hi Gustavo,
> > From: Johan Hedberg <johan.hedberg@intel.com>
> >
> > This patch fixes sending an unnecessary HCI_LE_Host_Enable command if
> > the command has already been sent as part of the default HCI init
> > sequence.
> >
> > Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> > ---
> > net/bluetooth/mgmt.c | 10 ++++++++--
> > 1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
> > index 02dc5f8..03dc176 100644
> > --- a/net/bluetooth/mgmt.c
> > +++ b/net/bluetooth/mgmt.c
> > @@ -2927,8 +2927,14 @@ int mgmt_powered(struct hci_dev *hdev, u8 powered)
> > cp.le = 1;
> > cp.simul = !!lmp_le_br_capable(hdev);
> >
> > - hci_send_cmd(hdev, HCI_OP_WRITE_LE_HOST_SUPPORTED,
> > - sizeof(cp), &cp);
> > + /* Check first if we already have the right
> > + * host state (host features set)
> > + */
> > + if (cp.le != !!lmp_host_le_capable(hdev) ||
> > + cp.simul != !!lmp_host_le_br_capable(hdev))
>
> Shouldn't the !! be part of the macro itself? Looks we will be using !! always
> with these macros.
we could do that actually. However I prefer to do that with a separate
patch.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 5/6] Bluetooth: mgmt: Add support for switching to LE peripheral mode
From: Johan Hedberg @ 2012-10-25 15:07 UTC (permalink / raw)
To: Vinicius Costa Gomes; +Cc: Anderson Lizardo, Marcel Holtmann, linux-bluetooth
In-Reply-To: <20121025143138.GA27907@samus>
Hi Vinicius,
On Thu, Oct 25, 2012, Vinicius Costa Gomes wrote:
> > On Thu, Oct 25, 2012, Johan Hedberg wrote:
> > > This will need some more thinking. We could add a new mgmt command for
> > > that, or if you wanna go crazy why not map this to the L2CAP socket
> > > interface's connect() system call. I.e. if LE GAP is in peripheral mode
> > > instead of doing HCI_LE_Create_Connection or just failing with "not
> > > allowed" a socket connect() would simply trigger directed advertising to
> > > the device in question and deliver the successful connection in the same
> > > way as a central role triggered connect would do (unless we time out
> > > waiting for the remote device to connect). Now that I think of this
> > > second option it actually sounds quite natural and not so crazy after
> > > all :)
> >
> > There's on problem with this though: we'd still be undirected
> > connectable between doing mgmt_set_le(peripheral) and issuing the socket
> > connect(). So maybe we might need to introduce a mgmt_set_le_connectable
> > command and a "le-connectable" setting after all (that could only be set
> > in peripheral mode).
>
> Why not sending undirected connectable events when there's an active
> listen()?
But we always have that, don't we? (the GATT server socket). Or are you
saying that bluetoothd could close its GATT server socket before
switching to peripheral mode and that would ensure that the kernel
doesn't enable connectable advertising?
Johan
^ permalink raw reply
* Re: [PATCH 3/6] Bluetooth: Fix sending unnecessary HCI_LE_Host_Enable
From: Gustavo Padovan @ 2012-10-25 15:05 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <1351112996-9597-4-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
* Johan Hedberg <johan.hedberg@gmail.com> [2012-10-25 00:09:53 +0300]:
> From: Johan Hedberg <johan.hedberg@intel.com>
>
> This patch fixes sending an unnecessary HCI_LE_Host_Enable command if
> the command has already been sent as part of the default HCI init
> sequence.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> net/bluetooth/mgmt.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
> index 02dc5f8..03dc176 100644
> --- a/net/bluetooth/mgmt.c
> +++ b/net/bluetooth/mgmt.c
> @@ -2927,8 +2927,14 @@ int mgmt_powered(struct hci_dev *hdev, u8 powered)
> cp.le = 1;
> cp.simul = !!lmp_le_br_capable(hdev);
>
> - hci_send_cmd(hdev, HCI_OP_WRITE_LE_HOST_SUPPORTED,
> - sizeof(cp), &cp);
> + /* Check first if we already have the right
> + * host state (host features set)
> + */
> + if (cp.le != !!lmp_host_le_capable(hdev) ||
> + cp.simul != !!lmp_host_le_br_capable(hdev))
Shouldn't the !! be part of the macro itself? Looks we will be using !! always
with these macros.
Gustavo
^ permalink raw reply
* [RFC 18/18] doc: Rename cycling API to cyclingspeed
From: Andrzej Kaczmarek @ 2012-10-25 14:43 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Andrzej Kaczmarek
In-Reply-To: <1351176228-5789-1-git-send-email-andrzej.kaczmarek@tieto.com>
---
doc/cycling-api.txt | 100 -----------------------------------------------
doc/cyclingspeed-api.txt | 100 +++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 100 insertions(+), 100 deletions(-)
delete mode 100644 doc/cycling-api.txt
create mode 100644 doc/cyclingspeed-api.txt
diff --git a/doc/cycling-api.txt b/doc/cycling-api.txt
deleted file mode 100644
index 08e11c8..0000000
--- a/doc/cycling-api.txt
+++ /dev/null
@@ -1,100 +0,0 @@
-Cycling Speed and Cadence API description
-*****************************************
-
-Copyright (C) 2012 Tieto Poland
-
-Cycling Speed and Cadence Manager hierarchy
-===========================================
-
-Service org.bluez
-Interface org.bluez.CyclingSpeedManager
-Object path [variable prefix]/{hci0,hci1,...}
-
-Methods RegisterWatcher(object agent)
-
- Registers a watcher to monitor cycling speed and
- cadence measurements.
-
- Possible Errors: org.bluez.Error.InvalidArguments
-
- UnregisterWatcher(object agent)
-
- Unregisters a watcher.
-
-Cycling Speed and Cadence Profile hierarchy
-===========================================
-
-Service org.bluez
-Interface org.bluez.CyclingSpeed
-Object path [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX
-
-Methods SetCumulativeWheelRevolutions(uint32 value)
-
- Sets cumulative wheel revolutions value if
- Cumulative Wheel Revolutions feature is supported.
-
- Possible Errors: org.bluez.Error.NotSupported
-
-Properties string Location (optional) [readwrite]
-
- Current sensor location, if supported.
- If Multiple Sensor Locations feature is supported,
- this property can be set to one of values read from
- SupportedLocations property.
-
- Possible values: "other", "top-of-shoe", "in-shoe",
- "hip", "front-wheel", "left-crank",
- "right-crank", "left-pedal",
- "right-pedal", "front-hub",
- "rear-dropout", "chainstay",
- "rear-wheel", "rear-hub"
-
- array{string} SupportedLocations (optional) [readonly]
-
- List of locations supported by sensor, only present
- if Multiple Sensor Locations feature is supported.
-
- boolean WheelRevolutionDataSupported [readonly]
-
- true if sensor can read and set Cumulative Wheel
- Revolutions value, false otherwise.
-
- boolean MultipleSensorLocationsSupported [readonly]
-
- true if sensor supports Multiple Sensor Locations
- feature and can set Location, false otherwise.
-
-Cycling Speed and Cadence Watcher hierarchy
-===========================================
-
-Service unique name
-Interface org.bluez.CyclingSpeedWatcher
-Object path freely definable
-
-Methods void MeasurementReceived(object device, dict measurement)
-
- This callback is called whenever wheel and/or crank
- revolutions measurement is received from sensor.
-
- Measurement:
-
- uint32 WheelRevolutions (optional):
-
- Cumulative number of wheel revolutions.
-
- uint16 LastWheelEventTime (optional):
-
- Time of last event from wheel sensor.
- Value is expressed in 1/1024 second
- units and can roll over during a ride.
-
- uint16 CrankRevolutions (optional):
-
- Cumulative number of crank revolutions.
- This value can occasionally roll over.
-
- uint16 LastCrankEventTime (optional):
-
- Time of last event from crank sensor.
- Value is expressed in 1/1024 second
- units and can roll over during a ride.
diff --git a/doc/cyclingspeed-api.txt b/doc/cyclingspeed-api.txt
new file mode 100644
index 0000000..08e11c8
--- /dev/null
+++ b/doc/cyclingspeed-api.txt
@@ -0,0 +1,100 @@
+Cycling Speed and Cadence API description
+*****************************************
+
+Copyright (C) 2012 Tieto Poland
+
+Cycling Speed and Cadence Manager hierarchy
+===========================================
+
+Service org.bluez
+Interface org.bluez.CyclingSpeedManager
+Object path [variable prefix]/{hci0,hci1,...}
+
+Methods RegisterWatcher(object agent)
+
+ Registers a watcher to monitor cycling speed and
+ cadence measurements.
+
+ Possible Errors: org.bluez.Error.InvalidArguments
+
+ UnregisterWatcher(object agent)
+
+ Unregisters a watcher.
+
+Cycling Speed and Cadence Profile hierarchy
+===========================================
+
+Service org.bluez
+Interface org.bluez.CyclingSpeed
+Object path [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX
+
+Methods SetCumulativeWheelRevolutions(uint32 value)
+
+ Sets cumulative wheel revolutions value if
+ Cumulative Wheel Revolutions feature is supported.
+
+ Possible Errors: org.bluez.Error.NotSupported
+
+Properties string Location (optional) [readwrite]
+
+ Current sensor location, if supported.
+ If Multiple Sensor Locations feature is supported,
+ this property can be set to one of values read from
+ SupportedLocations property.
+
+ Possible values: "other", "top-of-shoe", "in-shoe",
+ "hip", "front-wheel", "left-crank",
+ "right-crank", "left-pedal",
+ "right-pedal", "front-hub",
+ "rear-dropout", "chainstay",
+ "rear-wheel", "rear-hub"
+
+ array{string} SupportedLocations (optional) [readonly]
+
+ List of locations supported by sensor, only present
+ if Multiple Sensor Locations feature is supported.
+
+ boolean WheelRevolutionDataSupported [readonly]
+
+ true if sensor can read and set Cumulative Wheel
+ Revolutions value, false otherwise.
+
+ boolean MultipleSensorLocationsSupported [readonly]
+
+ true if sensor supports Multiple Sensor Locations
+ feature and can set Location, false otherwise.
+
+Cycling Speed and Cadence Watcher hierarchy
+===========================================
+
+Service unique name
+Interface org.bluez.CyclingSpeedWatcher
+Object path freely definable
+
+Methods void MeasurementReceived(object device, dict measurement)
+
+ This callback is called whenever wheel and/or crank
+ revolutions measurement is received from sensor.
+
+ Measurement:
+
+ uint32 WheelRevolutions (optional):
+
+ Cumulative number of wheel revolutions.
+
+ uint16 LastWheelEventTime (optional):
+
+ Time of last event from wheel sensor.
+ Value is expressed in 1/1024 second
+ units and can roll over during a ride.
+
+ uint16 CrankRevolutions (optional):
+
+ Cumulative number of crank revolutions.
+ This value can occasionally roll over.
+
+ uint16 LastCrankEventTime (optional):
+
+ Time of last event from crank sensor.
+ Value is expressed in 1/1024 second
+ units and can roll over during a ride.
--
1.8.0
^ permalink raw reply related
* [RFC 17/18] test: Add cyclingspeed test script
From: Andrzej Kaczmarek @ 2012-10-25 14:43 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Andrzej Kaczmarek
In-Reply-To: <1351176228-5789-1-git-send-email-andrzej.kaczmarek@tieto.com>
---
Makefile.tools | 2 +-
test/test-cyclingspeed | 115 +++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 116 insertions(+), 1 deletion(-)
create mode 100755 test/test-cyclingspeed
diff --git a/Makefile.tools b/Makefile.tools
index ec79cea..9168be9 100644
--- a/Makefile.tools
+++ b/Makefile.tools
@@ -215,4 +215,4 @@ EXTRA_DIST += test/sap_client.py test/hsplay test/hsmicro \
test/test-health test/test-health-sink test/service-record.dtd \
test/service-did.xml test/service-spp.xml test/service-opp.xml \
test/service-ftp.xml test/simple-player test/test-nap \
- test/test-heartrate test/test-alert
+ test/test-heartrate test/test-alert test/test-cycling
diff --git a/test/test-cyclingspeed b/test/test-cyclingspeed
new file mode 100755
index 0000000..f3771d3
--- /dev/null
+++ b/test/test-cyclingspeed
@@ -0,0 +1,115 @@
+#!/usr/bin/python
+
+from __future__ import absolute_import, print_function, unicode_literals
+
+'''
+Cycling Speed and Cadence test script
+'''
+
+import gobject
+
+import sys
+import dbus
+import dbus.service
+import dbus.mainloop.glib
+from optparse import OptionParser, make_option
+
+class Watcher(dbus.service.Object):
+ @dbus.service.method("org.bluez.CyclingSpeedWatcher",
+ in_signature="oa{sv}", out_signature="")
+ def MeasurementReceived(self, device, measure):
+ print("Measurement received from %s" % device)
+
+ if "WheelRevolutions" in measure:
+ print("WheelRevolutions: ", measure["WheelRevolutions"])
+
+ if "LastWheelEventTime" in measure:
+ print("LastWheelEventTime: ", measure["LastWheelEventTime"])
+
+ if "CrankRevolutions" in measure:
+ print("CrankRevolutions: ", measure["CrankRevolutions"])
+
+ if "LastCrankEventTime" in measure:
+ print("LastCrankEventTime: ", measure["LastCrankEventTime"])
+
+if __name__ == "__main__":
+ dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
+
+ bus = dbus.SystemBus()
+
+ option_list = [
+ make_option("-i", "--adapter", action="store",
+ type="string", dest="adapter"),
+ make_option("-b", "--device", action="store",
+ type="string", dest="address"),
+ ]
+
+ parser = OptionParser(option_list=option_list)
+
+ (options, args) = parser.parse_args()
+
+ if not options.address:
+ print("Usage: %s [-i <adapter>] -b <bdaddr> [-c <value>] [cmd]" % (sys.argv[0]))
+ print("Possible commands:")
+ print("\tShowSupportedLocations")
+ print("\tSetLocation <location>")
+ print("\tSetCumulativeWheelRevolutions <value>")
+ sys.exit(1)
+
+ manager = dbus.Interface(bus.get_object("org.bluez", "/"),
+ "org.bluez.Manager")
+ if options.adapter:
+ adapter_path = manager.FindAdapter(options.adapter)
+ else:
+ adapter_path = manager.DefaultAdapter()
+
+ adapter = dbus.Interface(bus.get_object("org.bluez", adapter_path),
+ "org.bluez.Adapter")
+
+ device_path = adapter.FindDevice(options.address)
+
+ cscmanager = dbus.Interface(bus.get_object("org.bluez", adapter_path),
+ "org.bluez.CyclingSpeedManager")
+
+ watcher_path = "/test/watcher"
+ watcher = Watcher(bus, watcher_path)
+ cscmanager.RegisterWatcher(watcher_path)
+
+ csc = dbus.Interface(bus.get_object("org.bluez", device_path),
+ "org.bluez.CyclingSpeed")
+
+ device_prop = dbus.Interface(bus.get_object("org.bluez", device_path),
+ "org.freedesktop.DBus.Properties")
+
+ properties = device_prop.GetAll("org.bluez.CyclingSpeed")
+
+ if "Location" in properties:
+ print("Sensor location: %s" % properties["Location"])
+ else:
+ print("Sensor location is not supported")
+
+ if len(args) > 0:
+ if args[0] == "ShowSupportedLocations":
+ if properties["MultipleSensorLocationsSupported"]:
+ print("Supported locations: ", properties["SupportedLocations"])
+ else:
+ print("Multiple sensor locations not supported")
+
+ elif args[0] == "SetLocation":
+ if properties["MultipleSensorLocationsSupported"]:
+ device_prop.Set("org.bluez.CyclingSpeed", "Location", args[1])
+ else:
+ print("Multiple sensor locations not supported")
+
+ elif args[0] == "SetCumulativeWheelRevolutions":
+ if properties["WheelRevolutionDataSupported"]:
+ csc.SetCumulativeWheelRevolutions(dbus.UInt32(args[1]))
+ else:
+ print("Wheel revolution data not supported")
+
+ else:
+ print("Unknown command")
+ sys.exit(1)
+
+ mainloop = gobject.MainLoop()
+ mainloop.run()
--
1.8.0
^ permalink raw reply related
* [RFC 16/18] core: Add CyclingSpeedWatcher interface to default policy
From: Andrzej Kaczmarek @ 2012-10-25 14:43 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Andrzej Kaczmarek
In-Reply-To: <1351176228-5789-1-git-send-email-andrzej.kaczmarek@tieto.com>
---
src/bluetooth.conf | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/bluetooth.conf b/src/bluetooth.conf
index 2db43d9..a1269a4 100644
--- a/src/bluetooth.conf
+++ b/src/bluetooth.conf
@@ -19,6 +19,7 @@
<allow send_interface="org.bluez.AlertAgent"/>
<allow send_interface="org.bluez.Profile"/>
<allow send_interface="org.bluez.HeartRateWatcher"/>
+ <allow send_interface="org.bluez.CyclingSpeedWatcher"/>
</policy>
<policy at_console="true">
--
1.8.0
^ permalink raw reply related
* [RFC 15/18] cyclingspeed: Add support for Set Cumulative Value
From: Andrzej Kaczmarek @ 2012-10-25 14:43 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Andrzej Kaczmarek
In-Reply-To: <1351176228-5789-1-git-send-email-andrzej.kaczmarek@tieto.com>
---
profiles/cyclingspeed/cyclingspeed.c | 92 +++++++++++++++++++++++++++++++++++-
1 file changed, 91 insertions(+), 1 deletion(-)
diff --git a/profiles/cyclingspeed/cyclingspeed.c b/profiles/cyclingspeed/cyclingspeed.c
index bf8ea46..7b5c3f5 100644
--- a/profiles/cyclingspeed/cyclingspeed.c
+++ b/profiles/cyclingspeed/cyclingspeed.c
@@ -75,6 +75,7 @@ struct controlpoint_req {
uint8_t opcode;
guint timeout;
GDBusPendingReply reply_id;
+ DBusMessage *msg;
};
struct csc_adapter {
@@ -287,6 +288,15 @@ static gboolean controlpoint_timeout(gpointer user_data)
g_dbus_pending_property_error(req->reply_id,
ERROR_INTERFACE ".Failed",
"Operation failed (timeout)");
+ } else if (req->opcode == SET_CUMULATIVE_VALUE) {
+ DBusMessage *reply;
+
+ reply = btd_error_failed(req->msg,
+ "Operation failed (timeout)");
+
+ g_dbus_send_message(btd_get_dbus_connection(), reply);
+
+ dbus_message_unref(req->msg);
}
req->csc->pending_req = NULL;
@@ -307,6 +317,15 @@ static void controlpoint_write_cb(guint8 status, const guint8 *pdu, guint16 len,
g_dbus_pending_property_error(req->reply_id,
ERROR_INTERFACE ".Failed",
"Operation failed (%d)", status);
+ } else if (req->opcode == SET_CUMULATIVE_VALUE) {
+ DBusMessage *reply;
+
+ reply = btd_error_failed(req->msg,
+ "Operation failed");
+
+ g_dbus_send_message(btd_get_dbus_connection(), reply);
+
+ dbus_message_unref(req->msg);
}
req->csc->pending_req = NULL;
@@ -616,6 +635,34 @@ static void controlpoint_property_reply(struct controlpoint_req *req,
}
}
+static void controlpoint_method_reply(struct controlpoint_req *req,
+ uint8_t code)
+{
+ DBusMessage *reply;
+
+ switch (code) {
+ case RSP_SUCCESS:
+ reply = dbus_message_new_method_return(req->msg);
+ break;
+ case RSP_NOT_SUPPORTED:
+ reply = btd_error_not_supported(req->msg);
+ break;
+ case RSP_INVALID_PARAM:
+ reply = btd_error_invalid_args(req->msg);
+ break;
+ case RSP_FAILED:
+ reply = btd_error_failed(req->msg, "Failed");
+ break;
+ default:
+ reply = btd_error_failed(req->msg, "Unknown error");
+ break;
+ }
+
+ g_dbus_send_message(btd_get_dbus_connection(), reply);
+
+ dbus_message_unref(req->msg);
+}
+
static void controlpoint_ind_handler(const uint8_t *pdu, uint16_t len,
gpointer user_data)
{
@@ -667,6 +714,10 @@ static void controlpoint_ind_handler(const uint8_t *pdu, uint16_t len,
}
switch (req->opcode) {
+ case SET_CUMULATIVE_VALUE:
+ controlpoint_method_reply(req, rsp_code);
+ break;
+
case REQUEST_SUPPORTED_SENSOR_LOC:
if (rsp_code == RSP_SUCCESS) {
csc->num_locations = len;
@@ -1069,6 +1120,44 @@ static const GDBusPropertyTable cyclingspeed_device_properties[] = {
{ }
};
+static DBusMessage *set_cumulative_wheel_rev(DBusConnection *conn,
+ DBusMessage *msg, void *data)
+{
+ struct csc *csc = data;
+ dbus_uint32_t value;
+ struct controlpoint_req *req;
+ uint8_t att_val[5]; /* uint8 opcode + uint32 value */
+
+ if (!dbus_message_get_args(msg, NULL, DBUS_TYPE_UINT32, &value,
+ DBUS_TYPE_INVALID))
+ return btd_error_invalid_args(msg);
+
+ if (csc->pending_req != NULL)
+ return btd_error_in_progress(msg);
+
+ req = g_new(struct controlpoint_req, 1);
+ req->csc = csc;
+ req->opcode = SET_CUMULATIVE_VALUE;
+ req->msg = dbus_message_ref(msg);
+
+ csc->pending_req = req;
+
+ att_val[0] = SET_CUMULATIVE_VALUE;
+ att_put_u32(value, att_val + 1);
+
+ gatt_write_char(csc->attrib, csc->controlpoint_val_handle, att_val,
+ sizeof(att_val), controlpoint_write_cb, req);
+
+ return NULL;
+}
+
+static const GDBusMethodTable cyclingspeed_device_methods[] = {
+ { GDBUS_ASYNC_METHOD("SetCumulativeWheelRevolutions",
+ GDBUS_ARGS({ "value", "u" }), NULL,
+ set_cumulative_wheel_rev) },
+ { }
+};
+
int csc_device_register(struct btd_device *device, struct gatt_primary *prim)
{
struct btd_adapter *adapter;
@@ -1088,7 +1177,8 @@ int csc_device_register(struct btd_device *device, struct gatt_primary *prim)
if (!g_dbus_register_interface(btd_get_dbus_connection(),
device_get_path(device),
CYCLINGSPEED_INTERFACE,
- NULL, NULL,
+ cyclingspeed_device_methods,
+ NULL,
cyclingspeed_device_properties,
csc, destroy_csc)) {
error("D-Bus failed to register %s interface",
--
1.8.0
^ 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