Sony PS3 sixaxis & bluez

Hello,

With the current bluez-utils version (3.22 or CVS), the PS3 bluetooth controller (Sixaxis) is not recognized. As a workaround, you need to use the former HID daemon (hidd), rename the file /var/lib/bluetooth/xx:xx:xx:xx:xx:xx/hidd to /var/lib/bluetooth/xx:xx:xx:xx:xx:xx/input and restart bluez with bluetoothd-service-input. It will now recognize the controller.

I'm writting to this list to get some help to better understand the new process used by bluetoothd-service-input to recognize and accept devices. I've read the code and the documentation but I still need some information.

Could someone explains me what should be the process to establish a HID connection from a remote device to the host using bluetoothd-service-input ? What are the interactions between hcid and bluetoothd-service-input ? Do you have a doc / diagram explaining this ?

I think bluetoothd-service-input should listen signals from /org/bluez/hci0 and create a device structure when a RemoteDeviceConnected signal is intercepted, but it doesn't seem to work like this.

In bluetoothd-service-input, in which step of this process should the create_device() function be called ? I've noticed interrupt_connect_cb() & control_connect_cb() but I can't figure out when they will be called.

Please be indulgent, this is my first bluetooth & bluez experience ;)

Below you can find a complete description of the problem and my investigations.

==== Problem Description ====

The sixaxis is not recognized by bluetoothd-service-input. According hcidump, a connection is made from the device (sixaxis) to the host controler but when trying to contact HDI on control channel (PSM 17), bluetoothd-service-input generate an error:
"HIDP: Control: Virtual cable unplug".

As a consequence, the device try few more times to establish the connection and then give up. Sixaxis is never recognized and created on the host.

==== Investigations ====

Attaching GDB to the running hcid and bluetoothd-service-input processes, I've isolated the following behavior :

**** bluetoothd-service-input side ****
At startup, it setup the callback mechanism from l2cap control (psm 17) & interrupt (psm 19) sockets to the function connect_event(). Later, when the device ask to open the psm 17 on l2cap, connect_event() is called. Then :

connect_event() ==call=> input_device_set_channel() ==call==> find_device() ==use==> GSList *devices;

In my case, GSList *devices is NULL, so connect_event() do a /* Send unplug virtual cable to unknown devices */.

This point out that:
1- The device structure for the sixaxis has not yet been created while opening the connection on psm 17 . 2- Having a device structure is a requirement to open & use a l2cap channel.

**** hcid side ****
Everything looks good here.
Once the device has completed the connection with hcid, the function conn_complete() is called.

This one will :
+ Send a dbus system signal via hcid_dbus_conn_complete() :
signal sender=:1.3 -> dest=(null destination) path=/org/bluez/hci0;
interface=org.bluez.Adapter; member=RemoteDeviceConnected
+ Read the remote name of the device

**** dbus side ****
Everytime the sixaxis tries to establish a connection with the host, the following messages appear :

signal sender=:1.3 -> dest=(null destination) path=/org/bluez/hci0; interface=org.bluez.Adapter; member=RemoteDeviceConnected
string "00:19:C1:ED:21:31"
signal sender=:1.3 -> dest=(null destination) path=/org/bluez/hci0; interface=org.bluez.Adapter; member=RemoteNameUpdated
string "00:19:C1:ED:21:31"
string "PLAYSTATION(R)3 Controller"
signal sender=:1.3 -> dest=(null destination) path=/org/bluez/hci0; interface=org.bluez.Adapter; member=RemoteDeviceDisconnected
string "00:19:C1:ED:21:31"

==== Other ====

Just to be sure, the pairing has been done using sixpair.c => same issue

# dbus-daemon --version
D-Bus Message Bus Daemon 1.0.2

# uname -a
Linux localhost 2.6.23 #3 SMP Tue Nov 13 23:08:08 CET 2007 ppc64 Cell Broadband Engine, altivec supported GNU/Linux

Please find in attachment :
+ Output of "hcidump -w" while trying to establish a connection
+ Output of "dbus-monitor --system --monitor" while trying to establish a connection
+ Output of syslog while trying to establish a connection

==== Workaround ====

Basically, using the file /var/lib/bluetooth/xx:xx:xx:xx:xx:xx/hidd renamed as input will help since at startup, bluetoothd-service-input will scan this file and fill 'GSList *devices' accordingly.
Also, the file /var/lib/bluetooth/xx:xx:xx:xx:xx:xx/trusts has to be updated .

For those interested, a step by step description can be found here :
http://creber.free.fr/frederic-blain/index.php?n=Main.GentooOnPS3SixaxisBluetooth#Workaround.

Thanks in advance for your help,

creber

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

The input service doesn't support device initiated connections. See:
http://thread.gmane.org/gmane.linux.bluez.devel/12584/focus=3D12614

<snip>

sBluetooth#Workaround.

Haaa. Once I get the capabilities right in my sixaxis patch (I'll be able to compare the hidd generated output with the one from my patch), I think I'll be able to use udev to automatically add the device as supported via Bluetooth once connected via USB.

I'll try and get to it in the week.

Cheers

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hello Bastien,

Thanks for this, I've updated http://wiki.bluez.org/wiki/Input to reflect explicitly this information.

Do you know why device initiated connections are not supported (Lake of time, technical issues, ...) and if someone is working on this integration ?

Regarding your sixaxis patch, I can help to develop / test it if you want.

creber

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Frederic,

in case of the PS3 controller you don't need device initiated connections. The PS3 controller will be never discoverable. The bonding procedure is triggered via the cable authorization. Meaning if you attache the controller via its USB cable you have to do the magic automatically in the background.

Regards

Marcel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Bastien,

please remember that hidd file format is different from the input file format. I am serious here. It is different.

I haven't spend any time on this, but here is how it should work. We need a udev rule that detects the PS3 controller and then runs an application. This application has to find the local Bluetooth adapter and get its BD_ADDR. Then it has to read the adapter address and controller address stored in the controller. This should be done via hidraw (or if possible via hiddev), because otherwise you have to disconnect the controller from the HID driver. If the stored adapter address is not one of the local Bluetooth adapters it should change it and add an entry into the input file. For this entry it needs the HID report descriptor. Best is to read this via USB (since it can change with a new generation of the controller), but it could also be hardcoded since currently it is fixed. The modification of the trusts file is optional, but it could be automated to avoid confusion. Since you attach the cable you basically give authorization.

The case were you have multiple Bluetooth adapters attached to your local system is a bit tricky. We must make sure that we don't keep overwriting the settings if the adapter order changes. Also if assigned to a new adapter, the device should be removed from the other ones.

Regards

Marcel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

That was always the plan for sixpair2.c

Not done yet, but low-prio (you need to pass it on the command-line right now).

That's a problem. hiddev.h has some info on how to get the report descriptors, but more example code is sorely missing. That's not my main concern right now though (I'll dig this up when I get the sixaxis working...).

Nod.

OK.

sixpair2.c has a couple of bugs:
- country is wrong
- version is wrong
- report is missing 4 bytes

I guess the later is the most important one. Once I get this working to some level, I'll have a look at using hiddev instead.

Cheers

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

On Mon, 2007-11-26 at 17:38 +0000, Bastien Nocera wrote:
<snip>

Doesn't matter.

That was my mistake.

Doesn't seem to matter. I think it might be hidd being broken...

Attaching a new version of sixpair2.c that seems to work:
sudo ./sixpair2 --store-info <local bdaddr>

It needs to be compiled from the input/ subdir of bluez-utils, using the command-line at the top of the file.

Frederic, could you check it works for you?

Cheers

/* To compile
* gcc -g -Wall -DSTORAGEDIR=\"/var/lib/bluetooth\" -o sixpair2 sixpair2.c storage.c ../common/libhelper.a -I../common pkg-config --libs --cflags glib-2.0 libusb -lbluetooth */

#include <unistd.h>
#include <stdio.h>
#include <inttypes.h>

#include <bluetooth/bluetooth.h>
#include <bluetooth/hidp.h>
#include <glib.h>
#include <usb.h>

#include "storage.h"

/* Vendor and product ID for the Sixaxis PS3 controller */ #define VENDOR 0x054c
#define PRODUCT 0x0268

#define USB_DIR_IN 0x80
#define USB_DIR_OUT 0

gboolean option_get_master = TRUE;
char *option_master= NULL;
gboolean option_store_info = TRUE;
const char *option_device = NULL;
gboolean option_quiet = FALSE;

const GOptionEntry options[] = {
	{ "get-master", '\0', 0, G_OPTION_ARG_NONE, &option_get_master, "Get currently set master address", NULL },
	{ "set-master", '\0', 0, G_OPTION_ARG_STRING, &option_master, "Set master address (\"auto\" for automatic)", NULL },
	{ "store-info", '\0', 0, G_OPTION_ARG_NONE, &option_store_info, "Store the HID info into the input database", NULL },
	{ "device", '\0', 0, G_OPTION_ARG_STRING, &option_device, "Only handle one device (default, all supported", NULL },
	{ "quiet", 'q', 0, G_OPTION_ARG_NONE, &option_quiet, "Quieten the output", NULL },
	{ NULL }
};

static gboolean
show_master (usb_dev_handle *devh, int itfnum)

{
	unsigned char msg[8];
	int res;

	res = usb_control_msg (devh,
			       USB_DIR_IN | USB_TYPE_CLASS | USB_RECIP_INTERFACE,
			       0x01, 0x03f5, itfnum,
			       (void*) msg, sizeof(msg),
			       5000);

	if (res < 0) {
		g_warning ("Getting the master Bluetooth address failed");
		return FALSE;
	}
	g_print ("Current Bluetooth master: %02x:%02x:%02x:%02x:%02x:%02x\n",
		 msg[2], msg[3], msg[4], msg[5], msg[6], msg[7]);

	return TRUE;
}

static char *
get_bdaddr (usb_dev_handle *devh, int itfnum)

{
	unsigned char msg[17];
	char *address;
	int res;

	res = usb_control_msg (devh,
			       USB_DIR_IN | USB_TYPE_CLASS | USB_RECIP_INTERFACE,
			       0x01, 0x03f2, itfnum,
			       (void*) msg, sizeof(msg),
			       5000);

	if (res < 0) {
		g_warning ("Getting the device Bluetooth address failed");
		return NULL;
	}

	address = g_strdup_printf ("%02x:%02x:%02x:%02x:%02x:%02x",
				   msg[4], msg[5], msg[6], msg[7], msg[8], msg[9]);

	if (option_quiet == FALSE) {
		g_print ("Device Bluetooth address: %s\n", address);
	}

	return address;
}

static gboolean
set_master_bdaddr (usb_dev_handle *devh, int itfnum, char *host)

{
	unsigned char msg[8];
	int mac[6];
	int res;

	if (sscanf(host, "%x:%x:%x:%x:%x:%x",
		   &mac[0],&mac[1],&mac[2],&mac[3],&mac[4],&mac[5]) != 6) {
		return FALSE;
	}

	msg[0] = 0x01;
	msg[1] = 0x00;
	msg[2] = mac[0];
	msg[3] = mac[1];
	msg[4] = mac[2];
	msg[5] = mac[3];
	msg[6] = mac[4];
	msg[7] = mac[5];

	res = usb_control_msg (devh,
			       USB_DIR_OUT | USB_TYPE_CLASS | USB_RECIP_INTERFACE,
			       0x09, 0x03f5, itfnum,
			       (void*) msg, sizeof(msg),
			       5000);

	if (res < 0) {
		g_warning ("Setting the master Bluetooth address failed");
		return FALSE;
	}

	return TRUE;

}

static char *
get_host_bdaddr (void)

{
	FILE *f;
	int mac[6];

	//FIXME use dbus to get the default adapter

	f = popen("hcitool dev", "r");

	if (f == NULL) {
		//FIXME
		return NULL;
	}
	if (fscanf(f, "%*s\n%*s %x:%x:%x:%x:%x:%x",
		   &mac[0],&mac[1],&mac[2],&mac[3],&mac[4],&mac[5]) != 6) {
		//FIXME
		return NULL;
	}

	return g_strdup_printf ("%x:%x:%x:%x:%x:%x", mac[0], mac[1], mac[2], mac[3], mac[4], mac[5]);
}

static int
get_record_info (struct usb_interface_descriptor *alt, unsigned int *_len, unsigned int *_country, uint16_t *_version)

{
	unsigned char *buf;
	unsigned int size, len, country;
	uint16_t version;
	int l;

	len = 0;
	country = 0;
	version = 0;

	if (!alt->extralen)
		return 0;

	size = alt->extralen;
	buf = alt->extra;
	while (size >= 2 * sizeof(u_int8_t)) {
		if (buf[0] < 2 || buf[1] != USB_DT_HID)
			continue;

		//FIXME that should be "21"
		//g_message ("country: %u", buf[4]);
		//country = buf[4];
		//country = 0x21;
		country = 0;
		version = (buf[3] << 8) + buf[2];

		for (l = 0; l < buf[5]; l++) {
			/* we are just interested in report descriptors*/
			if (buf[6+3*l] != USB_DT_REPORT)
				continue;
			len = buf[7+3*l] | (buf[8+3*l] << 8);
		}
		size -= buf[0];
		buf += buf[0];
	}

	if (len == 0)
		return -1;
	*_len = len;
	*_country = country;
	*_version = version;

	return 0;
}

static void
fill_req_from_usb (struct usb_device *dev, struct hidp_connadd_req *req, void *data, unsigned int len, unsigned int country, uint16_t version)

{
	req->vendor = dev->descriptor.idVendor;
	req->product = dev->descriptor.idProduct;
	req->version = version;
	/* req->subclass already set */
	req->country = country;
	/* Default value */
	req->parser = 0x0100;
	/* What are we expecting here? No idea, but we don't seem to need it */
	req->flags = 0;

	req->rd_size = len;
	req->rd_data = data;
}

static void
store_info (const char *host, const char *device, struct hidp_connadd_req *req)

{
	bdaddr_t dest, src;

	if (str2ba (host, &src) < 0) {
		//FIXME
		return;
	}
	if (str2ba (device, &dest) < 0) {
		//FIXME
		return;
	}

	if (store_device_info (&src, &dest, req) < 0)
		g_message ("store_device_info failed");
}

static int
handle_device (struct usb_device *dev, struct usb_config_descriptor *cfg, int itfnum, struct usb_interface_descriptor *alt)

{
	usb_dev_handle *devh;
	int res, retval;

	retval = -1;

	devh = usb_open (dev);
	if (devh == NULL) {
		g_warning ("Can't open device");
		goto bail;
	}
	usb_detach_kernel_driver_np (devh, itfnum);

	res = usb_claim_interface (devh, itfnum);
	if (res < 0) {
		g_warning ("Can't claim interface %d", itfnum);
		goto bail;
	}

	if (option_get_master != FALSE) {
		if (show_master (devh, itfnum) == FALSE)
			goto bail;
		retval = 0;
	}

	if (option_master != NULL) {
		if (strcmp (option_master, "auto") == 0) {
			g_free (option_master);
			option_master = get_host_bdaddr ();
			if (option_master == NULL) {
				g_warning ("Can't get bdaddr from default device");
				retval = -1;
				goto bail;
			}
		}
	} else {
		option_master = get_host_bdaddr ();
		if (option_master == NULL) {
			g_warning ("Can't get bdaddr from default device");
			retval = -1;
			goto bail;
		}
	}

	if (option_store_info != FALSE) {
		unsigned char data[8192];
		struct hidp_connadd_req req;
		unsigned int len, country;
		int n;
		uint16_t version;
		char *device;

		device = get_bdaddr (devh, itfnum);
		if (device == NULL) {
			retval = -1;
			goto bail;
		}

		if (get_record_info (alt, &len, &country, &version) < 0) {
			g_warning ("Can't get record info");
			retval = -1;
			goto bail;
		}

		if ((n = usb_control_msg(devh,
				    USB_ENDPOINT_IN | USB_TYPE_STANDARD | USB_RECIP_INTERFACE,
				    USB_REQ_GET_DESCRIPTOR,
				    (USB_DT_REPORT << 8),
				    itfnum, (void *) &data, len, 5000)) < 0) {
			g_warning ("Can't get report descriptor (length: %d, interface: %d)", len, itfnum);
			retval = -1;
			goto bail;
		}

		req.subclass = alt->bInterfaceSubClass;
		fill_req_from_usb (dev, &req, data, len, country, version);

		store_info (option_master, device, &req);

		if (set_master_bdaddr (devh, itfnum, option_master) == FALSE) {
			retval = -1;
			goto bail;
		}

		//FIXME finally, set device as trusted
	}

bail:

	if (devh != NULL)
		usb_close (devh);

	return retval;
}

int main (int argc, char **argv)

{
	GOptionContext *context;
	GError *error = NULL;
	struct usb_bus *busses, *bus;

	context = g_option_context_new ("- Manage Sixaxis PS3 controllers");
	g_option_context_add_main_entries (context, options, NULL);
	if (g_option_context_parse (context, &argc, &argv, &error) == FALSE) {
		g_warning ("Couldn't parse command-line options: %s", error->message);
		return 1;
	}

	/* Check that the passed bdaddr is correct */
	if (option_master != NULL && strcmp (option_master, "auto") != 0) {
		//FIXME check bdaddr
	}

	/* Find device(s) */
	usb_init ();
	if (usb_find_busses () < 0) {
		g_warning ("usb_find_busses failed");
		return 1;
	}
	if (usb_find_devices () < 0) {
		g_warning ("usb_find_devices failed");
		return 1;
	}

	busses = usb_get_busses();
	if (busses == NULL) {
		g_warning ("usb_get_busses failed");
		return 1;
	}

	for (bus = busses; bus; bus = bus->next) {
		struct usb_device *dev;

		for (dev = bus->devices; dev; dev = dev->next) {
			struct usb_config_descriptor *cfg;

			/* Here we check for the supported devices */
			if (dev->descriptor.idVendor != VENDOR || dev->descriptor.idProduct != PRODUCT)
				continue;

			/* Look for the interface number that interests us */
			for (cfg = dev->config; cfg < dev->config + dev->descriptor.bNumConfigurations; ++cfg) {
				int itfnum;

				for (itfnum = 0; itfnum < cfg->bNumInterfaces; ++itfnum) {
					struct usb_interface *itf = &cfg->interface[itfnum];
					struct usb_interface_descriptor *alt;

					for (alt = itf->altsetting; alt < itf->altsetting + itf->num_altsetting; ++alt) {
						if (alt->bInterfaceClass == 3) {
							handle_device (dev, cfg, itfnum, alt);
						}
					}
				}
			}
		}
	}

	return 0;
}

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Everything's fine with sixpair2.

Just need to adjust the trusts file.
This could be easily done by adding something like :

  bdaddr_t hostaddr;
  str2ba(option_master, &hostaddr);
  write_trust(&hostaddr, device, GLOBAL_TRUST, TRUE);

instead of "//FIXME finally, set device as trusted" in handle_device() (sixpair2.c:316)
However, write_trust() is defined in hcid/hcid.h and implemented in hcid/storage.c.
Since both hcid/storage.c and input/storage.c implement the function read_device_name(),
with a different prototype, it can not compile :

../hcid/hcid.h:193: error: conflicting types for 'read_device_name' storage.h:36: error: previous declaration of 'read_device_name' was here

/tmp/ccE5MOV3.o: In function `read_device_name':
storage.c:(.opd+0x138): multiple definition of `read_device_name'

It could be good to move write_trust() and GLOBAL_TRUST (hcid/hcid.h) in the common directory / lib.

Whatever, thanks a lot for your work,

creber



-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Bastien,

can you extract the full HID report descriptor from SDP and simply put it statically into the code? I think that makes it easier.

I would like to include this one into the CVS. Can you get me a version without GLib stuff? It is not really needed as I can tell. You only use it for option parsing.

Regards

Marcel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

The report descriptor says length is 148 (in lsusb and my code) and my "truncated" version has 296 characters, so it look fine.

You mentioned that already last time I sent the script. I'd really like to be sure it works as expected before I trim it though, so if you or Frederic could test it, I even have a udev rule, and some code to look at to implement using hiddev instead lsusb so the device doesn't disconnect on plugging it in.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Bastien,

please put the descriptor in the code. So we have it there for reference.

Once I get back home, I gonna test it. I am not traveling with my PS3 all the time ;)

However even a half ready "noinst" version might be a good start.

Regards

Marcel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Frederic,

no, no and no. The file formats a different. And you don't have to do anything if you have the hidd file. The input service will import it.

The wiki.bluez.org contains a lot of diagrams and there are slides available from my talks that explains it.

The short answer is no. The long one is that we have two L2CAP PSM that handle the remote connections.

You don't do this. It is a security risk. Period. Think about what you are proposing. Creating a device entry for a remote input device needs user interaction.

Regards

Marcel

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel