_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Sumeet,
> Actually when the ADD_SCO_CONNECTION is not supported a command complete is
> generated with the status 0x01 (Unknown HCI Command). The controller doesn't
> know about this command at all. If the controller had known about this
> command then it will generate a command status with suitable status code.
I reviewed that patch and the current attempt to support eSCO is wrong
and eSCO shouldn't be an alternate if SCO fails. In case the LMP_ESCO
features bit is set, then we should always use the new eSCO commands to
setup the audio link. Only in case of Bluetooth 1.1 adapters and earlier
we fall back to the old SCO setup. My understanding is that the new eSCO
setup routine of Bluetooth 1.2 chips or later can handle the remote
Bluetooth 1.1 devices without problems.
Please also use le32 for 32-bit size variables in HCI commands and
events. Don't diff *.mod.c files. These are auto-generated.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Sumeet,
> Yes I think that's a good idea. I think the change required is very minimal.
> In sco.c whether I create a SCO or ESCO link depends on the version which is
> readily available in hci_dev structure. Its just a matter of adding a
> conditional statement (if else). Maybe I can also to check the feature bit
> mask. I will try this.
don't use the version information. Use the features bits and check for
the LMP_ESCO bit.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Denis
Yes I think that's a good idea. I think the change required is very minimal.
In sco.c whether I create a SCO or ESCO link depends on the version which is
readily available in hci_dev structure. Its just a matter of adding a
conditional statement (if else). Maybe I can also to check the feature bit
mask. I will try this.
Regards,
Sumeet
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
[email protected]
Sent: Thursday, April 26, 2007 3:49 PM
To: BlueZ development
Subject: Re: [Bluez-devel] Esco implementation patch
Sumeet,
Yep you are correct. However what I'm trying to say is that if the adapter
is Bluetooth 1.2+ compatible and implements Add Sco Connection for backward
compatibility, then the faster eSCO alternative will never be used. Most of
the Bluetooth 1.2+ USB adapters I've had experience with, do implement the
Add Sco command for backward compatibility.
Shouldn't we try to query the Adapter version first and then use the
commands which are appropriate?
-Denis
> Denis
> Actually when the ADD_SCO_CONNECTION is not supported a command
> complete is generated with the status 0x01 (Unknown HCI Command). The
> controller doesn't know about this command at all. If the controller
> had known about this command then it will generate a command status
> with suitable status code.
>
> Regards,
> Sumeet
-----------------------------------------
Trolltech ASA, Sandakerveien 116, PO Box 4332, Nydalen NO-0402 Oslo, Norway
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express Download DB2 Express C - the
FREE version of DB2 express and take control of your XML. No limits. Just
data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Sumeet,
Yep you are correct. However what I'm trying to say is that if the
adapter is Bluetooth 1.2+ compatible and implements Add Sco Connection for
backward compatibility, then the faster eSCO alternative will never be
used. Most of the Bluetooth 1.2+ USB adapters I've had experience with,
do implement the Add Sco command for backward compatibility.
Shouldn't we try to query the Adapter version first and then use the
commands which are appropriate?
-Denis
> Denis
> Actually when the ADD_SCO_CONNECTION is not supported a command complete
> is
> generated with the status 0x01 (Unknown HCI Command). The controller
> doesn't
> know about this command at all. If the controller had known about this
> command then it will generate a command status with suitable status code.
>
> Regards,
> Sumeet
-----------------------------------------
Trolltech ASA, Sandakerveien 116, PO Box 4332, Nydalen NO-0402 Oslo, Norway
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Denis
Actually when the ADD_SCO_CONNECTION is not supported a command complete is
generated with the status 0x01 (Unknown HCI Command). The controller doesn't
know about this command at all. If the controller had known about this
command then it will generate a command status with suitable status code.
Regards,
Sumeet
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Denis
KENZIOR
Sent: Thursday, April 26, 2007 10:49 AM
To: [email protected]
Subject: Re: [Bluez-devel] Esco implementation patch
I'm concerned about the ADD_SCO addition to the hci_cc_link_ctl function.
The Version 2.0 + EDR page 617 specifies that:
"no Command Complete event will be sent by the Controller to indicate that
this command has been completed...."
To me that means that Add Sco should never trigger the hci_cc_link_ctl
function?
-Denis
On Thursday 26 April 2007 14:56, Sumeet VERMA wrote:
> Hi Marcel
> Sorry for the mistake. Please find a single diff attached.
>
> Regards,
> Sumeet
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Marcel
> Holtmann
> Sent: Wednesday, April 25, 2007 1:14 PM
> To: BlueZ development
> Subject: Re: [Bluez-devel] Esco implementation patch
>
> Hi Sumeet,
>
> > I have done an implementation of esco in bluez kernel. I have
> > hardcoded
>
> the settings of eSCO connection at the moment (packet type EV3).
>
> > Please review it and feel free to make modifications. This is
> > working fine
>
> on my side. I changed the 2.6.20 kernel code.
>
> your patch is reverse and please don't send separate patches for each
file.
> Create a big diff that includes all changes.
>
> Regards
>
> Marcel
>
>
>
> ----------------------------------------------------------------------
> --- This SF.net email is sponsored by DB2 Express Download DB2 Express
> C - the FREE version of DB2 express and take control of your XML. No
> limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express Download DB2 Express C - the
FREE version of DB2 express and take control of your XML. No limits. Just
data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Denis,
> I'm concerned about the ADD_SCO addition to the
> hci_cc_link_ctl function. The
> Version 2.0 + EDR page 617 specifies that:
>
> "no Command Complete event will be sent by the Controller to
> indicate that
> this command has been completed...."
>
> To me that means that Add Sco should never trigger the
> hci_cc_link_ctl
> function?
Yes, but please also read page 611 which states "They may be implemented
by a controller to allow for backwards compatibility
with a host utilizing a prior version of the specification.
A host should not use these commands."
This means that a BT 2.0 controller is not expected to implement the
deprecated commands.
In this case the device treats the ADD_SCO command as an unknown HCI
command and thus generates a command complete event.
The point that you mentioned would be applicable if the device processes
the ADD_SCO command normally.
Having said this, I agree that a problem is bound to arise when the host
is BT 1.1 and it has no idea about the BT 2.0 specifications.
Best Regards,
Mayank
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
iQEVAwUBRjBFkPlzfQCQpKQiAQJmXggAtllspT24CRt62TK6RL810xjq/DCXxKbk
Nn9JSCph2ev+jHdyvdBIWgfUAw0HEWZDJn82/9il4t3+AjiL6eCvCtYcxBAbvHXa
GGOzDknA2B133dRmJsR0bwHhO2e8fSLMYyiTMV2OINF52UHlHZKtqfy2oOGhGc2F
LqO0KxRFZ8Gt4LqoakWW7wyM1n22ny62QzBsP01hE/zTrMInMFSCNv+M6MgqQCW4
EUW5JWKQe72g3FMTS+NBAWhED3v69ckDWBLlHlFIS2OSARbh19bNC2O+f1BF9oZU
3riR6GDlnW2mvB6O002ImlABp2ZlYD2g4fofPgFGHBaNNp6gjG5SSQ==
=kZ/x
-----END PGP SIGNATURE-----
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
I'm concerned about the ADD_SCO addition to the hci_cc_link_ctl function. The
Version 2.0 + EDR page 617 specifies that:
"no Command Complete event will be sent by the Controller to indicate that
this command has been completed...."
To me that means that Add Sco should never trigger the hci_cc_link_ctl
function?
-Denis
On Thursday 26 April 2007 14:56, Sumeet VERMA wrote:
> Hi Marcel
> Sorry for the mistake. Please find a single diff attached.
>
> Regards,
> Sumeet
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Marcel
> Holtmann
> Sent: Wednesday, April 25, 2007 1:14 PM
> To: BlueZ development
> Subject: Re: [Bluez-devel] Esco implementation patch
>
> Hi Sumeet,
>
> > I have done an implementation of esco in bluez kernel. I have hardcoded
>
> the settings of eSCO connection at the moment (packet type EV3).
>
> > Please review it and feel free to make modifications. This is working
> > fine
>
> on my side. I changed the 2.6.20 kernel code.
>
> your patch is reverse and please don't send separate patches for each file.
> Create a big diff that includes all changes.
>
> Regards
>
> Marcel
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express Download DB2 Express C - the
> FREE version of DB2 express and take control of your XML. No limits. Just
> data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Sumeet,
> I have done an implementation of esco in bluez kernel. I have hardcoded the settings of eSCO connection at the moment (packet type EV3).
> Please review it and feel free to make modifications. This is working fine on my side. I changed the 2.6.20 kernel code.
your patch is reverse and please don't send separate patches for each
file. Create a big diff that includes all changes.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Mayank,
> >>> How about the 2-EV* and 3-EV* packet types? The spec says that a 0
> >>> for these bits means they have been enabled. Shouldn't you also
> >>> check for their support in the feature mask?
> >>
> >> Good question. I'm not entirely sure of this, however I did not
> >> interpret the specification in this manner. All it says is that
> >> there is a specific feature mask to disable 2-EV and 3-EV packets.
> >> There is nothing to say whether or not they are explicitly enabled.
> >> Also the examples in the specification use the esco feature masks in
> >> the same manner as I do. So I would assume that if EV3 support is
> >> not enabled, then 2-EV3 and 3-EV3 packets will not be used by the
> >> controller as well. However, I could be wrong.
> >
> > don't worry about packet types. This is the link managers job. Enable
> > as much packet types as possible.
>
> But you'll fall into trouble if the local controller does not support
> the packet type that you've enabled.
> In Denis' case it worked because the device supported the 2-EV* and
> 3-EV* packet types and he "accidentaly" enabled them.
> Why not check their support in the feature mask as well?
this is not needed. Unknown or reserved bits should be ignored. That is
the job of the link manager. And btw. it works fine for ACL EDR packets.
If you have a problem then the link manager firmware authors read the
specification wrong.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Denis,
> > No. It is the difference between using Accept Connection Request or
> > Accept Synchronous Connection Request. In the first case it has to fall
> > back to SCO since it has no further information on how to negotiate an
> > eSCO link.
>
> This is strange, because I would send an accept_sync_conn, get a
> sync_conn_complete_event and the link_type would be 0x0 (SCO) when connecting
> to an unpatched BlueZ box. Again, I imagine more testing is required.
but the unpatched side replies with a Accept Connection Request and this
can only lead to a SCO link since no additional parameters for the eSCO
negotiation are available.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Denis,
> Here's a modified patch that implements eSCO sockets, including incoming SCO
> connections. This was a merge of my previous work for the 2.4 series of
> kernels, so some variables might be named differently than in your patch.
please make sure you use my naming of variables. Otherwise it is too
much confusion. And please create a patch relative to this one so I can
actually review it. And please keep hci_setup_sync(). Doing the
separation this way it more logical than hacking up hci_add_sco(). The
function that decides which command to use should be hci_connect().
> > this patch is incomplete. It doesn't handle incoming eSCO connections
> > and it can't handle SCO audio packets over HCI when a real eSCO
> > connection has been established.
>
> Why do you say this? What is required in order to get eSCO packets flowing?
If you have type == ESCO_LINK then the kernel doesn't send these packets
over the transport layer.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel,
> don't worry about packet types. This is the link managers job. Enable as
> much packet types as possible.
OK, that is what I thought as well.
>
> No. It is the difference between using Accept Connection Request or
> Accept Synchronous Connection Request. In the first case it has to fall
> back to SCO since it has no further information on how to negotiate an
> eSCO link.
This is strange, because I would send an accept_sync_conn, get a
sync_conn_complete_event and the link_type would be 0x0 (SCO) when connecting
to an unpatched BlueZ box. Again, I imagine more testing is required.
Regards,
-Denis
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Marcel,
On Thursday, May 03, 2007 10:47 AM +0530, Marcel Holtmann wrote:
>>> How about the 2-EV* and 3-EV* packet types? The spec says that a 0
>>> for these bits means they have been enabled. Shouldn't you also
>>> check for their support in the feature mask?
>>
>> Good question. I'm not entirely sure of this, however I did not
>> interpret the specification in this manner. All it says is that
>> there is a specific feature mask to disable 2-EV and 3-EV packets.
>> There is nothing to say whether or not they are explicitly enabled.
>> Also the examples in the specification use the esco feature masks in
>> the same manner as I do. So I would assume that if EV3 support is
>> not enabled, then 2-EV3 and 3-EV3 packets will not be used by the
>> controller as well. However, I could be wrong.
>
> don't worry about packet types. This is the link managers job. Enable
> as much packet types as possible.
But you'll fall into trouble if the local controller does not support
the packet type that you've enabled.
In Denis' case it worked because the device supported the 2-EV* and
3-EV* packet types and he "accidentaly" enabled them.
Why not check their support in the feature mask as well?
Regards,
Mayank
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Denis,
> > How about the 2-EV* and 3-EV* packet types? The spec says that a 0 for
> > these bits means they have been enabled. Shouldn't you also check for their
> > support in the feature mask?
>
> Good question. I'm not entirely sure of this, however I did not interpret the
> specification in this manner. All it says is that there is a specific
> feature mask to disable 2-EV and 3-EV packets. There is nothing to say
> whether or not they are explicitly enabled. Also the examples in the
> specification use the esco feature masks in the same manner as I do. So I
> would assume that if EV3 support is not enabled, then 2-EV3 and 3-EV3 packets
> will not be used by the controller as well. However, I could be wrong.
don't worry about packet types. This is the link managers job. Enable as
much packet types as possible.
> > > I've tested it on several machines here, including eSco->eSco
> > > connection, eSco->sco connection for both incoming and outgoing
> > > scenarios, everything seems fine, however I'm sure more testing is
> > > required.
> >
> > How did you mangage to set up an eSCO since you are using only HV* packet
> > types (ESCO_PTYPE_MASK)? Or is it because the 2-EV* and 3-EV* bits are "0"
> > thus the controller thinks you want to enable those packet types?
>
> Well, it comes down to what the controller labels as an eSCO connection. E.g.
> the link_type returned in the connection complete and sync connection
> complete events. Doing BlueZ<->BlueZ which both use the patch, I get
> link_type of eSCO. Doing BlueZ<->BlueZ with one end not using the patch, I
> get a link_type of SCO. Perhaps it is the particular hardware I'm using?
No. It is the difference between using Accept Connection Request or
Accept Synchronous Connection Request. In the first case it has to fall
back to SCO since it has no further information on how to negotiate an
eSCO link.
Regards
Marcel
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Mayank,
> How about the 2-EV* and 3-EV* packet types? The spec says that a 0 for
> these bits means they have been enabled. Shouldn't you also check for their
> support in the feature mask?
Good question. I'm not entirely sure of this, however I did not interpret the
specification in this manner. All it says is that there is a specific
feature mask to disable 2-EV and 3-EV packets. There is nothing to say
whether or not they are explicitly enabled. Also the examples in the
specification use the esco feature masks in the same manner as I do. So I
would assume that if EV3 support is not enabled, then 2-EV3 and 3-EV3 packets
will not be used by the controller as well. However, I could be wrong.
>
> > I've tested it on several machines here, including eSco->eSco
> > connection, eSco->sco connection for both incoming and outgoing
> > scenarios, everything seems fine, however I'm sure more testing is
> > required.
>
> How did you mangage to set up an eSCO since you are using only HV* packet
> types (ESCO_PTYPE_MASK)? Or is it because the 2-EV* and 3-EV* bits are "0"
> thus the controller thinks you want to enable those packet types?
Well, it comes down to what the controller labels as an eSCO connection. E.g.
the link_type returned in the connection complete and sync connection
complete events. Doing BlueZ<->BlueZ which both use the patch, I get
link_type of eSCO. Doing BlueZ<->BlueZ with one end not using the patch, I
get a link_type of SCO. Perhaps it is the particular hardware I'm using?
Setup is a STLC2500 serial device connected to a BT1.2 USB dongle on a
non-patched kernel and a BT 2.0 USB dongle on a patched kernel.
Regards,
-Denis
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Thursday, May 03, 2007 9:27 AM +0530, Denis KENZIOR wrote:
> Here's a modified patch that implements eSCO sockets, including
> incoming SCO connections. This was a merge of my previous work for
> the 2.4 series of kernels, so some variables might be named
> differently than in your patch.
How about the 2-EV* and 3-EV* packet types? The spec says that a 0 for these bits means they have been enabled.
Shouldn't you also check for their support in the feature mask?
> I've tested it on several machines here, including eSco->eSco
> connection, eSco->sco connection for both incoming and outgoing
> scenarios, everything seems fine, however I'm sure more testing is
> required.
How did you mangage to set up an eSCO since you are using only HV* packet types (ESCO_PTYPE_MASK)?
Or is it because the 2-EV* and 3-EV* bits are "0" thus the controller thinks you want to enable those packet types?
>> this patch is incomplete. It doesn't handle incoming eSCO connections
>> and it can't handle SCO audio packets over HCI when a real eSCO
>> connection has been established.
>
> Why do you say this? What is required in order to get eSCO packets
> flowing?
Regards,
Mayank
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel