* 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
* Re: set LE advertise not working...
From: Claudio Takahasi @ 2010-09-10 21:03 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: Pavan Savoy, Anderson Briglia, linux-bluetooth
In-Reply-To: <AANLkTi=8nM_nh_4riZaCj77LLzaqRie0dPjGswqpSFz-@mail.gmail.com>
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.
^ permalink raw reply
* Re: set LE advertise not working...
From: Anderson Lizardo @ 2010-09-10 20:35 UTC (permalink / raw)
To: Pavan Savoy; +Cc: Anderson Briglia, linux-bluetooth
In-Reply-To: <AANLkTi=v3ZbVv2PkgCnSKxMRBPmbZCM5JA+bBXfDEd5x@mail.gmail.com>
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
^ permalink raw reply
* Re: Possible regression with skb_clone() in 2.6.36
From: Gustavo F. Padovan @ 2010-09-10 19:45 UTC (permalink / raw)
To: Mat Martineau; +Cc: linux-bluetooth, netdev, linux-kernel, marcel, davem
In-Reply-To: <alpine.DEB.2.00.1009100920270.14322@linux-sea-02>
Hi Mat,
* Mat Martineau <mathewm@codeaurora.org> [2010-09-10 09:53:31 -0700]:
>
> Gustavo -
>
> I'm not sure why the streaming code used to work, but this does not
> look like an skb_clone() problem. Your patch to remove the
> skb_clone() call in l2cap_streaming_send() addresses the root cause of
> this crash.
>
> On Wed, 8 Sep 2010, Gustavo F. Padovan wrote:
>
> > I've been experiencing some problems when running the L2CAP Streaming mode in
> > 2.6.36. The system quickly runs in an Out Of Memory condition and crash. That
> > wasn't happening before, so I think we may have a regression here (I didn't
> > find where yet). The crash log is below.
> >
> > The following patch does not fix the regression, but shows that removing the
> > skb_clone() call from l2cap_streaming_send() we workaround the problem. The
> > patch is good anyway because it saves memory and time.
> >
> > By now I have no idea on how to fix this.
> >
> > <snip>
>
> This has to do with the sk->sk_wmem_alloc accounting that controls the
> amount of write buffer space used on the socket.
>
> When the L2CAP streaming mode socket segments its data, it allocates
> memory using sock_alloc_send_skb() (via bt_skb_send_alloc()). Before
> that allocation call returns, skb_set_owner_w() is called on the new
> skb. This adds to sk->sk_wmem_alloc and sets skb->destructor so that
> sk->sk_wmem_alloc is correctly updated when the skb is freed.
>
> When that skb is cloned, the clone is not "owned" by the write buffer.
> The clone's destructor is set to NULL in __skb_clone(). The version
> of l2cap_streaming_send() that runs out of memory is passing the
> non-owned skb clone down to the HCI layer. The original skb (the one
> that's "owned by w") is immediately freed, which adjusts
> sk->sk_wmem_alloc back down - the socket thinks it has unlimited write
> buffer space. As a result, bt_skb_send_alloc() never blocks waiting
> for buffer space (or returns EAGAIN for nonblocking writes) and the
> HCI send queue keeps growing.
If the problem is what you are saying, add a skb_set_owner_w(skb, sk) on
the cloned skb should solve the problem, but it doesn't. That's exactly
what tcp_transmit_skb() does. Also that just appeared in 2.6.36, is was
working fine before, i.e, we have a regression here.
>
> This isn't a problem for the ERTM sends, because the original skbs are
> kept in the ERTM tx queue until they are acked. Once they're acked,
> the write buffer space is freed and additional skbs can be allocated.
It affects ERTM as well, but in that case the kernel doesn't crash
because ERTM block on sending trying to allocate memory. Then we are not
able to receive any ack (everything stays queued in sk_backlog_queue as
the sk is owned by the user) and ERTM stalls.
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Re: Request for input regarding new driver in MFD for GPS_Bluetooth_FM controller CG2900
From: Pavan Savoy @ 2010-09-10 19:25 UTC (permalink / raw)
To: Alan Cox, linus.walleij, par-gunnar.p.hjalmdahl
Cc: pghatwork, linux-kernel, linux-bluetooth
In-Reply-To: <AANLkTikXFmaZs+XzrOWjWoLPhyUy0CEXfOQMqP=Xp1cO@mail.gmail.com>
ok bit more of information ....
We don;t use the hciattach, instead we have our own daemon which opens
up the UART and installs the line discipline (not N_HCI, but similar
one called N_SHARED) when the hciconfig hci0 up happens or even when
/dev/radio0 (FM V4L2 device) happens or when generic GPS character
device (/dev/tigps) happens...
There is non-mailine driver which gets modified to get into mainline @
http://git.omapzoom.org/?p=kernel/omap.git;a=tree;f=drivers/misc/ti-st;h=028ff4a739d7b59b94d0c613b5ef510ff338b65d;hb=refs/heads/p-android-omap-2.6.32
feel free to have a look at it...
Yes our solution too works with BlueZ and non-exactly a MFD driver but
it is a simple platform device driver .. by looks of things the driver
can run as is for your chip too .. (except for the firmware search and
download part .. may be...).
and note when we would want to support SPI transport for the same, we
plan a SPI-TTY driver ('ala usb-serial) where-in we can install this
N_TI_WL line discipline on that /dev/ttySPI0 device, and the SPI
related stuff to be handled by the spi-tty.c which registers itself as
a tty_device and a tty_driver ....
regards,
Pavan
On Fri, Sep 10, 2010 at 2:07 PM, Pavan Savoy <pavan_savoy@sify.com> wrote:
> Can you directly make use of the ti-st driver which is currently staged?
> It has _EXACTLY_ the same thing.... which is REALLY REALLY surprising !!!
>
> On Fri, Sep 10, 2010 at 8:38 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>>> - Is it OK to dynamically use the channels either from Kernel or User space?
>>
>> Quite a few devices do this. In most cases it makes no sense to burden
>> the user with channel management so its only natural that opening the tty
>> or direct interfaces should "just work"
>> --
>> 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: Request for input regarding new driver in MFD for GPS_Bluetooth_FM controller CG2900
From: Pavan Savoy @ 2010-09-10 19:07 UTC (permalink / raw)
To: Alan Cox
Cc: pghatwork, par-gunnar.p.hjalmdahl, linux-kernel, linux-bluetooth,
linus.walleij
In-Reply-To: <20100910143813.4af0a3ce@lxorguk.ukuu.org.uk>
Can you directly make use of the ti-st driver which is currently staged?
It has _EXACTLY_ the same thing.... which is REALLY REALLY surprising !!!
On Fri, Sep 10, 2010 at 8:38 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> - Is it OK to dynamically use the channels either from Kernel or User space?
>
> Quite a few devices do this. In most cases it makes no sense to burden
> the user with channel management so its only natural that opening the tty
> or direct interfaces should "just work"
> --
> 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: Pavan Savoy @ 2010-09-10 19:01 UTC (permalink / raw)
To: Anderson Briglia; +Cc: linux-bluetooth
In-Reply-To: <4C8A758B.1060708@openbossa.org>
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?
On Fri, Sep 10, 2010 at 1:14 PM, Anderson Briglia
<anderson.briglia@openbossa.org> wrote:
> On 09/10/2010 12:53 PM, Pavan Savoy wrote:
>>
>> Nope, I haven't applied the kernel patches...
>> But my kernel diff to the latest kernel is only regarding the "block"
>> and "unblock" to black list devices....
>>
>> do I need some patches in kernel for enabling/disabling BLE too ?
>> I thought it just sends out the commands to controller...
>>
>
> You are right. You don't need to have the kernel patches.
> I did some tests here and everything goes ok.
> Check the hcidump output below:
>
> 2010-09-10 14:13:19.032099 < HCI Command: Unknown (0x08|0x000a) plen 1
> 0000: 01 .
> 2010-09-10 14:13:19.070320 > HCI Event: Command Complete (0x0e) plen 4
> Unknown (0x08|0x000a) ncmd 2
> 0000: 00
>
> I just did a hciconfig hci0 leadv
>
> Regards,
>
> Anderson Briglia
>>
>> On Fri, Sep 10, 2010 at 8:40 AM, Anderson Briglia
>> <anderson.briglia@openbossa.org> wrote:
>>
>>>
>>> Hi Pavan,
>>>
>>> Try to make a hciconfig reset before setting leadv.
>>> Are you using that kernel patches I send before, right?
>>>
>>> Regards,
>>>
>>> Anderson Briglia
>>>
>>> On 09/09/2010 03:58 PM, Pavan Savoy wrote:
>>>
>>>>
>>>> I have an LE enabled BT controller, and I happened to send across a
>>>> simple "leadv" from the recently updated hciconfig
>>>> I got back the following data
>>>> "4 e 5 1 a 20 c 3a" and hence
>>>> "Can't set advertise mode on hci0: Success (0)"
>>>> and 0xC I guess by the BT spec means the command is disallowed (for
>>>> reasons unknown?....)
>>>>
>>>> So I'm just wondering, am I supposed to run some HCI-VS commands to
>>>> enable LE? I mean I should ask my vendor I agree, but anyone who has
>>>> got it working.. do they run some VS commands before enabling LE
>>>> advertising?
>>>> --
>>>> 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: MAP implementation status
From: Luiz Augusto von Dentz @ 2010-09-10 18:26 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: Radoslaw Jablonski, linux-bluetooth@vger.kernel.org
In-Reply-To: <20100910181259.GA19693@vigoh>
Hi,
On Fri, Sep 10, 2010 at 9:12 PM, Gustavo F. Padovan
<padovan@profusion.mobi> wrote:
> Hi Radoslaw,
>
> * Radoslaw Jablonski <ext-jablonski.radoslaw@nokia.com> [2010-09-09 15:46:33 +0300]:
>
>>
>> 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.
>
> We had a Google Summer of Code Project on MAP this year. Vinicius was
> the mentor, he can talk about.
iirc it was mainly a MAP client, the other parts that are missing is:
- MAP plugin + drivers
- Backend infrastructure
- Backends
--
Luiz Augusto von Dentz
Computer Engineer
^ 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