[Bluez-devel] Sony PS3 sixaxis & bluez

[Bluez-devel] Sony PS3 sixaxis & bluez

[Frédéric Blain]

[-- Attachment #1: Type: text/plain, Size: 4815 bytes --]

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


[-- Attachment #2: sixaxis-logs.tbz2 --]
[-- Type: application/octet-stream, Size: 7809 bytes --]

[-- Attachment #3: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #4: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Sony PS3 sixaxis & bluez

[Bastien Nocera]

On Sat, 2007-11-24 at 00:37 +0000, Fr=E9d=E9ric Blain wrote:
> Hello,
> =

> With the current bluez-utils version (3.22 or CVS), the PS3 bluetooth =

> controller (Sixaxis) is
> not recognized.

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

<snip>
> =3D=3D=3D=3D Workaround =3D=3D=3D=3D
> =

> 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=3DMain.GentooOnPS3Sixaxi=
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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Sony PS3 sixaxis & bluez

[Frédéric Blain]

[-- Attachment #1.1: Type: text/plain, Size: 1578 bytes --]


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



Bastien Nocera wrote:
> On Sat, 2007-11-24 at 00:37 +0000, Frédéric Blain wrote:
>   
>> Hello,
>>
>> With the current bluez-utils version (3.22 or CVS), the PS3 bluetooth 
>> controller (Sixaxis) is
>> not recognized.
>>     
>
> The input service doesn't support device initiated connections. See:
> http://thread.gmane.org/gmane.linux.bluez.devel/12584/focus=12614
>
> <snip>
>   
>> ==== 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.
>>     
>
> 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
>
>   


[-- Attachment #1.2: Type: text/html, Size: 2445 bytes --]

[-- Attachment #2: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Sony PS3 sixaxis & bluez

[Marcel Holtmann]

Hi Frederic,

> 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 ?

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Sony PS3 sixaxis & bluez

[Marcel Holtmann]

Hi Bastien,

> > With the current bluez-utils version (3.22 or CVS), the PS3 bluetooth 
> > controller (Sixaxis) is
> > not recognized.
> 
> The input service doesn't support device initiated connections. See:
> http://thread.gmane.org/gmane.linux.bluez.devel/12584/focus=12614

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

> 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 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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Sony PS3 sixaxis & bluez

[Bastien Nocera]

On Mon, 2007-11-26 at 07:15 +0100, Marcel Holtmann wrote:
> Hi Bastien,
> 
> > > With the current bluez-utils version (3.22 or CVS), the PS3 bluetooth 
> > > controller (Sixaxis) is
> > > not recognized.
> > 
> > The input service doesn't support device initiated connections. See:
> > http://thread.gmane.org/gmane.linux.bluez.devel/12584/focus=12614
> 
> please remember that hidd file format is different from the input file
> format. I am serious here. It is different.
> 
> > 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 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.

That was always the plan for sixpair2.c

>  This application has to find the local Bluetooth adapter
> and get its BD_ADDR.

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

>  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.

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...).

>  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.

Nod.

>  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.

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Sony PS3 sixaxis & bluez

[Bastien Nocera]

[-- Attachment #1: Type: text/plain, Size: 546 bytes --]


On Mon, 2007-11-26 at 17:38 +0000, Bastien Nocera wrote:
<snip>
> sixpair2.c has a couple of bugs:
> - country is wrong

Doesn't matter.

> - version is wrong

That was my mistake.

> - report is missing 4 bytes

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

[-- Attachment #2: sixpair2.c --]
[-- Type: text/x-csrc, Size: 9094 bytes --]

/* 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;
}


[-- Attachment #3: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #4: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Sony PS3 sixaxis & bluez

[Frédéric Blain]

Bastien Nocera wrote:
> Frederic, could you check it works for you?
>   
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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Sony PS3 sixaxis & bluez

[Marcel Holtmann]

Hi Bastien,

> > sixpair2.c has a couple of bugs:
> > - country is wrong
> 
> Doesn't matter.
> 
> > - version is wrong
> 
> That was my mistake.
> 
> > - report is missing 4 bytes
> 
> Doesn't seem to matter. I think it might be hidd being broken...

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

> 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.

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Sony PS3 sixaxis & bluez

[Bastien Nocera]

On Tue, 2007-11-27 at 09:32 +0100, Marcel Holtmann wrote:
> Hi Bastien,
> 
> > > sixpair2.c has a couple of bugs:
> > > - country is wrong
> > 
> > Doesn't matter.
> > 
> > > - version is wrong
> > 
> > That was my mistake.
> > 
> > > - report is missing 4 bytes
> > 
> > Doesn't seem to matter. I think it might be hidd being broken...
> 
> can you extract the full HID report descriptor from SDP and simply put
> it statically into the code? I think that makes it easier.

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

> > 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.
> 
> 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.

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Sony PS3 sixaxis & bluez

[Marcel Holtmann]

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.
> 
> The report descriptor says length is 148 (in lsusb and my code) and my
> "truncated" version has 296 characters, so it look fine.

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

> > > 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.
> > 
> > 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.
> 
> 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.

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Sony PS3 sixaxis & bluez

[Marcel Holtmann]

Hi Frederic,

> 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.

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.

> 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 ?

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

> 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.

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

> 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.

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel