[Bluez-users] Missing: big picture

[Bluez-users] Missing: big picture

[Peter Wurmsdobler]

Hello,

For the past few month help requests come up repeatedly on this list, 
requests that are related to audio, headset, pass key - you name it. In 
my opinion this is due to a missing overall understanding rather than to 
unpredictable code behavior. At least for me, I miss an overall document 
describing the architecture to a new user's eyes.

I recognise that all the developers do a great job implementing features 
and advancing fast. They do a great job, but are far too deep in the 
matter in order to understand the comprehension difficulties of a 
newcomer. Certainly all reasons why there is no "big picture". The 
sparse collection of Wikis does not help either. Of course, look at the 
code is always an option, but it is time consuming.

Where is my problem? I see, on the one hand there is the well defined 
stack model. On the other, there is a collection of demons in user space 
and a bunch of kernel modules. But how does is hang together? What is 
the designed start-up sequence?

A bluetooth chip would be connected over different physical media such 
as UART, USB and SDIO to a linux host. Is it correct to assume that the 
respective kernel drivers will abstract the different physical transport 
media into the HCI interface?

By some magic (to me) hciattach creates socket interfaces hciX. I have 
added a service at start-up that does this, as in my case, the BC4-ROM 
will be connected permanently to the mx27 host processor. Why is a 
hciattach process required to maintain the hci0 interface? There is no 
equivalent thing for ethernet, is there? Or would it be the job of hcid 
anyway?

What is exactly the role of hcid? Is it to create hciX interfaces, or 
redirecting all communication coming in by the dbus to the proper hciX 
interface?

Assuming that hcid is involved in the creation of hciXes, does the sdpd 
have to be started afterwards, or before?

If passkey-agent and auth-agent are required but not supported, why is 
their service simply not included into the bluez-utils, but is offered 
by kde or gnome implementation, or even in QTopia? Because it involves 
user invention?

Assuming that, like in my case, a BT chip is connected permanently to 
the mx27 host processor, what is supposed to happened in what order? Who 
is involved and what configuration files are required?

In the case of a headset, what are the stages the entire bluetooth stack 
is going through from the moment you set the headset into pairing mode? 
What demons must be running, and how would the state diagram look like?

Now in case of an audio stream being sent from an audio player, how are 
the PCM sample routed to the BT headset (both with PCM data transfer 
over SCO using a dedicated SSI connection between CPU and BT chip, or 
piping the PCM data through HCI)?

One thing I can say, once I understand all that with the help hopefully 
of the list, I will write it up and make nice drawings. The downside 
could, once they are finished they are obsolete.

Regards,
peter


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

Re: [Bluez-users] Missing: big picture

[Marcel Holtmann]

Hi Peter,

> For the past few month help requests come up repeatedly on this list, 
> requests that are related to audio, headset, pass key - you name it. In 
> my opinion this is due to a missing overall understanding rather than to 
> unpredictable code behavior. At least for me, I miss an overall document 
> describing the architecture to a new user's eyes.
> 
> I recognise that all the developers do a great job implementing features 
> and advancing fast. They do a great job, but are far too deep in the 
> matter in order to understand the comprehension difficulties of a 
> newcomer. Certainly all reasons why there is no "big picture". The 
> sparse collection of Wikis does not help either. Of course, look at the 
> code is always an option, but it is time consuming.

and that is the point why developers should never write documentation,
because they always have a total different view point. I would prefer to
have some newbie starting some documentation and let the developers
assist him on question. People with no knowledge do the best manuals,
but they need guidance/help from the developers to distinguish right
from hacking and in some cases even actual bugs.

> Where is my problem? I see, on the one hand there is the well defined 
> stack model. On the other, there is a collection of demons in user space 
> and a bunch of kernel modules. But how does is hang together? What is 
> the designed start-up sequence?

I gave a lot of presentation at various conferences in the past and they
talk all about the stack design. The slides are all public.

> A bluetooth chip would be connected over different physical media such 
> as UART, USB and SDIO to a linux host. Is it correct to assume that the 
> respective kernel drivers will abstract the different physical transport 
> media into the HCI interface?

Yes.

> By some magic (to me) hciattach creates socket interfaces hciX. I have 
> added a service at start-up that does this, as in my case, the BC4-ROM 
> will be connected permanently to the mx27 host processor. Why is a 
> hciattach process required to maintain the hci0 interface? There is no 
> equivalent thing for ethernet, is there? Or would it be the job of hcid 
> anyway?

The hciattach is only needed in case of UART chips. USB and SDIO drivers
create the hciX interface directly. The hciattach case is needed since
you have to tell the kernel somehow to use an existing serial device
(like /dev/ttyS0) and use the Bluetooth H:4 (or BCSP etc.) protocol on
top of it. If you have USB or SDIO this step is not needed.

> What is exactly the role of hcid? Is it to create hciX interfaces, or 
> redirecting all communication coming in by the dbus to the proper hciX 
> interface?

The hciX interfaces are created by the Bluetooth subsystem inside the
kernel. Every driver registers a hci_dev device which becomes the next
hciX interface.

The hcid is the master daemon that handles additional device
initialization and pairing requests. This was its original task when
BlueZ 1.x and 2.x where released. With BlueZ 3.x we extended hcid to
expose a full D-Bus interface that allows you to control all device
settings.

> Assuming that hcid is involved in the creation of hciXes, does the sdpd 
> have to be started afterwards, or before?

No. The sdpd is a relic from old times. We don't use that anymore and
the main reason for it is technical. It had race conditions when
interacting with hcid. The full SDP server is now included in hcid. And
starting hcid with -s will enable it.

We only keep the sdpd binary around for reference. Actually with the
latest bluez-utils you would have to use --enable-sdpd to enable its
compilation. But again, it has been replaced with hcid. So don't use it
anymore.

> If passkey-agent and auth-agent are required but not supported, why is 
> their service simply not included into the bluez-utils, but is offered 
> by kde or gnome implementation, or even in QTopia? Because it involves 
> user invention?

A system process running as root should not hack around a user process
that owns the X session. The passkey and authentication agent concept is
an abstraction and allows us to have a way to tell hcid that a progress
that could display a dialog box and asked for PIN input is available
now. It is the clean daemon versus UI separation.

The GNOME and KDE desktops deliver agent implementation and it is easy
to write your own. This is what passkey-agent.c and auth-agent.c are
for. They give you a quick overview on how it has to be done.

The other advantage with abstracting the agents over D-Bus is that it
allows you to write agents in any programming language that has D-Bus
bindings. So a passkey agent in Python is about 20 lines of code or so.

> Assuming that, like in my case, a BT chip is connected permanently to 
> the mx27 host processor, what is supposed to happened in what order? Who 
> is involved and what configuration files are required?

Depends on the type of physical connection. The embedded world is always
a little bit more complex. Mostly these are UART or SDIO. So in the SDIO
case you start "hcid -s" and then make sure that you have agents that
suit your needs. You might have to write them by yourself.

In case of UART it is a little bit more trickier. In the simple way, you
also start "hcid -s" and then call hciattach with the right parameters
(don't ask me which they are, it depends on your board). However the
order of hcid and hciattach doesn't really matter.

There are some specific UART cases (for example the Nokia N8xx) in which
case they have their own kernel driver. Even if it is actually an UART.
If you have a kernel driver that drives your Bluetooth chip attached via
UART, you don't need the hciattach step. If the UART is exposed as
normal serial port, you do. As simple as that.

> In the case of a headset, what are the stages the entire bluetooth stack 
> is going through from the moment you set the headset into pairing mode? 
> What demons must be running, and how would the state diagram look like?

You need to enable the audio service. See /etc/bluetooth/audio.service
and change autostart. Then hcid will take care of actually starting the
audio service.

The configuration of your audio device via ALSA or GStreamer or directly
in case you use SCO over PCM is up to your UI application. Here you have
the same as for the agents, you might have to write your own one.

> Now in case of an audio stream being sent from an audio player, how are 
> the PCM sample routed to the BT headset (both with PCM data transfer 
> over SCO using a dedicated SSI connection between CPU and BT chip, or 
> piping the PCM data through HCI)?

In case of PCM, the daemons do nothing. It is up to you to hook up the
PCM interface of your Bluetooth chip with the sound system of your
embedded device.

In case of HCI, you can use ALSA or GStreamer and the plugins will make
sure the audio data goes to the SCO socket (for HFP/HSP) or L2CAP socket
(for A2DP).

> One thing I can say, once I understand all that with the help hopefully 
> of the list, I will write it up and make nice drawings. The downside 
> could, once they are finished they are obsolete.

Go ahead and use the wiki.

Regards

Marcel



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

Re: [Bluez-users] Missing: big picture

[Peter Wurmsdobler]

Hello Marcel,

many thanks for the explanations and your time. I will go through your 
presentations and once I got around bluez try to contribute to the wiki.

Regards,
peter


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

Re: [Bluez-users] Missing: big picture

[Brian Sammon]

> > I recognise that all the developers do a great job implementing features 
> > and advancing fast. They do a great job, but are far too deep in the 
> > matter in order to understand the comprehension difficulties of a 
> > newcomer. Certainly all reasons why there is no "big picture". The 
> > sparse collection of Wikis does not help either. Of course, look at the 
> > code is always an option, but it is time consuming.
> 
> and that is the point why developers should never write documentation,
> because they always have a total different view point. I would prefer to
> have some newbie starting some documentation and let the developers
> assist him on question. People with no knowledge do the best manuals,

The problem with this system is that you need someone to answer users questions.
The developers don't seem to be doing that consistently on this list.  I've asked a few questions here in the past, in an attempt to get a conceptual overview of how things work, and they were either ignored, or I got an answer from another user, usually along the lines of "Try this, it worked for me", an answer that sometimes worked, but was not helpful in getting understanding.

Please, encourage the developers to read and respond to this list--or should the users be posting these kinds of questions on bluez-devel?



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

Re: [Bluez-users] Missing: big picture

[Marcel Holtmann]

Hi Brian,

>>> I recognise that all the developers do a great job implementing  
>>> features
>>> and advancing fast. They do a great job, but are far too deep in the
>>> matter in order to understand the comprehension difficulties of a
>>> newcomer. Certainly all reasons why there is no "big picture". The
>>> sparse collection of Wikis does not help either. Of course, look  
>>> at the
>>> code is always an option, but it is time consuming.
>>
>> and that is the point why developers should never write  
>> documentation,
>> because they always have a total different view point. I would  
>> prefer to
>> have some newbie starting some documentation and let the developers
>> assist him on question. People with no knowledge do the best manuals,
>
> The problem with this system is that you need someone to answer  
> users questions.
> The developers don't seem to be doing that consistently on this  
> list.  I've asked a few questions here in the past, in an attempt to  
> get a conceptual overview of how things work, and they were either  
> ignored, or I got an answer from another user, usually along the  
> lines of "Try this, it worked for me", an answer that sometimes  
> worked, but was not helpful in getting understanding.
>
> Please, encourage the developers to read and respond to this list-- 
> or should the users be posting these kinds of questions on bluez- 
> devel?

this works very well and a lot of people spent a lot of time to answer  
questions on the mailing list and track down problems. However you  
should read this first:

http://www.catb.org/~esr/faqs/smart-questions.html

It is important to understand what you can expect and what not. Also  
you go to #bluez on freenode.net and ask questions.

My advise would be to start some documentation inside the wiki and  
then ask questions. Asking them up-front without showing that you will  
contribute to the project doesn't go good with any developers of any  
open source project. The secret is to give something back and you  
would be surprised how much help you can get quite quickly.

Regards

Marcel


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

Re: [Bluez-users] Missing: big picture

[Brian Sammon]

> > Please, encourage the developers to read and respond to this list-- 
> > or should the users be posting these kinds of questions on bluez- 
> > devel?
> 
> this works very well and a lot of people spent a lot of time to answer  

I'm a little unclear what you're saying here.  Are you saying that, yes, it is 
better to ask these questions on the developer's mailing list?

> questions on the mailing list and track down problems. However you  
> should read this first:
> 
> http://www.catb.org/~esr/faqs/smart-questions.html

I'm quite familiar with this page.  Is there one of my previous questions that 
you thought was not "smart", or is this just general advice?

> My advise would be to start some documentation inside the wiki and  

Actually, I think that the last thing the wiki needs is more "started" 
documentation.  My plan would be to fix (or "finish") some of the 
documentation that has already been started.

> then ask questions. Asking them up-front without showing that you will  
> contribute to the project doesn't go good with any developers of any  

I have contributed.  If you look through the archives of this list, you'll see 
that I've attempted to provide assistance to other users on a few occasions, 
as well as I could with my limited knowledge.

In any case, when I find some time in the next few days I'll repost my 
unanswered questions from a few months ago, and if I get an answer, I'll try 
to integrate it into the wiki.

Re: [Bluez-users] Missing: big picture

[Marcel Holtmann]

Hi Brian,

>>> Please, encourage the developers to read and respond to this list--
>>> or should the users be posting these kinds of questions on bluez-
>>> devel?
>>
>> this works very well and a lot of people spent a lot of time to  
>> answer
>
> I'm a little unclear what you're saying here.  Are you saying that,  
> yes, it is
> better to ask these questions on the developer's mailing list?

if you are writing any kind of documentation and you need help with  
it, then yes, ask on the developer mailing list or via IRC.

>> questions on the mailing list and track down problems. However you
>> should read this first:
>>
>> http://www.catb.org/~esr/faqs/smart-questions.html
>
> I'm quite familiar with this page.  Is there one of my previous  
> questions that
> you thought was not "smart", or is this just general advice?

I was more going into the area where the document speaks about what  
you can expect and in which timeframe. Besides asking questions the  
right way, you have to understand what you can expect.

>> My advise would be to start some documentation inside the wiki and
>
> Actually, I think that the last thing the wiki needs is more "started"
> documentation.  My plan would be to fix (or "finish") some of the
> documentation that has already been started.

Either way is fine with me.

>> then ask questions. Asking them up-front without showing that you  
>> will
>> contribute to the project doesn't go good with any developers of any
>
> I have contributed.  If you look through the archives of this list,  
> you'll see
> that I've attempted to provide assistance to other users on a few  
> occasions,
> as well as I could with my limited knowledge.
>
> In any case, when I find some time in the next few days I'll repost my
> unanswered questions from a few months ago, and if I get an answer,  
> I'll try
> to integrate it into the wiki.

Do so. I am looking forward to read it.

Regards

Marcel


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