* Re: [RFC] BlueZ D-Bus Sim Access Profile Server API description
From: Johan Hedberg @ 2010-09-13 13:20 UTC (permalink / raw)
To: Suraj Sumangala; +Cc: linux-bluetooth, Jothikumar.Mothilal
In-Reply-To: <4C8E0BA3.1010308@Atheros.com>
Hi,
> Should we have the method like,
> struct RequestATR(string command, variant param)
ATR doesn't take any parameters so it'd be just RequestATR()
> where, struct = { string, array{uint8} )
What do you need the string for? Wouldn't an array{uint8} suffice? A
D-Bus error return could be used when the ResultCode in the response
indicates failure.
Johan
^ permalink raw reply
* RE: [RFC] BlueZ D-Bus Sim Access Profile Server API description
From: Waldemar.Rymarkiewicz @ 2010-09-13 12:47 UTC (permalink / raw)
To: suraj; +Cc: Suraj.Sumangala, linux-bluetooth, Jothikumar.Mothilal
In-Reply-To: <4C8E1942.40805@Atheros.com>
Hi Suraj,
>The agent will be in a better position to take this decision
>as it will be interfacing between actual card reader and SAP server.
>
>For example, if the agent is connected to an external card
>reader and it has lost connection with the reader. It can ask
>for an Immediate disconnection.
What will happen when dbus connection will be lost? SAP server will start immediate disconnection. Right?
>If disconnection was triggered by a user action, it can decide
>to call this API with Graceful as the parameter.
What exactly do you mean "triggerd by a user" ? Does agent interact with the user somehow? In which way, any API for that?
>One candidate would be when the MessageSize is changed.
>Another one will be with the "SimStatus" property. It makes
>sense to raise his signal after the server sends the STATUS
>IND response successfully.
>
>But, it is a fact that most of the Properties are set by the
>Agent itself. So agent will know that they have changed.
Exactly.
Thanks,
/Waldek
^ permalink raw reply
* [PATCH] Fix crash on gstreamer plugin if device doesn't support sbc
From: Luiz Augusto von Dentz @ 2010-09-13 12:40 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
---
audio/gstavdtpsink.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/audio/gstavdtpsink.c b/audio/gstavdtpsink.c
index f0e5b76..b8c8832 100644
--- a/audio/gstavdtpsink.c
+++ b/audio/gstavdtpsink.c
@@ -448,6 +448,9 @@ static GstStructure *gst_avdtp_sink_parse_sbc_caps(
GValue *list;
gboolean mono, stereo;
+ if (sbc == NULL)
+ return NULL;
+
structure = gst_structure_empty_new("audio/x-sbc");
value = g_value_init(g_new0(GValue, 1), G_TYPE_STRING);
--
1.7.1
^ permalink raw reply related
* Re: [RFC] BlueZ D-Bus Sim Access Profile Server API description
From: Suraj Sumangala @ 2010-09-13 12:29 UTC (permalink / raw)
To: Waldemar.Rymarkiewicz@tieto.com
Cc: Suraj Sumangala, linux-bluetooth@vger.kernel.org,
Jothikumar Mothilal
In-Reply-To: <99B09243E1A5DA4898CDD8B700111448097968E653@EXMB04.eu.tieto.com>
Hi Waldek,
On 9/13/2010 5:41 PM, Waldemar.Rymarkiewicz@tieto.com wrote:
> Hi Suraj,
>
>> + void Disconnect(string type)
>> +
>> + This initiates a SAP disconnection from
>> SAP server.
>> +
>> + The type parameter specifies the type
>> of disconnection.
>> +
>> + "Graceful" -> lets the SAP client initiate a
>> + garceful disconnection.
>> +
>> + "Immediate" -> disconnects the connection
>> + immediately from the server.
>
> How agent will use this method? I mean when it is supposed to use gracefull and when immediate disconnection?
The agent will be in a better position to take this decision as it will
be interfacing between actual card reader and SAP server.
For example, if the agent is connected to an external card reader and
it has lost connection with the reader. It can ask for an Immediate
disconnection.
If disconnection was triggered by a user action, it can decide to call
this API with Graceful as the parameter.
>
>> +Signals PropertyChanged(string name, variant value)
>> +
>> + This signal indicates a changed value
>> of the given
>> + property.
>
> Is the signal really needed? Who is interested in keeping track on properties?
One candidate would be when the MessageSize is changed.
Another one will be with the "SimStatus" property. It makes sense to
raise his signal after the server sends the STATUS IND response
successfully.
But, it is a fact that most of the Properties are set by the Agent
itself. So agent will know that they have changed.
>
> Thanks,
> /Waldek
Regards
Suraj
^ permalink raw reply
* Printing over BT without OBEX-BPP
From: Zaahir Khan @ 2010-09-13 12:24 UTC (permalink / raw)
To: linux-bluetooth
Dear All,
We are having APM BT over UART.
Our object is to print over BT.
Is it possible to print without using OBEX-BPP?
Any help highly appreciated.
Thanks & regards,
Zaahir Khan
^ permalink raw reply
* RE: [RFC] BlueZ D-Bus Sim Access Profile Server API description
From: Waldemar.Rymarkiewicz @ 2010-09-13 12:11 UTC (permalink / raw)
To: suraj, linux-bluetooth; +Cc: Jothikumar.Mothilal
In-Reply-To: <1284374584-12282-1-git-send-email-suraj@atheros.com>
Hi Suraj,
>+ void Disconnect(string type)
>+
>+ This initiates a SAP disconnection from
>SAP server.
>+
>+ The type parameter specifies the type
>of disconnection.
>+
>+ "Graceful" -> lets the SAP client initiate a
>+ garceful disconnection.
>+
>+ "Immediate" -> disconnects the connection
>+ immediately from the server.
How agent will use this method? I mean when it is supposed to use gracefull and when immediate disconnection?
>+Signals PropertyChanged(string name, variant value)
>+
>+ This signal indicates a changed value
>of the given
>+ property.
Is the signal really needed? Who is interested in keeping track on properties?
Thanks,
/Waldek
^ permalink raw reply
* Re: [RFC] BlueZ D-Bus Sim Access Profile Server API description
From: Suraj Sumangala @ 2010-09-13 11:31 UTC (permalink / raw)
To: linux-bluetooth, Jothikumar.Mothilal
In-Reply-To: <20100913105932.GA3566@jh-x301>
Hi Johan,
On 9/13/2010 4:29 PM, Johan Hedberg wrote:
> Hi Suraj,
>
> On Mon, Sep 13, 2010, Suraj Sumangala wrote:
>> + void Response(string command, string result, object response)
>
> This method should be removed. Instead, you should use the methor return
> messages for the commands to relay the response information.
Ok,
Should we have the method like,
struct RequestATR(string command, variant param)
where, struct = { string, array{uint8} )
>
>> +Sim Access Server Agent hierarchy
>> +=================================
>> +
>> +Service unique name
>> +Interface org.bluez.SAPServerAgent
>> +Object path freely definable
>> +
>> +Methods Request(string command, object param)
>
> Since the set of SAP commands is fixed and rather short it'd be much
> simpler if you have a separate D-Bus method for each command
> (particularly from the method and method return signature perspective).
> You also seem to have some confusion about what an "object" type
> parameter is. It seems you're using it for some sort of variant type
> when it will only ever represent a simple object path.
Thanks, My mistake. I was referring to a variant type there.
>
> Johan
Regards
Suraj
^ permalink raw reply
* Re: [RFC] BlueZ D-Bus Sim Access Profile Server API description
From: Johan Hedberg @ 2010-09-13 10:59 UTC (permalink / raw)
To: Suraj Sumangala; +Cc: linux-bluetooth, Jothikumar.Mothilal
In-Reply-To: <1284374584-12282-1-git-send-email-suraj@atheros.com>
Hi Suraj,
On Mon, Sep 13, 2010, Suraj Sumangala wrote:
> + void Response(string command, string result, object response)
This method should be removed. Instead, you should use the methor return
messages for the commands to relay the response information.
> +Sim Access Server Agent hierarchy
> +=================================
> +
> +Service unique name
> +Interface org.bluez.SAPServerAgent
> +Object path freely definable
> +
> +Methods Request(string command, object param)
Since the set of SAP commands is fixed and rather short it'd be much
simpler if you have a separate D-Bus method for each command
(particularly from the method and method return signature perspective).
You also seem to have some confusion about what an "object" type
parameter is. It seems you're using it for some sort of variant type
when it will only ever represent a simple object path.
Johan
^ permalink raw reply
* [RFC] BlueZ D-Bus Sim Access Profile Server API description
From: Suraj Sumangala @ 2010-09-13 10:43 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jothikumar.Mothilal, Suraj Sumangala
Hi,
Below is the Sim Access Profile server role API discription.
Please let me know your comments.
Regards
Suraj
---
Makefile.am | 2 +-
doc/sap-api.txt | 216 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 217 insertions(+), 1 deletions(-)
create mode 100644 doc/sap-api.txt
diff --git a/Makefile.am b/Makefile.am
index a8829d9..52537bc 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -350,7 +350,7 @@ EXTRA_DIST += doc/manager-api.txt \
doc/service-api.txt doc/agent-api.txt doc/attribute-api.txt \
doc/serial-api.txt doc/network-api.txt \
doc/input-api.txt doc/audio-api.txt doc/control-api.txt \
- doc/hfp-api.txt doc/assigned-numbers.txt
+ doc/hfp-api.txt doc/assigned-numbers.txt doc/sap-api.txt
AM_YFLAGS = -d
diff --git a/doc/sap-api.txt b/doc/sap-api.txt
new file mode 100644
index 0000000..9a684fa
--- /dev/null
+++ b/doc/sap-api.txt
@@ -0,0 +1,216 @@
+BlueZ D-Bus Sim Access Profile API description
+**********************************************
+
+Copyright (C) 2009-2010 Atheros Communication Ltd
+
+
+Sim Access Server hierarchy
+===========================
+
+Service org.bluez
+Interface org.bluez.SAPServer
+Object path [variable prefix]/{hci0,hci1,...}
+
+This interface is available for devices which can function as the
+Server role of the Sim Access profiles.
+It is intended to be used with external stacks / handlers of the Sim Access
+protocol.
+
+
+Methods void RegisterAgent(object agent)
+
+ This registers the Sim Access server agent.
+ This also registers the profile with the service
+ databse and start waiting for an RFCOMM connection
+ on the SAP server channel.
+
+ The object path defines the path the of the agent.
+
+ If an application disconnects from the bus all
+ of its registered agents will be removed.
+
+ Possible errors: org.bluez.Error.InvalidArguments
+ org.bluez.Error.AlreadyExists
+ org.bluez.Error.Failed
+
+ void UnregisterAgent(object agent)
+
+ This unregisters the agent that has been previously
+ registered. The object path parameter must match the
+ same value that has been used on registration.
+
+ Possible errors: org.bluez.Error.DoesNotExist
+ org.bluez.Error.InvalidArguments
+ org.bluez.Error.Failed
+
+ void Response(string command, string result, object response)
+
+ This sends a SAP response packet to a SAP sequest.
+
+ The command parameter specifies the SAP command for
+ which response is being sent.
+
+ The result parameter specifies the ResultCode for the
+ operation.
+
+ The object response specifies the response packet to
+ be sent if any.
+
+ Below mentioned are the parameters and possible value.
+
+ command result response
+ ----------------------------------------------------
+
+ Connect OkSuccess NA
+ ConnectFailed
+ OkOngoingCall
+
+ APDU OkSuccess array{uint8}
+ NoReason
+ CardNotAccessible
+ CardPoweredOff
+ CardRemoved
+
+ APDU7816 OkSuccess array{uint8}
+ NoReason
+ CardNotAccessible
+ CardPoweredOff
+ CardRemoved
+
+ ATR OkSuccess array{uint8}
+ NoReason
+ CardPoweredOff
+ CardRemoved
+ DataNotAvailable
+
+ SimPowerOn OkSuccess NA
+ NoReason
+ CardNotAccessible
+ CardRemoved
+ CardPoweredOn
+
+ SimPowerOff OkSuccess NA
+ NoReason
+ CardPoweredOff
+ CardRemoved
+
+ Reset OkSuccess NA
+ NoReason
+ CardNotAccessible
+ CardPoweredOff
+ CardRemoved
+
+ CardReaderStatus OkSuccess uint8
+ NoReason
+ DataNotAvailable
+
+ TransportProtocol OkSuccess NA
+ NotSupported
+
+ Disconnect NA NA
+
+ Possible errors: org.bluez.Error.InvalidArguments
+ org.bluez.Error.Failed
+
+ void Disconnect(string type)
+
+ This initiates a SAP disconnection from SAP server.
+
+ The type parameter specifies the type of disconnection.
+
+ "Graceful" -> lets the SAP client initiate a
+ garceful disconnection.
+
+ "Immediate" -> disconnects the connection
+ immediately from the server.
+
+ void SetProperty(string name, variant value)
+
+ Changes the value of the specified property. Only
+ properties that are listed a read-write are changeable.
+ On success this will emit a PropertyChanged signal.
+
+ Possible Errors: org.bluez.Error.DoesNotExist
+ org.bluez.Error.InvalidArguments
+
+ dict GetProperties()
+
+ Returns all properties for the interface. See the
+ properties section for available properties.
+
+ Possible Errors: org.bluez.Error.InvalidArguments
+
+Signals PropertyChanged(string name, variant value)
+
+ This signal indicates a changed value of the given
+ property.
+
+Properties string SimStatus [readwrite]
+
+ Specifies the availability of the SIM.
+
+ The possible value are
+
+ "UnknownError"
+ "CardReset"
+ "CardNotAccesible"
+ "CardRemoved"
+ "CardInsterted"
+ "CardRecovered"
+
+ uint16 MaxMessageSize [readwrite]
+
+ The maximum possible message size supported by
+ SAP server.
+
+ uint16 MinMessageSize [readwrite]
+
+ The minimum possible message size supported by
+ SAP server.
+
+ uint16 MessageSize [readonly]
+
+ The negotiated message size for the current connection.
+ This is valid only when there is an active
+ SAP connection.
+
+Sim Access Server Agent hierarchy
+=================================
+
+Service unique name
+Interface org.bluez.SAPServerAgent
+Object path freely definable
+
+Methods Request(string command, object param)
+
+ This method gets called whenever a SAP request is received
+ from SAP client. This will help deliver the
+ SAP request to the Agent.
+
+ The command parameter specifies the SAP request type
+ received.
+
+ The param parameter specifies the command parameter
+ packet received from SAP client.
+
+ Below mentioned is the parameters and possible value.
+
+ command parameter
+ ----------------------------------------------------
+
+ Connect NA
+ APDU array{uint8}
+ APDU7816 array{uint8}
+ ATR NA
+ SimPowerOn NA
+ SimPowerOff NA
+ Reset NA
+ CardReaderStatus NA
+ TransportProtocol uint8
+ Disconnect NA
+
+ void Release()
+
+ This method gets called whenever the service daemon
+ unregisters the agent or whenever the Adapter where
+ the SimAccessServerAgent registers itself is removed.
--
1.7.0.4
^ permalink raw reply related
* RE: MAP implementation status
From: Counihan, Tom @ 2010-09-13 10:11 UTC (permalink / raw)
To: Radoslaw Jablonski, linux-bluetooth@vger.kernel.org
In-Reply-To: <4C88D729.7050803@nokia.com>
[-- Attachment #1: Type: text/plain, Size: 2074 bytes --]
Hi Radoslaw,
>-----Original Message-----
>From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-
>owner@vger.kernel.org] On Behalf Of Radoslaw Jablonski
>Sent: 09 September 2010 13:47
>To: linux-bluetooth@vger.kernel.org
>Subject: MAP implementation status
>
>
> Hi all,
>We plan to start implementation of Message Access Profile Server as
>obexd plugin. Before we start with coding part I need to check if
>someone else started implementing MAP Server, MNS Server of Map client.
>If some code is already available, then we could combine our forces to
>add MAP support for OBEXD.
This is something I've been focusing on recently.
Attached is my modest start to this.
My initial strategy - even though its IVI client side I'm most interested in - was to tackle server side, essentially bring up both sides of the interface incrementally.
I was going to employ a strategy of, instead of doing it in big bulk, dropping small unobtrusive patches into the trunk, so interested people could see and contribute to the activity.
I'm struggling in defining the right level of patch to upstream - maybe folks here can comment on the attached - is it of acceptable substance or would more meat be require to make it a meaningful contribution?
I've taken on board the suggestion from Marcel and Johan to focus on SMS data first. That makes sense to me.
Hope the above and attached is of use.
Looking forward to hearing from you - any thoughts/insights/criticism are most welcome.
Regards
Tom
--------------------------------------------------------------
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
[-- Attachment #2: 0001-Initial-intro-for-MAP.patch --]
[-- Type: application/octet-stream, Size: 8107 bytes --]
From 66b42f3a3e1520d8cdb2b7549215224d0abde606 Mon Sep 17 00:00:00 2001
From: Tom Counihan <tom.counihan@intel.com>
Date: Sun, 5 Sep 2010 15:01:34 +0100
Subject: [PATCH] Initial intro for MAP
Bootstraping MAP implementation
---
plugins/map.c | 232 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
plugins/sms.h | 49 ++++++++++++
2 files changed, 281 insertions(+), 0 deletions(-)
create mode 100644 plugins/map.c
create mode 100644 plugins/sms.h
diff --git a/plugins/map.c b/plugins/map.c
new file mode 100644
index 0000000..2a483e7
--- /dev/null
+++ b/plugins/map.c
@@ -0,0 +1,232 @@
+/*
+ * OBEX Server
+ *
+ * Copyright (C) 2009-2010 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * 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 Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ *
+ *
+ * Author Name <tom.counihan@intel.com>
+ * - FIXME: Short log of changes
+ *
+ *
+ * FIXME: DOCUMENTATION: entry points and code roadmap. What does
+ * it do, how does it work, etc.
+ * - Postpone Notification feature until rudimentary functionality up
+ */
+
+#ifdef HAVE_CONFIG_H
+#include <config.h>
+#endif
+
+#include <stdio.h>
+#include <string.h>
+#include <errno.h>
+#include <glib.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <arpa/inet.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <fcntl.h>
+
+#include <openobex/obex.h>
+#include <openobex/obex_const.h>
+
+#include "plugin.h"
+#include "log.h"
+#include "obex.h"
+#include "service.h"
+
+#define MAP_CHANNEL 16
+
+#define MAXLISTCOUNT_TAG 0x01
+#define STARTOFFSET_TAG 0x02
+#define FILTERMESSAGETYPE_TAG 0x03
+#define FILTERBEGINPERIOD_TAG 0x04
+#define ENDFILTERPERIODEND_TAG 0x05
+#define FILTERREADSTATUS_TAG 0x06
+#define FILTERRECIPIENT_TAG 0x07
+#define FILTERORIGINATOR_TAG 0x08
+#define FILTERPRIORITY_TAG 0x09
+#define ATTACHEMENT_TAG 0x0A
+#define TRANSPARENT_TAG 0x0B
+#define RETRY_TAG 0x0C
+#define NEWMESSAGE_TAG 0x0D
+#define NOTIFICATIONSTATUS_TAG 0x0E
+#define MASINSTANCEID_TAG 0x0F
+#define PARAMETERMASK_TAG 0x10
+#define FOLDERLISTINGSIZE_TAG 0x11
+#define MESSAGELISTINGSIZE_TAG 0x12
+#define SUBJECTLENGTH_TAG 0x13
+#define CHARSET_TAG 0x14
+#define FRACTIONREQUEST_TAG 0x15
+#define FRACTIONDELIVERED_TAG 0x16
+#define STATUSINDICATOR_TAG 0x17
+#define STATUSVALUE_TAG 0x18
+#define MSETIME_TAG 0x19
+
+/* The following length is in the unit of byte */
+#define MAXLISTCOUNT_LEN 2
+#define STARTOFFSET_LEN 2
+#define FILTERMESSAGETYPE_LEN 1
+#define FILTERREADSTATUS_LEN 1
+#define FILTERPRIORITY_LEN 1
+#define ATTACHEMENT_LEN 1
+#define TRANSPARENT_LEN 1
+#define RETRY_LEN 1
+#define NEWMESSAGE_LEN 1
+#define NOTIFICATIONSTATUS_LEN 1
+#define MASINSTANCEID_LEN 1
+#define PARAMETERMASK_LEN 4
+#define FOLDERLISTINGSIZE_LEN 2
+#define MESSAGELISTINGSIZE_LEN 2
+#define SUBJECTLENGTH_LEN 1
+#define CHARSET_LEN 1
+#define FRACTIONREQUEST_LEN 1
+#define FRACTIONDELIVERED_LEN 1
+#define STATUSINDICATOR_LEN 1
+#define STATUSVALUE_LEN 1
+
+#define MAP_RECORD "<?xml version=\"1.0\" encoding=\"UTF-8\" ?> \
+<record> \
+ <attribute id=\"0x0001\"> \
+ <sequence> \
+ <uuid value=\"0x1132\"/> \
+ </sequence> \
+ </attribute> \
+ \
+ <attribute id=\"0x0004\"> \
+ <sequence> \
+ <sequence> \
+ <uuid value=\"0x0100\"/> \
+ </sequence> \
+ <sequence> \
+ <uuid value=\"0x0003\"/> \
+ <uint8 value=\"%u\" name=\"channel\"/> \
+ </sequence> \
+ <sequence> \
+ <uuid value=\"0x0008\"/> \
+ </sequence> \
+ </sequence> \
+ </attribute> \
+ \
+ <attribute id=\"0x0009\"> \
+ <sequence> \
+ <sequence> \
+ <uuid value=\"0x1134\"/> \
+ <uint16 value=\"0x0100\" name=\"version\"/> \
+ </sequence> \
+ </sequence> \
+ </attribute> \
+ \
+ <attribute id=\"0x0100\"> \
+ <text value=\"%s\" name=\"name\"/> \
+ </attribute> \
+ \
+ <attribute id=\"0x0316\"> \
+ <uint8 value=\"0x02\"/> \
+ </attribute> \
+</record>"
+
+
+static const uint8_t MAP_TARGET[TARGET_SIZE] = {
+ 0xBB, 0x58, 0x2B, 0x40, 0x42, 0x0C, 0x11, 0xDB,
+ 0xB0, 0xDE, 0x08, 0x00, 0x20, 0x0C, 0x9A, 0x66 };
+
+struct map_session {
+ struct apparam_field *params;
+ char *folder;
+ uint32_t find_handle;
+ GString *buffer;
+};
+
+/* TODO Fix this entry */
+struct cache_entry {
+ uint64_t handle;
+ char *id;
+ char *name;
+ char *sound;
+ char *tel;
+};
+
+
+static void *map_connect(struct obex_session *os, int *err)
+{
+ /* Rejects all connects for the moment */
+ struct map_session *map;
+
+ map = g_new0(struct map_session, 1);
+
+ return map;
+}
+
+static int map_get(struct obex_session *os, obex_object_t *obj,
+ gboolean *stream, void *user_data)
+{
+ /* Rejects all gets for the moment */
+ return -EBADR;
+}
+
+static int map_setpath(struct obex_session *os, obex_object_t *obj,
+ void *user_data)
+{
+ /* Rejects all set paths for the moment */
+ return -EBADR;
+}
+
+static void map_disconnect(struct obex_session *os, void *user_data)
+{
+ /* Rejects all disconnect for the moment */
+
+}
+
+static int map_chkput(struct obex_session *os, void *user_data)
+{
+ /* Rejects all PUTs */
+ return -EBADR;
+}
+
+
+static struct obex_service_driver map = {
+ .name = "Message Access server",
+ .service = OBEX_MAP,
+ .channel = MAP_CHANNEL,
+ .record = MAP_RECORD,
+ .target = MAP_TARGET,
+ .target_size = TARGET_SIZE,
+ .connect = map_connect,
+ .get = map_get,
+ .setpath = map_setpath,
+ .disconnect = map_disconnect,
+ .chkput = map_chkput
+};
+
+static int map_init(void)
+{
+ int err;
+
+
+ return 0;
+
+ return err;
+}
+static void map_exit(void)
+{
+ obex_service_driver_unregister(&map);
+
+}
+
+OBEX_PLUGIN_DEFINE(map, map_init, map_exit)
diff --git a/plugins/sms.h b/plugins/sms.h
new file mode 100644
index 0000000..8cc9a30
--- /dev/null
+++ b/plugins/sms.h
@@ -0,0 +1,49 @@
+/*
+ * OBEX Server
+ *
+ * Copyright (C) 2009-2010 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * 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 Street, Fifth Floor, Boston, MA
+ * 02110-1301, USA.
+ *
+ *
+ * Author Name <tom.counihan@intel.com>
+ * - FIXME: Short log of changes
+ *
+ *
+ * FIXME: DOCUMENTATION: entry points and code roadmap. What does
+ * it do, how does it work, etc.
+ */
+
+struct apparam_field {
+ /* FolderListing and MessageListing attributes */
+ uint16_t maxlistcount;
+ uint16_t liststartoffset;
+
+ /* MessageListing attributes only */
+ uint8_t subjectlength;
+ uint32_t parametermask;
+ uint8_t filtermessagetype;
+ uint8_t *filterperiodbegin;
+ uint8_t *filterperiodend;
+ uint8_t filterreadstatus;
+ uint8_t *filterrecipient;
+ uint8_t *filteroriginator;
+ uint8_t filterpriority;
+
+ /* Message function attributes only */
+ uint8_t attachement;
+ uint8_t charset;
+ uint8_t fractionrequest;
+};
--
1.7.1.1
^ permalink raw reply related
* Re: [PATCH V2 0/2] bluez: cleanup btio library
From: Johan Hedberg @ 2010-09-13 8:26 UTC (permalink / raw)
To: Zhenhua Zhang; +Cc: linux-bluetooth
In-Reply-To: <1284365851-8066-1-git-send-email-zhenhua.zhang@intel.com>
Hi Zhenhua,
On Mon, Sep 13, 2010, Zhenhua Zhang wrote:
> These two patches are to cleanup BlueZ btio.[ch] in bluez source directory.
Thanks. These patches have also been pushed upstream.
Johan
^ permalink raw reply
* [PATCH V2 2/2] btio: Seperate btio.[ch] into btio directory
From: Zhenhua Zhang @ 2010-09-13 8:17 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1284365851-8066-1-git-send-email-zhenhua.zhang@intel.com>
Seperate btio.[ch] from src directory to btio sub-folder.
---
Makefile.am | 8 +++++---
Makefile.tools | 2 +-
{src => btio}/btio.c | 0
{src => btio}/btio.h | 0
4 files changed, 6 insertions(+), 4 deletions(-)
rename {src => btio}/btio.c (100%)
rename {src => btio}/btio.h (100%)
diff --git a/Makefile.am b/Makefile.am
index 7895be2..a8829d9 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -102,6 +102,8 @@ endif
gdbus_sources = gdbus/gdbus.h gdbus/mainloop.c gdbus/watch.c \
gdbus/object.c gdbus/polkit.c
+btio_sources = btio/btio.h btio/btio.c
+
builtin_modules =
builtin_sources =
builtin_nodist =
@@ -216,14 +218,14 @@ endif
sbin_PROGRAMS += src/bluetoothd
src_bluetoothd_SOURCES = $(gdbus_sources) $(builtin_sources) \
- $(attrib_sources) \
+ $(attrib_sources) $(btio_sources) \
$(mcap_sources) \
src/main.c src/log.h src/log.c \
src/security.c src/rfkill.c src/hcid.h src/sdpd.h \
src/sdpd-server.c src/sdpd-request.c \
src/sdpd-service.c src/sdpd-database.c \
src/attrib-server.h src/attrib-server.c \
- src/sdp-xml.h src/sdp-xml.c src/btio.h src/btio.c \
+ src/sdp-xml.h src/sdp-xml.c \
src/textfile.h src/textfile.c \
src/glib-helper.h src/glib-helper.c \
src/oui.h src/oui.c src/uinput.h src/ppoll.h \
@@ -357,7 +359,7 @@ AM_CFLAGS = @DBUS_CFLAGS@ @GLIB_CFLAGS@ @CAPNG_CFLAGS@ \
INCLUDES = -I$(builddir)/lib -I$(builddir)/src -I$(srcdir)/src \
-I$(srcdir)/audio -I$(srcdir)/sbc -I$(srcdir)/gdbus \
- -I$(srcdir)/attrib
+ -I$(srcdir)/attrib -I$(srcdir)/btio
if MCAP
INCLUDES += -I$(builddir)/health
diff --git a/Makefile.tools b/Makefile.tools
index 1c46542..14ecf31 100644
--- a/Makefile.tools
+++ b/Makefile.tools
@@ -170,7 +170,7 @@ test_bdaddr_LDADD = lib/libbluetooth.la
test_agent_LDADD = @DBUS_LIBS@
-test_btiotest_SOURCES = test/btiotest.c src/btio.h src/btio.c
+test_btiotest_SOURCES = test/btiotest.c btio/btio.h btio/btio.c
test_btiotest_LDADD = @GLIB_LIBS@ lib/libbluetooth.la
test_test_textfile_SOURCES = test/test-textfile.c src/textfile.h src/textfile.c
diff --git a/src/btio.c b/btio/btio.c
similarity index 100%
rename from src/btio.c
rename to btio/btio.c
diff --git a/src/btio.h b/btio/btio.h
similarity index 100%
rename from src/btio.h
rename to btio/btio.h
--
1.7.0.4
^ permalink raw reply related
* [PATCH V2 1/2] btio: Add ifndef/endif guard for btio.h
From: Zhenhua Zhang @ 2010-09-13 8:17 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1284365851-8066-1-git-send-email-zhenhua.zhang@intel.com>
To avoid circular inclusion of include file.
---
src/btio.h | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/btio.h b/src/btio.h
index 81fda8e..d373ed1 100644
--- a/src/btio.h
+++ b/src/btio.h
@@ -21,6 +21,8 @@
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*
*/
+#ifndef BT_IO_H
+#define BT_IO_H
#include <glib.h>
@@ -92,3 +94,4 @@ GIOChannel *bt_io_listen(BtIOType type, BtIOConnect connect,
GDestroyNotify destroy, GError **err,
BtIOOption opt1, ...);
+#endif
--
1.7.0.4
^ permalink raw reply related
* [PATCH V2 0/2] bluez: cleanup btio library
From: Zhenhua Zhang @ 2010-09-13 8:17 UTC (permalink / raw)
To: linux-bluetooth
Hi,
These two patches are to cleanup BlueZ btio.[ch] in bluez source directory.
Regards,
Zhenhua
^ permalink raw reply
* Re: [PATCH V2 0/2] cleanup btio library
From: Johan Hedberg @ 2010-09-13 8:16 UTC (permalink / raw)
To: Zhenhua Zhang; +Cc: linux-bluetooth
In-Reply-To: <1284365042-7526-1-git-send-email-zhenhua.zhang@intel.com>
Hi Zhenhua,
On Mon, Sep 13, 2010, Zhenhua Zhang wrote:
> These two patches are to cleanup btio.[ch] in obex source directory.
Thanks. Both patches have been pushed to obexd upstream.
Johan
^ permalink raw reply
* [PATCH V2 2/2] btio: Seperate btio.[ch] into btio directory
From: Zhenhua Zhang @ 2010-09-13 8:04 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1284365042-7526-1-git-send-email-zhenhua.zhang@intel.com>
Seperate btio.[ch] from src directory to btio sub-folder.
---
Makefile.am | 19 ++++++++++---------
{src => btio}/btio.c | 0
{src => btio}/btio.h | 0
3 files changed, 10 insertions(+), 9 deletions(-)
rename {src => btio}/btio.c (100%)
rename {src => btio}/btio.h (100%)
diff --git a/Makefile.am b/Makefile.am
index e6940bc..175747c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -19,6 +19,8 @@ gwobex_sources = gwobex/gw-obex.h gwobex/gw-obex.c \
gwobex/obex-xfer.h gwobex/obex-xfer.c \
gwobex/utils.h gwobex/utils.c gwobex/log.h
+btio_sources = btio/btio.h btio/btio.c
+
libexec_PROGRAMS =
if SERVER
@@ -66,11 +68,10 @@ builtin_nodist += plugins/phonebook.c
libexec_PROGRAMS += src/obexd
-src_obexd_SOURCES = $(gdbus_sources) $(builtin_sources) \
+src_obexd_SOURCES = $(gdbus_sources) $(builtin_sources) $(btio_sources) \
src/main.c src/obexd.h src/plugin.h src/plugin.c \
- src/log.h src/log.c src/btio.h src/btio.c \
- src/dbus.h src/manager.c src/obex.h src/obex.c \
- src/obex-priv.h \
+ src/log.h src/log.c src/dbus.h src/manager.c \
+ src/obex.h src/obex.c src/obex-priv.h \
src/mimetype.h src/mimetype.c \
src/service.h src/service.c \
src/transport.h src/transport.c \
@@ -108,13 +109,12 @@ service_in_files += client/obex-client.service.in
libexec_PROGRAMS += client/obex-client
-client_obex_client_SOURCES = $(gdbus_sources) $(gwobex_sources) client/main.c \
- client/session.h client/session.c \
+client_obex_client_SOURCES = $(gdbus_sources) $(gwobex_sources) $(btio_sources) \
+ client/main.c client/session.h client/session.c \
src/log.h src/log.c \
client/pbap.h client/pbap.c \
client/sync.h client/sync.c \
- client/transfer.h client/transfer.c \
- src/btio.c src/btio.h
+ client/transfer.h client/transfer.c
client_obex_client_LDADD = @GLIB_LIBS@ @DBUS_LIBS@ @OPENOBEX_LIBS@ @BLUEZ_LIBS@
endif
@@ -127,7 +127,8 @@ AM_CFLAGS = @OPENOBEX_CFLAGS@ @BLUEZ_CFLAGS@ @EBOOK_CFLAGS@ \
-DOBEX_PLUGIN_BUILTIN -DPLUGINDIR=\""$(plugindir)"\"
INCLUDES = -I$(builddir)/src -I$(srcdir)/src -I$(srcdir)/plugins \
- -I$(srcdir)/gdbus -I$(srcdir)/gwobex
+ -I$(srcdir)/gdbus -I$(srcdir)/gwobex \
+ -I$(srcdir)/btio
CLEANFILES = $(service_DATA) $(builtin_files)
diff --git a/src/btio.c b/btio/btio.c
similarity index 100%
rename from src/btio.c
rename to btio/btio.c
diff --git a/src/btio.h b/btio/btio.h
similarity index 100%
rename from src/btio.h
rename to btio/btio.h
--
1.7.0.4
^ permalink raw reply related
* [PATCH V2 1/2] btio: Replace void * with gpointer
From: Zhenhua Zhang @ 2010-09-13 8:04 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1284365042-7526-1-git-send-email-zhenhua.zhang@intel.com>
To make it consistent with bluez btio.c.
---
src/btio.c | 24 ++++++++++++------------
src/btio.h | 10 +++++-----
2 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/src/btio.c b/src/btio.c
index 42a3bcd..8b273ca 100644
--- a/src/btio.c
+++ b/src/btio.c
@@ -62,20 +62,20 @@ struct set_opts {
struct connect {
BtIOConnect connect;
- void *user_data;
+ gpointer user_data;
GDestroyNotify destroy;
};
struct accept {
BtIOConnect connect;
- void *user_data;
+ gpointer user_data;
GDestroyNotify destroy;
};
struct server {
BtIOConnect connect;
BtIOConfirm confirm;
- void *user_data;
+ gpointer user_data;
GDestroyNotify destroy;
};
@@ -115,7 +115,7 @@ static gboolean check_nval(GIOChannel *io)
}
static gboolean accept_cb(GIOChannel *io, GIOCondition cond,
- void *user_data)
+ gpointer user_data)
{
struct accept *accept = user_data;
GError *err = NULL;
@@ -136,7 +136,7 @@ static gboolean accept_cb(GIOChannel *io, GIOCondition cond,
}
static gboolean connect_cb(GIOChannel *io, GIOCondition cond,
- void *user_data)
+ gpointer user_data)
{
struct connect *conn = user_data;
GError *gerr = NULL;
@@ -169,7 +169,7 @@ static gboolean connect_cb(GIOChannel *io, GIOCondition cond,
}
static gboolean server_cb(GIOChannel *io, GIOCondition cond,
- void *user_data)
+ gpointer user_data)
{
struct server *server = user_data;
int srv_sock, cli_sock;
@@ -201,7 +201,7 @@ static gboolean server_cb(GIOChannel *io, GIOCondition cond,
}
static void server_add(GIOChannel *io, BtIOConnect connect,
- BtIOConfirm confirm, void *user_data,
+ BtIOConfirm confirm, gpointer user_data,
GDestroyNotify destroy)
{
struct server *server;
@@ -219,7 +219,7 @@ static void server_add(GIOChannel *io, BtIOConnect connect,
}
static void connect_add(GIOChannel *io, BtIOConnect connect,
- void *user_data, GDestroyNotify destroy)
+ gpointer user_data, GDestroyNotify destroy)
{
struct connect *conn;
GIOCondition cond;
@@ -234,7 +234,7 @@ static void connect_add(GIOChannel *io, BtIOConnect connect,
(GDestroyNotify) connect_remove);
}
-static void accept_add(GIOChannel *io, BtIOConnect connect, void *user_data,
+static void accept_add(GIOChannel *io, BtIOConnect connect, gpointer user_data,
GDestroyNotify destroy)
{
struct accept *accept;
@@ -1046,7 +1046,7 @@ static gboolean get_valist(GIOChannel *io, BtIOType type, GError **err,
return FALSE;
}
-gboolean bt_io_accept(GIOChannel *io, BtIOConnect connect, void *user_data,
+gboolean bt_io_accept(GIOChannel *io, BtIOConnect connect, gpointer user_data,
GDestroyNotify destroy, GError **err)
{
int sock;
@@ -1195,7 +1195,7 @@ failed:
}
GIOChannel *bt_io_connect(BtIOType type, BtIOConnect connect,
- void *user_data, GDestroyNotify destroy,
+ gpointer user_data, GDestroyNotify destroy,
GError **gerr, BtIOOption opt1, ...)
{
GIOChannel *io;
@@ -1249,7 +1249,7 @@ GIOChannel *bt_io_connect(BtIOType type, BtIOConnect connect,
}
GIOChannel *bt_io_listen(BtIOType type, BtIOConnect connect,
- BtIOConfirm confirm, void *user_data,
+ BtIOConfirm confirm, gpointer user_data,
GDestroyNotify destroy, GError **err,
BtIOOption opt1, ...)
{
diff --git a/src/btio.h b/src/btio.h
index e9dcc9f..d373ed1 100644
--- a/src/btio.h
+++ b/src/btio.h
@@ -72,11 +72,11 @@ typedef enum {
BT_IO_SEC_HIGH,
} BtIOSecLevel;
-typedef void (*BtIOConfirm)(GIOChannel *io, void *user_data);
+typedef void (*BtIOConfirm)(GIOChannel *io, gpointer user_data);
-typedef void (*BtIOConnect)(GIOChannel *io, GError *err, void *user_data);
+typedef void (*BtIOConnect)(GIOChannel *io, GError *err, gpointer user_data);
-gboolean bt_io_accept(GIOChannel *io, BtIOConnect connect, void *user_data,
+gboolean bt_io_accept(GIOChannel *io, BtIOConnect connect, gpointer user_data,
GDestroyNotify destroy, GError **err);
gboolean bt_io_set(GIOChannel *io, BtIOType type, GError **err,
@@ -86,11 +86,11 @@ gboolean bt_io_get(GIOChannel *io, BtIOType type, GError **err,
BtIOOption opt1, ...);
GIOChannel *bt_io_connect(BtIOType type, BtIOConnect connect,
- void *user_data, GDestroyNotify destroy,
+ gpointer user_data, GDestroyNotify destroy,
GError **err, BtIOOption opt1, ...);
GIOChannel *bt_io_listen(BtIOType type, BtIOConnect connect,
- BtIOConfirm confirm, void *user_data,
+ BtIOConfirm confirm, gpointer user_data,
GDestroyNotify destroy, GError **err,
BtIOOption opt1, ...);
--
1.7.0.4
^ permalink raw reply related
* [PATCH V2 0/2] cleanup btio library
From: Zhenhua Zhang @ 2010-09-13 8:04 UTC (permalink / raw)
To: linux-bluetooth
Hi,
These two patches are to cleanup btio.[ch] in obex source directory.
Regards,
Zhenhua
^ permalink raw reply
* Re: dund
From: Bastien Nocera @ 2010-09-12 14:45 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org; +Cc: Ivan Baidakou
In-Reply-To: <20100912163714.09aac1e3@vaio.site>
On Sun, 2010-09-12 at 16:37 +0200, Vladimir Botka wrote:
> On Sun, 12 Sep 2010 11:44:11 +0300
> Ivan Baidakou <the.dmol@gmail.com> wrote:
>
> > You haven't real experience, right?
>
> I have.
And so have I, I got the patch upstream into pilot-link, and helped get
the gnome-pilot support integrated.
^ permalink raw reply
* Re: dund
From: Vladimir Botka @ 2010-09-12 14:37 UTC (permalink / raw)
To: Ivan Baidakou; +Cc: Bastien Nocera, linux-bluetooth@vger.kernel.org
In-Reply-To: <20100912114411.2678ffbe@gmail.com>
On Sun, 12 Sep 2010 11:44:11 +0300
Ivan Baidakou <the.dmol@gmail.com> wrote:
> You haven't real experience, right?
I have.
# pilot-xfer -p bt:00:07:E0:B3:DD:03 -l
Listening for incoming connection on bt:00:07:E0:B3:DD:03... connected!
Reading list of databases in RAM...
AdditDVSData
ADD050SData
AdditSystemSData
<snip>
Cheers,
-vlado
^ permalink raw reply
* Re: dund
From: Ivan Baidakou @ 2010-09-12 8:44 UTC (permalink / raw)
To: Bastien Nocera; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <16C0AC8E-F3CC-41A8-BE7D-C1BCB7F10CCC@hadess.net>
---=== reply ===---
You haven't real experience, right? In any case I don't know how to do
it: in the official pilot-link guide there is need to establish TCP
connection to sync (http://howto.pilot-link.org/bluesync/gb.html), and
to establish it they recommend to launch dund
(http://howto.pilot-link.org/bluesync/ga.html).
That's why I do ask here, what thing in new bluez can replace the
deprecated dund?
Best regards,
Ivan Baidakou
---=== original message ===---
Date: Sun, 12 Sep 2010 00:26:57 +0100
Subj: Re: dund
From: Bastien Nocera <hadess@hadess.net>
To: Ivan Baidakou <the.dmol@gmail.com>
On 11 Sep 2010, at 19:45, Ivan Baidakou <the.dmol@gmail.com> wrote:
> Hi All,
>
> There was DUN daemon in bluez 2.x, but in current version it moved to
> old daemons and considered deprecated. If I understand correctly its
> aim is simple to launch pppd on incoming connection.
>
> Is is possible to reach the same behaviour via current implementation
> without dund? Currently I do need dund to sync my Palm with desktop; I
> performed internet search and found not any solution.
Gnome-pilot and pilot-link both support native Bluetooth connections.
Cheers
^ permalink raw reply
* Re: dund
From: Bastien Nocera @ 2010-09-11 23:26 UTC (permalink / raw)
To: Ivan Baidakou; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <20100911214553.0d8bc6f0@gmail.com>
On 11 Sep 2010, at 19:45, Ivan Baidakou <the.dmol@gmail.com> wrote:
> Hi All,
>
> There was DUN daemon in bluez 2.x, but in current version it moved to
> old daemons and considered deprecated. If I understand correctly its
> aim is simple to launch pppd on incoming connection.
>
> Is is possible to reach the same behaviour via current implementation
> without dund? Currently I do need dund to sync my Palm with desktop; I
> performed internet search and found not any solution.
Gnome-pilot and pilot-link both support native Bluetooth connections.
Cheers
^ permalink raw reply
* dund
From: Ivan Baidakou @ 2010-09-11 18:45 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
Hi All,
There was DUN daemon in bluez 2.x, but in current version it moved to
old daemons and considered deprecated. If I understand correctly its
aim is simple to launch pppd on incoming connection.
Is is possible to reach the same behaviour via current implementation
without dund? Currently I do need dund to sync my Palm with desktop; I
performed internet search and found not any solution.
Thanks for helping.
Best regards,
Ivan Baidakou
^ permalink raw reply
* Re: set LE advertise not working...
From: Pavan Savoy @ 2010-09-10 22:22 UTC (permalink / raw)
To: Mike Tsai
Cc: Claudio Takahasi, Anderson Lizardo, Anderson Briglia,
linux-bluetooth@vger.kernel.org
In-Reply-To: <35B17FE5076C7040809188FBE7913F983F2381E185@SC1EXMB-MBCL.global.atheros.com>
So do these (my) dual mode device has some command where I can put it
in BLE (slave) mode only ?
Is that not part of spec?
PS:
Still trying to get around the spec and its uses.. so please excuse
naive questions...
On Fri, Sep 10, 2010 at 4:35 PM, Mike Tsai <Mike.Tsai@atheros.com> wrote:
>
> -----Original Message-----
> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Claudio Takahasi
> Sent: Friday, September 10, 2010 2:03 PM
> To: Anderson Lizardo
> Cc: Pavan Savoy; Anderson Briglia; linux-bluetooth@vger.kernel.org
> Subject: Re: set LE advertise not working...
>
> On Fri, Sep 10, 2010 at 5:35 PM, Anderson Lizardo
> <anderson.lizardo@openbossa.org> wrote:
>> On Fri, Sep 10, 2010 at 3:01 PM, Pavan Savoy <pavan_savoy@sify.com> wrote:
>>> No, I don't suppose my controller was in a advertising state.. even if
>>> it was why the return 0x0c? (command disallowed ..)
>>>
>>> I wanted to know whether you have some HCI-VS commands which sort of
>>> enable the LE (AMP/radio/controller) ?
>>> Is it only then the leadv command works? Or does it just works right-away.
>>> I have one of those all in 1 chips.. bt/fm-rx-tx/gps so I am wondering
>>> should I do something to enable BLE and is it some sort of un-spoken
>>> standard?
>>
>> Does LE scan work for this same hardware?
>>
>> Do you have some windows software to test this hardware ? if so, you
>> can try putting one device in advertise mode there , then attempt
>> lescan on the other (from linux)... If it works, most probably the
>> hardware might require some initialization...
>>
>> At least some hardware requires firmware upload and vendor specific
>> one-time initialization which (I think) is out of scope for hciconfig.
>>
>> Regards,
>> --
>> Anderson Lizardo
>> OpenBossa Labs - INdT
>> Manaus - Brazil
>> --
>> 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
>>
>
>> Hi All,
>
>> I noticed that some LE hardwares don't allow to enable scanning or
>> advertising when inquiry scan and/or page scan are enabled.
>> Try to disable it using hciconfig or the D-Bus method before to start
>> LE operations.
>
>> Regards,
>> Claudio.
>
> Hello,
>
> Now I remember, dual mode devices (BR/EDR/LE) are not allowed to work as peripheral (or slave) device. The default advertising mode is "connectable indirect advertising mode". When you try to enable the advertising, you are trying to make this dual mode device as a potential slave to other LE masters and that's why the controller rejects the command.
>
> Scan should work though.
>
> I don't think you can ever connect 2 dual mode devices together, you need a single mode device (LE only) as the slave,
>
> Cheers,
>
> Mike
>
>
>
> 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: set LE advertise not working...
From: Mike Tsai @ 2010-09-10 21:35 UTC (permalink / raw)
To: Claudio Takahasi, Anderson Lizardo
Cc: Pavan Savoy, Anderson Briglia, linux-bluetooth@vger.kernel.org
In-Reply-To: <AANLkTinUCN-MSEffR5mshV7PiB3AW=d+3pA8hXK8-68L@mail.gmail.com>
-----Original Message-----
From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Claudio Takahasi
Sent: Friday, September 10, 2010 2:03 PM
To: Anderson Lizardo
Cc: Pavan Savoy; Anderson Briglia; linux-bluetooth@vger.kernel.org
Subject: Re: set LE advertise not working...
On Fri, Sep 10, 2010 at 5:35 PM, Anderson Lizardo
<anderson.lizardo@openbossa.org> wrote:
> On Fri, Sep 10, 2010 at 3:01 PM, Pavan Savoy <pavan_savoy@sify.com> wrote:
>> No, I don't suppose my controller was in a advertising state.. even if
>> it was why the return 0x0c? (command disallowed ..)
>>
>> I wanted to know whether you have some HCI-VS commands which sort of
>> enable the LE (AMP/radio/controller) ?
>> Is it only then the leadv command works? Or does it just works right-away.
>> I have one of those all in 1 chips.. bt/fm-rx-tx/gps so I am wondering
>> should I do something to enable BLE and is it some sort of un-spoken
>> standard?
>
> Does LE scan work for this same hardware?
>
> Do you have some windows software to test this hardware ? if so, you
> can try putting one device in advertise mode there , then attempt
> lescan on the other (from linux)... If it works, most probably the
> hardware might require some initialization...
>
> At least some hardware requires firmware upload and vendor specific
> one-time initialization which (I think) is out of scope for hciconfig.
>
> Regards,
> --
> Anderson Lizardo
> OpenBossa Labs - INdT
> Manaus - Brazil
> --
> 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
>
> Hi All,
> I noticed that some LE hardwares don't allow to enable scanning or
> advertising when inquiry scan and/or page scan are enabled.
> Try to disable it using hciconfig or the D-Bus method before to start
> LE operations.
> Regards,
> Claudio.
Hello,
Now I remember, dual mode devices (BR/EDR/LE) are not allowed to work as peripheral (or slave) device. The default advertising mode is "connectable indirect advertising mode". When you try to enable the advertising, you are trying to make this dual mode device as a potential slave to other LE masters and that's why the controller rejects the command.
Scan should work though.
I don't think you can ever connect 2 dual mode devices together, you need a single mode device (LE only) as the slave,
Cheers,
Mike
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
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