Hi.
I have some questions about BlueZ.
Our company is investigating now about BlueZ,
to determine whether it is useful to use in our commercial product, or not.
I searched the archive of BlueZ mailing list about Q&A of BlueZ in commercial use.
I found some threads which are related to such a topic, but I want to know more detail.
Please reply on the following questions.
Q1. development schedule in the future
I saw "http://www.bluez.org/todo.html"
But there is no information I want to know.
Please tell me the following things.
- eSCO (enhanced SCO) in Bluetooth 1.2
Do you have any plan to develop these?
- Audio/Video related profiles
Do you have any plan to develop these(A2DP, AVRCP)?
Q2. maintenance/support
I found some examples about the support of open-source that
companies which want to use such a open-source software,
pay some maintenance fee to the community or some companies which
provide the service to maintain it, so that
the community or such companies ensure the quality of their software is a certain level.
For example, MySQL, JBoss, etc.
These open-sources are maintained to ensure the quality,
by some kind of organizations which get the maintenance fee.
Does BlueZ allow such a business model?
Q3. version control
Many open-sources are composed of two versions,
one is a "testing version", and another is a "stable version".
But I think BlueZ has only a "testing version".
Why doesn't BlueZ have a "stable version"?
Do you have any plan to have a "stable version" of BlueZ?
I will appreciate any reply.
Thanks.
Keihachi
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit http://www.blackhat.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi KeiHachi,
> > The problem is that they use multiple L2CAP connections with the same
> > PSM for different protocols. This is totally stupid, because you can
> > only differ between them on the order of their creation. However the
> > basic mode looks very simple. Right now it looks like that I will
> > support AVDTP as a sequential packet socket.
>
> Probably it can be realized as a socket.
> But some functionalities, like a SEP concept, should be considered in deeply.
I already did that and in the fact of SEP it is nothing different from a
PSM or RFCOMM channel. Actually because of this I thought that a socket
based implementation is the best. Along time I prefered to keep AVDTP in
userspace. However the only difficult part is the discover, because if
you don't know the SEP you must use it to find the available ones and
this includes a L2CAP connection. I must see how this gets integrated in
a nice way.
> > No problem for me, because I don't like talking about theoretical stuff.
> > I prefer to talk about facts. If you know what you want, we can talk
> > about what is possible and what not. And I can help you with not driving
> > into a dead end.
>
> Thank you, availing of your kind offer, I have one more question.
>
> I know the product that uses BlueZ in it, as I found it on the BlueZ site before.
> http://www.bluez.org/qualification.html
>
> In that case, how did you or other guys help them to qualify?
> For example, did that company paid some fee, or donation?
> Were you or other guys under obligation to help them based on a contract?
>
> Of course if you have the obligation to keep its secrets, it is OK to say nothing.
There is no secret about it. Parts of the communication can be found in
the mailing list archive. The rest was not in public, but actually only
by accident.
What we had done was to fix the L2CAP and RFCOMM protocol layers and
extend the test programs to pass the qualification tests.
There was no contract and they didn't paid us.
Regards
Marcel
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit http://www.blackhat.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Ademar,
> > start asking Max about it. Since he is still working for Qualcomm we may
> > resolve this issue very soon. If Qualcomm and Max agree on LGPL for the
> > library I will also agree on it.
>
> Added him to CC: just in case he is not following the thread.
this depends on the size of his mailbox and how busy he is. To be on the
safe side, connect him directly and set me on CC. No need to forward
this to the mailing list.
Regards
Marcel
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit http://www.blackhat.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann wrote:
> Hi Ademar,
>
>
>>>For the BlueZ library and the utilities we can talk about it. Some time
>>>ago people asked for a LGPL version of the library and actually I tend
>>>to agree with that. However this can't be decided by me alone, because
>>>part of the code is copyright by Qualcomm and also by Maxim Krasnyansky
>>>himself.
>>
>>That would be something really interesting to hear about and I guess it's
>>important to define as soon as possible (to avoid including more people with
>>copyright code in the ring, for example).
>
>
> start asking Max about it. Since he is still working for Qualcomm we may
> resolve this issue very soon. If Qualcomm and Max agree on LGPL for the
> library I will also agree on it.
Added him to CC: just in case he is not following the thread.
Max, could you give us your view about that?
Thanks and best regards,
- Ademar
--
Ademar de Souza Reis Jr. <[email protected]>
Conectiva S.A. - http://www.conectiva.com.br
^[:wq!
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit http://www.blackhat.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi all,
I have no objection to relicensing the SDP library under the LGPL.
Cheers,
Steve
On Mon, 2004-06-28 at 16:38, Marcel Holtmann wrote:
> Hi Ademar,
>
> > > For the BlueZ library and the utilities we can talk about it. Some time
> > > ago people asked for a LGPL version of the library and actually I tend
> > > to agree with that. However this can't be decided by me alone, because
> > > part of the code is copyright by Qualcomm and also by Maxim Krasnyansky
> > > himself.
> >
> > That would be something really interesting to hear about and I guess it's
> > important to define as soon as possible (to avoid including more people with
> > copyright code in the ring, for example).
>
> start asking Max about it. Since he is still working for Qualcomm we may
> resolve this issue very soon. If Qualcomm and Max agree on LGPL for the
> library I will also agree on it.
>
> But I forgot to mention the SDP part of the library. In the beginning it
> was based on the Affix code. I don't know how much of Affix is still in
> there. However you also have to ask Stephen Crane for permission.
>
> If everybody agree I will release a LGPL version of the library as soon
> as possible.
>
> > There are already companies interested in creating products with BT support
> > under Linux and bluez could be the definitive answer.
>
> Can you name them?
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit http://www.blackhat.com
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
--
Stephen Crane, Rococo Software Ltd. http://www.rococosoft.com
[email protected] +353-1-6601315 (ext 209)
Hi Ademar,
> > For the BlueZ library and the utilities we can talk about it. Some time
> > ago people asked for a LGPL version of the library and actually I tend
> > to agree with that. However this can't be decided by me alone, because
> > part of the code is copyright by Qualcomm and also by Maxim Krasnyansky
> > himself.
>
> That would be something really interesting to hear about and I guess it's
> important to define as soon as possible (to avoid including more people with
> copyright code in the ring, for example).
start asking Max about it. Since he is still working for Qualcomm we may
resolve this issue very soon. If Qualcomm and Max agree on LGPL for the
library I will also agree on it.
But I forgot to mention the SDP part of the library. In the beginning it
was based on the Affix code. I don't know how much of Affix is still in
there. However you also have to ask Stephen Crane for permission.
If everybody agree I will release a LGPL version of the library as soon
as possible.
> There are already companies interested in creating products with BT support
> under Linux and bluez could be the definitive answer.
Can you name them?
Regards
Marcel
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit http://www.blackhat.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann wrote:
> Hi Ademar,
>
>
>>While we're at this topic: Is there a way to get a license to use the bluez
>>code in a comercial, closed-source, product? (I was thinking about something
>>like what QT/Trolltech does).
>
>
> the kernel part of BlueZ is GPL and will stay as GPL forever. Another
> license makes no sense here.
Yes, sure.
>
> For the BlueZ library and the utilities we can talk about it. Some time
> ago people asked for a LGPL version of the library and actually I tend
> to agree with that. However this can't be decided by me alone, because
> part of the code is copyright by Qualcomm and also by Maxim Krasnyansky
> himself.
That would be something really interesting to hear about and I guess it's
important to define as soon as possible (to avoid including more people with
copyright code in the ring, for example).
There are already companies interested in creating products with BT support
under Linux and bluez could be the definitive answer.
> For the utilities I don't see any need for a different license.
>
> I believe in the GPL and from my view releasing the Linux Bluetooth
> library under LGPL is the only step I wanna make forward to allow closed
> source products based on BlueZ.
Totally agreed. The only scenario I don't want is the one where the code is
GPL only and there's no way to license its use in comercial/closed products,
because that would force companies to use non-standard bluetooth stacks
under Linux or to avoid using Linux at all...
Thanks.
--
Ademar de Souza Reis Jr. <[email protected]>
Conectiva S.A. - http://www.conectiva.com.br
^[:wq!
Hi Ademar,
> While we're at this topic: Is there a way to get a license to use the bluez
> code in a comercial, closed-source, product? (I was thinking about something
> like what QT/Trolltech does).
the kernel part of BlueZ is GPL and will stay as GPL forever. Another
license makes no sense here.
For the BlueZ library and the utilities we can talk about it. Some time
ago people asked for a LGPL version of the library and actually I tend
to agree with that. However this can't be decided by me alone, because
part of the code is copyright by Qualcomm and also by Maxim Krasnyansky
himself. For the utilities I don't see any need for a different license.
I believe in the GPL and from my view releasing the Linux Bluetooth
library under LGPL is the only step I wanna make forward to allow closed
source products based on BlueZ.
Regards
Marcel
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit http://www.blackhat.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Nicholas A. Preyss wrote:
> On 0, KeiHachi <[email protected]> wrote:
>
>>I have some questions about BlueZ.
>>
>>Our company is investigating now about BlueZ,
>>to determine whether it is useful to use in our commercial product, or not.
>
>
> If this is the first GPL software you are using, please read and
> understand the implications of this license. This is no offense, but i
> think some DVD and Router manufacturer didn't do this before integrating
> linux code in their products.
>
Hello.
While we're at this topic: Is there a way to get a license to use the bluez
code in a comercial, closed-source, product? (I was thinking about something
like what QT/Trolltech does).
I'm sorry if this has been asked before, but I haven't found it in the
archives and it's not in the FAQ.
Thanks.
--
Ademar de Souza Reis Jr. <[email protected]>
Conectiva S.A. - http://www.conectiva.com.br
^[:wq!
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit http://www.blackhat.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Nicholas,
> > the current USB subsystem (as of 2.6.7) is not as bad as you think.
> > Actually it is working very nice and even the hci_usb driver didn't
> > crash anymore. Anyhow the problem is not USB. We made all of them by
> > ourself :(
>
> I think the problem is USB. It is too complicated for the least cost
> market. So many manufacturers built chips or firmware for USB devices
> which are not spec compliant. Additionaly there are so many bad
> programmed driver.
I had a small chat with Oliver Neukum about some design issues of the
USB subsystem. And yes, some parts are too complex and some companies
are unable to read specifications and understand them the right way. The
problem is that you can't prevent this.
Even in the case of Bluetooth where the qualifications tests are very
complex and try to test every aspect of a bad implementation. Some
devices are broken, but they are still qualified and must work.
On the other side parts of the specifications are bad. I may remind you
of our discussion on who has to terminate the ACL link if no other
protocol or application is using it.
> I think this is a design failure, even if it only appears as bad driver
> implementations.
The Bluetooth USB (H:2) devices are a little bit complex. A design must
grow along the needs of the real USB devices. The USB guys are now aware
of it and you can expect changes within the 2.7 kernel lifetime.
> > I really like the Debian way of forking a stable version and only doing
> > security or bugfixes. The problem is that this needs a lot of man power
> > and costs a lot of time. I know what I am talking about, because I did
> > all the 2.4 kernel backports of the Bluetooth subsystem.
>
> A company would need to do this for the version they use in production
> systems only. So it should be possible.
Yes thats right, but from my point a specific company fork won't drive
the community forwards. This actually depends of course on how the
company talks back to us.
> > If we got a number of companies that help sponsoring the BlueZ itself
> > and its official qualification I can think of such a fork. At that point
> > it makes sense to me and is worth the extra work.
>
> I didn't thought of you maintaining such a stable fork. But like in the
> debian project, the developers who need this high quality standard, care
> for the branch themselves. Then you need to assure only, that all fixes you
> apply are documented and published, even if you fix them with a new feature
> that doesn't go into the stable tree.
We use Bitkeeper for the kernel trees and CVS for the BlueZ library and
utils. I think everything like this is quite well documented.
However this is not the first time I talked about a fork. One year ago
or so when WideRay starts to qualify there BlueZ based product we also
talked about the qualifcation needs. It will be necessary to fork a
qualified version of BlueZ and you need someone who maintains it. This
must not me, but this is a fork that I will support. For other forks you
better should convince me that its worth ;)
Regards
Marcel
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit http://www.blackhat.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On 0, Marcel Holtmann <[email protected]> wrote:
> the current USB subsystem (as of 2.6.7) is not as bad as you think.
> Actually it is working very nice and even the hci_usb driver didn't
> crash anymore. Anyhow the problem is not USB. We made all of them by
> ourself :(
I think the problem is USB. It is too complicated for the least cost
market. So many manufacturers built chips or firmware for USB devices
which are not spec compliant. Additionaly there are so many bad
programmed driver.
I think this is a design failure, even if it only appears as bad driver
implementations.
> > The debian project shows that if you really want such high quality
> > standards for use in embedded devices e.g. it is possible to keep your
> > own stable branch. I think it is very easy with a good Changelog.
>
> I really like the Debian way of forking a stable version and only doing
> security or bugfixes. The problem is that this needs a lot of man power
> and costs a lot of time. I know what I am talking about, because I did
> all the 2.4 kernel backports of the Bluetooth subsystem.
A company would need to do this for the version they use in production
systems only. So it should be possible.
> If we got a number of companies that help sponsoring the BlueZ itself
> and its official qualification I can think of such a fork. At that point
> it makes sense to me and is worth the extra work.
I didn't thought of you maintaining such a stable fork. But like in the
debian project, the developers who need this high quality standard, care
for the branch themselves. Then you need to assure only, that all fixes you
apply are documented and published, even if you fix them with a new feature
that doesn't go into the stable tree.
nicholas
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit http://www.blackhat.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Nicholas,
> > the Linux kernel 2.6 itself first will become mature if Andrew takes
> > over the maintainer role and the 2.7 branch is created. However the
> > kernel itself is stable and the BlueZ core is also stable. The USB
> > problem you are talking about is a driver problem (hci_usb) only and
> > don't effect the BlueZ core.
>
> I wasn't referring to the bluez code, but about the whole 2.6 kernel.
> And nowadays USB is going to be the standard for connecting even
> internal devices, so the OP should be clear that using the 2.6 kernel is
> no smart idea. Because these really heavy problems of the whole USB
> subsystem affect the use of bluetooth usb dongles i mentioned it. I
> think it isn't a good idea too use USB at all.
the current USB subsystem (as of 2.6.7) is not as bad as you think.
Actually it is working very nice and even the hci_usb driver didn't
crash anymore. Anyhow the problem is not USB. We made all of them by
ourself :(
> > This is a another nice point why I don't really wanna start thinking in
> > black/white or stable/testing categories. Choose what you need and then
> > you can start talking about how stable this will be for a specific use
> > case.
>
> I agree with you, the seperation of stable/testing trees is not the
> perfect solution.
> But you have to admit, that yours is a more error-prone approach then
> forking a stable branch and backporting bugfixes. Technically seen, it
> is the same as fixing the core and do larger modifications and feature
> adds to modules only. But i think this makes quality assurance more
> complicated.
> The debian project shows that if you really want such high quality
> standards for use in embedded devices e.g. it is possible to keep your
> own stable branch. I think it is very easy with a good Changelog.
I really like the Debian way of forking a stable version and only doing
security or bugfixes. The problem is that this needs a lot of man power
and costs a lot of time. I know what I am talking about, because I did
all the 2.4 kernel backports of the Bluetooth subsystem.
If we got a number of companies that help sponsoring the BlueZ itself
and its official qualification I can think of such a fork. At that point
it makes sense to me and is worth the extra work.
Regards
Marcel
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit http://www.blackhat.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On 0, Marcel Holtmann <[email protected]> wrote:
> > I wouldn't consider 2.6. as stable. And i think it is not recommend to
> > use anything related to USB with 2.6. in a commercial standalone device.
>
> the Linux kernel 2.6 itself first will become mature if Andrew takes
> over the maintainer role and the 2.7 branch is created. However the
> kernel itself is stable and the BlueZ core is also stable. The USB
> problem you are talking about is a driver problem (hci_usb) only and
> don't effect the BlueZ core.
I wasn't referring to the bluez code, but about the whole 2.6 kernel.
And nowadays USB is going to be the standard for connecting even
internal devices, so the OP should be clear that using the 2.6 kernel is
no smart idea. Because these really heavy problems of the whole USB
subsystem affect the use of bluetooth usb dongles i mentioned it. I
think it isn't a good idea too use USB at all.
> This is a another nice point why I don't really wanna start thinking in
> black/white or stable/testing categories. Choose what you need and then
> you can start talking about how stable this will be for a specific use
> case.
I agree with you, the seperation of stable/testing trees is not the
perfect solution.
But you have to admit, that yours is a more error-prone approach then
forking a stable branch and backporting bugfixes. Technically seen, it
is the same as fixing the core and do larger modifications and feature
adds to modules only. But i think this makes quality assurance more
complicated.
The debian project shows that if you really want such high quality
standards for use in embedded devices e.g. it is possible to keep your
own stable branch. I think it is very easy with a good Changelog.
nicholas
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit http://www.blackhat.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Nicholas,
> > That is wrong. BlueZ itself is stable. Speaking about the kernel part
> > then every code in a stable kernel like 2.4 and 2.6 is stable. Bugs
> > exists and later kernel releases are more stable than previous, but
> > every BlueZ code in the kernel can be considered as stable.
>
> I wouldn't consider 2.6. as stable. And i think it is not recommend to
> use anything related to USB with 2.6. in a commercial standalone device.
the Linux kernel 2.6 itself first will become mature if Andrew takes
over the maintainer role and the 2.7 branch is created. However the
kernel itself is stable and the BlueZ core is also stable. The USB
problem you are talking about is a driver problem (hci_usb) only and
don't effect the BlueZ core.
This is a another nice point why I don't really wanna start thinking in
black/white or stable/testing categories. Choose what you need and then
you can start talking about how stable this will be for a specific use
case.
Regards
Marcel
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit http://www.blackhat.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On 0, Marcel Holtmann <[email protected]> wrote:
> > Why doesn't BlueZ have a "stable version"?
> > Do you have any plan to have a "stable version" of BlueZ?
>
> That is wrong. BlueZ itself is stable. Speaking about the kernel part
> then every code in a stable kernel like 2.4 and 2.6 is stable. Bugs
> exists and later kernel releases are more stable than previous, but
> every BlueZ code in the kernel can be considered as stable.
I wouldn't consider 2.6. as stable. And i think it is not recommend to
use anything related to USB with 2.6. in a commercial standalone device.
nicholas
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit http://www.blackhat.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Keihachi,
> Our company is investigating now about BlueZ,
> to determine whether it is useful to use in our commercial product, or not.
about what kind of product are you talking?
> Q1. development schedule in the future
> I saw "http://www.bluez.org/todo.html"
> But there is no information I want to know.
> Please tell me the following things.
This list only shows kernel related items that other people can start
working on if they want to contribute anything to BlueZ. My personal
todo list is much longer.
> - eSCO (enhanced SCO) in Bluetooth 1.2
> Do you have any plan to develop these?
Define what kind of eSCO support do you need? Must the SCO packets go
though the HCI layer or through an extra PCM interface?
Do you own Bluetooth chips that supports eSCO? I only own two devboards
and both don't support SCO over HCI and they also don't came with a PCM
codec on it.
> - Audio/Video related profiles
> Do you have any plan to develop these(A2DP, AVRCP)?
Audio/video is along with HID one of the two major things that will be
supported in the future. However talking about A2DP the problem I see is
that there is not free GPL code for the suband codec at the moment and I
am not an audio expert. I haven't spent any time with thinking about the
remote control profiles.
> Q2. maintenance/support
> I found some examples about the support of open-source that
> companies which want to use such a open-source software,
> pay some maintenance fee to the community or some companies which
> provide the service to maintain it, so that
> the community or such companies ensure the quality of their software is a certain level.
> For example, MySQL, JBoss, etc.
> These open-sources are maintained to ensure the quality,
> by some kind of organizations which get the maintenance fee.
>
> Does BlueZ allow such a business model?
Many business models are possible, but you must be more specific about
that what you had in mind. What kind of maintenance and support do you
need?
> Q3. version control
> Many open-sources are composed of two versions,
> one is a "testing version", and another is a "stable version".
> But I think BlueZ has only a "testing version".
>
> Why doesn't BlueZ have a "stable version"?
> Do you have any plan to have a "stable version" of BlueZ?
That is wrong. BlueZ itself is stable. Speaking about the kernel part
then every code in a stable kernel like 2.4 and 2.6 is stable. Bugs
exists and later kernel releases are more stable than previous, but
every BlueZ code in the kernel can be considered as stable.
The -mh patches for 2.4 are also stable, because they don't add new
features. They only make it possible to use the latest BlueZ code 2.4
with older kernel releases. I did this, because embedded developers are
very stuck to some kernel versions.
Starting with 2.6 I changed the use case of my -mh patches. They are
only maintained for the latest kernel version and they include testing
code. For example the upcoming HIDP support.
The BlueZ library and utils are also stable. The next generation work
(or may you wanna call it "testing") can be found in CVS under libs2 and
utils2.
Regards
Marcel
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit http://www.blackhat.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On 0, KeiHachi <[email protected]> wrote:
> I have some questions about BlueZ.
>
> Our company is investigating now about BlueZ,
> to determine whether it is useful to use in our commercial product, or not.
If this is the first GPL software you are using, please read and
understand the implications of this license. This is no offense, but i
think some DVD and Router manufacturer didn't do this before integrating
linux code in their products.
> Q1. development schedule in the future
> I saw "http://www.bluez.org/todo.html"
> But there is no information I want to know.
> Please tell me the following things.
>
> - eSCO (enhanced SCO) in Bluetooth 1.2
> Do you have any plan to develop these?
I am not Marcel and not writing any kernel code, but i listened his talk
at Linuxtag Karlsruhe. I think the problem is the lack of the end-user
products already supporting this. But it is on his plan:
http://www.holtmann.org/papers/bluetooth/lt2004_slides.pdf
> - Audio/Video related profiles
> Do you have any plan to develop these(A2DP, AVRCP)?
He posted some time ago a request, that if people supply him such
hardware he would implent those support.
> Q2. maintenance/support
> I found some examples about the support of open-source that
> companies which want to use such a open-source software,
> pay some maintenance fee to the community or some companies which
> provide the service to maintain it, so that
> the community or such companies ensure the quality of their software is a certain level.
> For example, MySQL, JBoss, etc.
> These open-sources are maintained to ensure the quality,
> by some kind of organizations which get the maintenance fee.
>
> Does BlueZ allow such a business model?
I don't understand, are you looking for a company that provides such
support or you want to start a business providing such support?
I don't know of the first, but contacting the developer directly, one
may provide such support. The second is of course possible.
> Q3. version control
> Many open-sources are composed of two versions,
> one is a "testing version", and another is a "stable version".
> But I think BlueZ has only a "testing version".
>
> Why doesn't BlueZ have a "stable version"?
> Do you have any plan to have a "stable version" of BlueZ?
It is so stable, you don't need one, ;) Just kidding. Why do you think,
there is no stable version? I think the releases are considered stable
and the CVS stuff and the utils2/libs2 are the testing branch.
nicholas
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit http://www.blackhat.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi Peter,
> > I will attend there and my plan is to present something very
> > nice, but right now I am not sure what it will be. Any proposals?
>
> How about a Logitech bt headset working under linux as an alsa soundcard?
> (Just kidding :-)
I won't go with the current way of the snd-bt-sco patch. Take a look at
my LinuxTag 2004 slides and you will see what kind of way I have in mind
for solving the audio issue.
Regards
Marcel
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit http://www.blackhat.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann wrote:
<snip>
> I will attend there and my plan is to present something very
> nice, but right now I am not sure what it will be. Any proposals?
How about a Logitech bt headset working under linux as an alsa soundcard?
(Just kidding :-)
Anyway, if anyone is interested, I've made a patch of the snd-bt-sco stuff
against the 2.6.6 kernel. It is available here:
http://how.dk/~pfavr/snd_bt_sco-kernel-2.6.6.patch
I'm currently trying with 2.6.7, although the above patch misses a hunk in
/drivers/bluetooth/hci_usb.c - I'll just try to see if it works even without
that hunk applied.
As usual, any guidance or suggestions on this matter is very welcome!
Best regards,
Peter
Hi KeiHachi,
> > I already did that and in the fact of SEP it is nothing different from a
> > PSM or RFCOMM channel. Actually because of this I thought that a socket
> > based implementation is the best. Along time I prefered to keep AVDTP in
> > userspace. However the only difficult part is the discover, because if
> > you don't know the SEP you must use it to find the available ones and
> > this includes a L2CAP connection. I must see how this gets integrated in
> > a nice way.
>
> I see.
> You, Marcel, are the one of the best engineer in the world,
> so I anticipate the time when AVDTP will be completed.
many thanks for these nice words.
When I first looked deeper at the details of AVDTP, my plan was to get a
working demo of the VDP at the Linux konferenca 2004 in Portoroz. Anyhow
my work on the HID support will take longer as expected and I hope that
I can finish the Bluetooth HID boot protocol support for the kernel
integration within the next two days.
Actually I thought that I will find some time to write the basics of the
AVDTP implementation in August, but I got invited to the O'Reilly Euro
Foo Camp. I will attend there and my plan is to present something very
nice, but right now I am not sure what it will be. Any proposals?
Regards
Marcel
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit http://www.blackhat.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi, Marcel.
> I already did that and in the fact of SEP it is nothing different from a
> PSM or RFCOMM channel. Actually because of this I thought that a socket
> based implementation is the best. Along time I prefered to keep AVDTP in
> userspace. However the only difficult part is the discover, because if
> you don't know the SEP you must use it to find the available ones and
> this includes a L2CAP connection. I must see how this gets integrated in
> a nice way.
I see.
You, Marcel, are the one of the best engineer in the world,
so I anticipate the time when AVDTP will be completed.
> There is no secret about it. Parts of the communication can be found in
> the mailing list archive. The rest was not in public, but actually only
> by accident.
I found those e-mails, thank you.
> What we had done was to fix the L2CAP and RFCOMM protocol layers and
> extend the test programs to pass the qualification tests.
>
> There was no contract and they didn't paid us.
Thank you, you furnished me with useful information.
Regards,
KeiHachi.
Hi, Marcel
> in most cases this is a problem of a broken mailer. I use Evolution and
> the only thing I do is hit the "Reply to All" button and write my
> answer.
Thank you.
I use OutLook Express made by Microsoft.
I reply by "Reply to All" functionality, too.
But in my case, the reply is handled as another thread.
It is strange... But I will forget it. Thank you.
> The problem is that they use multiple L2CAP connections with the same
> PSM for different protocols. This is totally stupid, because you can
> only differ between them on the order of their creation. However the
> basic mode looks very simple. Right now it looks like that I will
> support AVDTP as a sequential packet socket.
Probably it can be realized as a socket.
But some functionalities, like a SEP concept, should be considered in deeply.
> No problem for me, because I don't like talking about theoretical stuff.
> I prefer to talk about facts. If you know what you want, we can talk
> about what is possible and what not. And I can help you with not driving
> into a dead end.
Thank you, availing of your kind offer, I have one more question.
I know the product that uses BlueZ in it, as I found it on the BlueZ site before.
http://www.bluez.org/qualification.html
In that case, how did you or other guys help them to qualify?
For example, did that company paid some fee, or donation?
Were you or other guys under obligation to help them based on a contract?
Of course if you have the obligation to keep its secrets, it is OK to say nothing.
> No you didn't anything wrong. The smiley means for me that you should
> take me comment too serious. In this case this applies to the Affix
> stack, because I don't take this stack really serious.
Yes, of course I had understood your intention then.
Thank you for your concern again.
Regards,
KeiHachi.
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit http://www.blackhat.com
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel