linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [Bluez-devel] [Patch] Add dbus method for obtaining RFCOMM channels
@ 2006-07-11 19:39 Matthew Garrett
  2006-07-12 23:32 ` Marcel Holtmann
  0 siblings, 1 reply; 5+ messages in thread
From: Matthew Garrett @ 2006-07-11 19:39 UTC (permalink / raw)
  To: bluez-devel

So, firstly, this is something that scratches an itch I have for hal 
integration. I'm entirely open to doing it in an entirely different way 
if people would prefer that.

This patch adds a GetRFCOMMChannel dbus method, allowing channels to be 
added to hal objects. An example use case would be a phone manager - 
having the channel means that it can simply call a few dbus methods and 
then have a serial device.

===================================================================
RCS file: /cvsroot/bluez/utils/hcid/dbus-sdp.c,v
retrieving revision 1.6
diff -u -r1.6 dbus-sdp.c
--- dbus-sdp.c	27 Jun 2006 07:33:37 -0000	1.6
+++ dbus-sdp.c	11 Jul 2006 19:30:50 -0000
@@ -929,6 +929,38 @@
 	return send_reply_and_unref(conn, reply);
 }
 
+
+static DBusHandlerResult get_rfcomm_channel(DBusConnection *conn,
+					    DBusMessage *msg, void *data)
+{
+	DBusMessage *reply;
+	sdp_record_t *rec;
+	uint32_t identifier;
+	sdp_list_t *protos;
+	int channel;
+
+	if (!dbus_message_get_args(msg, NULL,
+				DBUS_TYPE_UINT32, &identifier,
+				DBUS_TYPE_INVALID))
+		return error_invalid_arguments(conn, msg);
+
+	rec = find_record(identifier);
+	if (!rec)
+		return error_record_does_not_exist(conn, msg);
+
+	reply = dbus_message_new_method_return(msg);
+	
+	if (sdp_get_access_protos(rec, &protos) == 0) {
+		channel = sdp_get_proto_port(protos, RFCOMM_UUID);
+	}
+
+	dbus_message_append_args(reply,
+			DBUS_TYPE_UINT32, &channel,
+			DBUS_TYPE_INVALID);
+
+	return send_reply_and_unref(conn, reply);
+}
+
 static DBusHandlerResult get_name(DBusConnection *conn,
 		DBusMessage *msg, void *data)
 {
@@ -1058,6 +1090,7 @@
 	{ "GetIdentifiersByService",	get_identifiers_by_service	},
 	{ "GetUUID",			get_uuid			},
 	{ "GetName",			get_name			},
+	{ "GetRFCOMMChannel",		get_rfcomm_channel		},
 	{ "RegisterRFCOMM",		register_rfcomm			},
 	{ "UnregisterRFCOMM",		unregister_rfcomm		},
 	{ NULL, NULL }

-- 
Matthew Garrett | mjg59@srcf.ucam.org


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Bluez-devel] [Patch] Add dbus method for obtaining RFCOMM channels
  2006-07-11 19:39 [Bluez-devel] [Patch] Add dbus method for obtaining RFCOMM channels Matthew Garrett
@ 2006-07-12 23:32 ` Marcel Holtmann
  2006-07-13  0:11   ` Matthew Garrett
                     ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Marcel Holtmann @ 2006-07-12 23:32 UTC (permalink / raw)
  To: BlueZ development

Hi Matthew,

> So, firstly, this is something that scratches an itch I have for hal 
> integration. I'm entirely open to doing it in an entirely different way 
> if people would prefer that.
> 
> This patch adds a GetRFCOMMChannel dbus method, allowing channels to be 
> added to hal objects. An example use case would be a phone manager - 
> having the channel means that it can simply call a few dbus methods and 
> then have a serial device.

I would actually prefer not to hand the channel around. We have seen
devices where the channel changes every time they reboot and so it might
not be a good idea. I would prefer using a unique ID to identify the
service.

One of the bigger goals is a working SDP cache for these kind of task
and the knowledge when to refresh the SDP records for a specific
service. At the moment it is not fully clear how this can be achieved
and we might simply have to play with certain ways and see what works
best in the end.

Regards

Marcel




-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Bluez-devel] [Patch] Add dbus method for obtaining RFCOMM channels
  2006-07-12 23:32 ` Marcel Holtmann
@ 2006-07-13  0:11   ` Matthew Garrett
  2006-07-17 17:49   ` Matthew Garrett
  2006-07-17 18:16   ` Matthew Garrett
  2 siblings, 0 replies; 5+ messages in thread
From: Matthew Garrett @ 2006-07-13  0:11 UTC (permalink / raw)
  To: BlueZ development

On Thu, Jul 13, 2006 at 01:32:18AM +0200, Marcel Holtmann wrote:

> I would actually prefer not to hand the channel around. We have seen
> devices where the channel changes every time they reboot and so it might
> not be a good idea. I would prefer using a unique ID to identify the
> service.

Ok. Is it possible for a device to have multiple services with the same 
UUID? If not, is that a reasonable thing to key it off? I noticed the 
list of services in dbus-api.txt, but it currently seems somewhat 
smaller than the number of available profiles.

> One of the bigger goals is a working SDP cache for these kind of task
> and the knowledge when to refresh the SDP records for a specific
> service. At the moment it is not fully clear how this can be achieved
> and we might simply have to play with certain ways and see what works
> best in the end.

Is there a practical way of knowing when the device has rebooted? If 
not, is it possible to simply check the channel on every connection 
attempt? I'm keen on working on this stuff, but my experience of 
bluetooth is mostly at the ui level rather than the protocol level. From 
my point of view, I just want a good way of providing "Get an RFCOMM 
connection to this device" to user applications :)

Thanks,
-- 
Matthew Garrett | mjg59@srcf.ucam.org


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Bluez-devel] [Patch] Add dbus method for obtaining RFCOMM channels
  2006-07-12 23:32 ` Marcel Holtmann
  2006-07-13  0:11   ` Matthew Garrett
@ 2006-07-17 17:49   ` Matthew Garrett
  2006-07-17 18:16   ` Matthew Garrett
  2 siblings, 0 replies; 5+ messages in thread
From: Matthew Garrett @ 2006-07-17 17:49 UTC (permalink / raw)
  To: BlueZ development

On Thu, Jul 13, 2006 at 01:32:18AM +0200, Marcel Holtmann wrote:

> I would actually prefer not to hand the channel around. We have seen
> devices where the channel changes every time they reboot and so it might
> not be a good idea. I would prefer using a unique ID to identify the
> service.

Hm. dbus-api.txt currently documents that Connect should take a string 
describing the service. Would a serviceid not be more appropriate?

-- 
Matthew Garrett | mjg59@srcf.ucam.org


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Bluez-devel] [Patch] Add dbus method for obtaining RFCOMM channels
  2006-07-12 23:32 ` Marcel Holtmann
  2006-07-13  0:11   ` Matthew Garrett
  2006-07-17 17:49   ` Matthew Garrett
@ 2006-07-17 18:16   ` Matthew Garrett
  2 siblings, 0 replies; 5+ messages in thread
From: Matthew Garrett @ 2006-07-17 18:16 UTC (permalink / raw)
  To: BlueZ development

Ok. How about this? It doesn't deal with the caching problem, but with 
luck that's possible without breaking the API and this ought to deal 
with the most common case. I've also changed dbus-api.txt to match what 
the code appears to do. Only compile-tested - I want to check if people 
are happy with the basic approach before writing any code to do anything 
with this :)

Index: dbus-api.txt
===================================================================
RCS file: /cvsroot/bluez/utils/hcid/dbus-api.txt,v
retrieving revision 1.39
diff -u -r1.39 dbus-api.txt
--- dbus-api.txt	26 Jun 2006 12:33:13 -0000	1.39
+++ dbus-api.txt	17 Jul 2006 18:13:26 -0000
@@ -887,11 +887,11 @@
 Interface	org.bluez.RFCOMM
 Object path	/org/bluez/{hci0,hci1,...}
 
-Methods		string Connect(string address, string service)
+Methods		string Connect(string address, int service)
 
 			This creates a connection to a remote RFCOMM based
-			service. The service string can either be a UUID-16,
-			a UUID-32, a UUID-128 or a service abbreviation.
+			service. The service should be a serviceid as 
+			provided by the org.bluez.SDP methods.
 
 			The return value will be the path of the newly
 			created RFCOMM TTY device (for example /dev/rfcomm0).
@@ -899,11 +899,7 @@
 			If the application disconnects from the D-Bus this
 			connection will be terminated.
 
-			Valid service values: "vcp", "map", "pbap", "sap",
-			                      "ftp", "bpp", "bip", "synch",
-			                      "dun", "opp", "fax", "spp"
-
-		void CancelConnect(string address, string service)
+		void CancelConnect(string address, int service)
 
 			This method cancels a previous Connect method call.
 
@@ -963,13 +959,13 @@
 Interface	org.bluez.SDP
 Object path	/org/bluez/{hci0,hci1,...}
 
-Methods		array{string} GetIdentifiers(string address)
+Methods		array{int} GetIdentifiers(string address)
 
-		array{string} GetIdentifiersByService(string address, string service)
+		array{int} GetIdentifiersByService(string address, string service)
 
-		string GetUUID(string identifier)
+		string GetUUID(int identifier)
 
-		string GetName(string identifier)
+		string GetName(int identifier)
 
 		string RegisterRFCOMM(string service, byte channel)
 
Index: dbus-rfcomm.c
===================================================================
RCS file: /cvsroot/bluez/utils/hcid/dbus-rfcomm.c,v
retrieving revision 1.9
diff -u -r1.9 dbus-rfcomm.c
--- dbus-rfcomm.c	2 Jun 2006 10:27:57 -0000	1.9
+++ dbus-rfcomm.c	17 Jul 2006 18:13:27 -0000
@@ -38,6 +38,8 @@
 #include <bluetooth/rfcomm.h>
 #include <bluetooth/hci.h>
 #include <bluetooth/hci_lib.h>
+#include <bluetooth/sdp.h>
+#include <bluetooth/sdp_lib.h>
 
 #include <dbus/dbus.h>
 
@@ -452,18 +454,87 @@
 	return node;
 }
 
-static DBusHandlerResult rfcomm_connect_req(DBusConnection *conn,
-						DBusMessage *msg, void *data)
+static DBusHandlerResult rfcomm_cancel_connect_req(DBusConnection *conn,
+						   DBusMessage *msg, void *data)
 {
-	error("RFCOMM.Connect not implemented");
-	return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
+	const char *dst;
+	int ch = -1;
+	uint32_t service;
+	DBusMessage *reply;
+	struct pending_connect *pending;
+	sdp_record_t *rec;
+	sdp_list_t *protos;
+
+	if (!dbus_message_get_args(msg, NULL,
+				DBUS_TYPE_STRING, &dst,
+				DBUS_TYPE_UINT32, &service,
+				DBUS_TYPE_INVALID))
+		return error_invalid_arguments(conn, msg);
+
+	/* Now we need to find a channel */
+
+	rec = find_record (service);
+	if (!rec)
+		return error_record_does_not_exist (conn, msg);
+
+	if (sdp_get_access_protos(rec, &protos) == 0)
+		ch = sdp_get_proto_port (protos, RFCOMM_UUID);
+
+	if (ch == -1)
+		return error_record_does_not_exist (conn, msg);
+
+	pending = find_pending_connect(dst, ch);
+	if (!pending)
+		return error_connect_not_in_progress(conn, msg);
+
+	reply = dbus_message_new_method_return(msg);
+	if (!reply)
+		return DBUS_HANDLER_RESULT_NEED_MEMORY;
+
+	pending->canceled = 1;
+
+	return send_reply_and_unref(conn, reply);
 }
 
-static DBusHandlerResult rfcomm_cancel_connect_req(DBusConnection *conn,
-						DBusMessage *msg, void *data)
+static DBusHandlerResult rfcomm_connect_req(DBusConnection *conn,
+					    DBusMessage *msg, void *data)
 {
-	error("RFCOMM.CancelConnect not implemented");
-	return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
+	bdaddr_t bdaddr;
+	const char *dst;
+	uint32_t service;
+	int ch = -1;
+	int err;
+	struct hci_dbus_data *dbus_data = data;
+	sdp_record_t *rec;
+	sdp_list_t *protos;
+
+	hci_devba(dbus_data->dev_id, &bdaddr);
+
+	if (!dbus_message_get_args(msg, NULL,
+				DBUS_TYPE_STRING, &dst,
+				DBUS_TYPE_UINT32, &service,
+				DBUS_TYPE_INVALID))
+		return error_invalid_arguments(conn, msg);
+
+	/* Now we need to find a channel */
+
+	rec = find_record (service);
+	if (!rec)
+		return error_record_does_not_exist (conn, msg);
+
+	if (sdp_get_access_protos(rec, &protos) == 0)
+		ch = sdp_get_proto_port (protos, RFCOMM_UUID);
+
+	if (ch == -1)
+		return error_record_does_not_exist (conn, msg);
+
+	if (find_pending_connect(dst, ch))
+		return error_connect_in_progress(conn, msg);
+
+	if (rfcomm_connect(conn, msg, &bdaddr, dst, NULL, ch, &err) < 0)
+		return error_failed(conn, msg, err);
+
+	return DBUS_HANDLER_RESULT_HANDLED;
 }
 
 static DBusHandlerResult rfcomm_connect_by_ch_req(DBusConnection *conn,
Index: dbus.h
===================================================================
RCS file: /cvsroot/bluez/utils/hcid/dbus.h,v
retrieving revision 1.94
diff -u -r1.94 dbus.h
--- dbus.h	10 Jul 2006 19:23:14 -0000	1.94
+++ dbus.h	17 Jul 2006 18:13:27 -0000
@@ -199,4 +199,6 @@
 
 int discoverable_timeout_handler(void *data);
 
+sdp_record_t *find_record(uint32_t identifier);
+
 #endif /* __H_BLUEZ_DBUS_H__ */

-- 
Matthew Garrett | mjg59@srcf.ucam.org


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2006-07-17 18:16 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-07-11 19:39 [Bluez-devel] [Patch] Add dbus method for obtaining RFCOMM channels Matthew Garrett
2006-07-12 23:32 ` Marcel Holtmann
2006-07-13  0:11   ` Matthew Garrett
2006-07-17 17:49   ` Matthew Garrett
2006-07-17 18:16   ` Matthew Garrett

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).