Hello,
I'm trying to write a Bluetooth interface layer for another API, targeting
Bluez as the backend. Unfortunately I don't seem to be able to find any API
documentation for how to drive Bluez. I've managed to reverse engineer a fair
amount of it by studying the header files and the source code for libbluetooth
and bluez-utils, but this is only getting me so far.
(Currently, I'm trying to figure out how to turn discoverability on and off on
the local machine. This appears to be harder than it looks.)
I don't suppose someone can tell me where all this is documented?
--
David Given
[email protected]
This message is subject to Tao's e-mail terms ( http://e.tao-group.com/1 )
Tao Group Ltd, 62/63 Suttons Business Park, Suttons Park Avenue,
Reading, Berkshire RG6 1AZ. Registered in England, number 2722079
-------------------------------------------------------------------------
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Andrew,
> > D-Bus is the solution for a generic IPC between applications or daemons
> > and the size of the system doesn't matter. I never said that D-Bus is
> > perfect, but it is time that all the embedded people that complain about
> > D-Bus actually start fixing it. Believe it or not, D-Bus is the way to
> > go for shrinking the memory footprint in your embedded systems, because
> > all applications will use the same IPC.
>
> I understand your reasons for using D-Bus; I really do. It's a pain in the
> ass to try and maintain more than one IPC mechanism for any project, BlueZ or
> otherwise. I honestly don't fault you at all for selecting D-Bus, and my
> aside from my recognition of it elegantly solving a particular problem for
> you, I also tend to think that if you're using bluetooth you've likely got
> enough memory for a full-blown message bus such as D-Bus as well.
> Complaining about the requirement for D-Bus for BlueZ is kind of like
> complaining about the need for the TCP part of the IP stack if all you're
> using is UDP and ICMP.
>
> Having said that, I tend to complain about D-Bus because it's so goddamned
> convoluted, even for a regular desktop application. I am chalking that up
> mostly to my own ignorance on the use of and architecture of the message bus.
>
> I disagree, however, that it's the bees' knees when it comes to unifying IPC
> in all circumstances. For many applications, both embedded and not, there is
> absolutely NO NEED for an abstraction layer this "thick" -- I don't give a
> rat's ass for introspection, data typing, nor any of the loftier goals that
> D-Bus addresses. IOCTLs are more than enough for most of my applications,
> and the fact that they change from time to time... who cares? Embedded
> systems don't evolve nor do they get updated anywhere NEAR as quickly as
> desktops. When something changes it's because of a damn good reason, not
> because of "hey wow, there's a new version out!" Besides that, I get by, as
> many others do, with FAR lighter IPC mechanisms, including passing pointers
> around to shared data structures.
>
> As I review what I've written here, I find myself idly wondering about
> a "dbus-lite" -- a very thin emulation of the D-Bus API which strips away
> everything that makes D-Bus so cool and lets us smaller guys put this issue
> to rest once and for all.
I was thinking about embedded D-Bus (edbus) like what we and the Mono
project does with GLib. There was a potential sponsor of that project,
but the backed out and so I might not get started on it. However feel
free to fill in and get this done.
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Thursday 10 May 2007 8:57 am, Marcel Holtmann wrote:
> D-Bus is the solution for a generic IPC between applications or daemons
> and the size of the system doesn't matter. I never said that D-Bus is
> perfect, but it is time that all the embedded people that complain about
> D-Bus actually start fixing it. Believe it or not, D-Bus is the way to
> go for shrinking the memory footprint in your embedded systems, because
> all applications will use the same IPC.
I understand your reasons for using D-Bus; I really do. It's a pain in the
ass to try and maintain more than one IPC mechanism for any project, BlueZ or
otherwise. I honestly don't fault you at all for selecting D-Bus, and my
aside from my recognition of it elegantly solving a particular problem for
you, I also tend to think that if you're using bluetooth you've likely got
enough memory for a full-blown message bus such as D-Bus as well.
Complaining about the requirement for D-Bus for BlueZ is kind of like
complaining about the need for the TCP part of the IP stack if all you're
using is UDP and ICMP.
Having said that, I tend to complain about D-Bus because it's so goddamned
convoluted, even for a regular desktop application. I am chalking that up
mostly to my own ignorance on the use of and architecture of the message bus.
I disagree, however, that it's the bees' knees when it comes to unifying IPC
in all circumstances. For many applications, both embedded and not, there is
absolutely NO NEED for an abstraction layer this "thick" -- I don't give a
rat's ass for introspection, data typing, nor any of the loftier goals that
D-Bus addresses. IOCTLs are more than enough for most of my applications,
and the fact that they change from time to time... who cares? Embedded
systems don't evolve nor do they get updated anywhere NEAR as quickly as
desktops. When something changes it's because of a damn good reason, not
because of "hey wow, there's a new version out!" Besides that, I get by, as
many others do, with FAR lighter IPC mechanisms, including passing pointers
around to shared data structures.
As I review what I've written here, I find myself idly wondering about
a "dbus-lite" -- a very thin emulation of the D-Bus API which strips away
everything that makes D-Bus so cool and lets us smaller guys put this issue
to rest once and for all.
-A.
-------------------------------------------------------------------------
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Andrew,
> > all. Most probably, the footprint is too large for memory-restricted
> > systems. Because of that and the fact there are very few (if any)
> > projects for embedded systems that use d-bus it's hardly worth the
> > effort to port it. Bluez has worked quite well for embedded systems with
> > older versions, but since it ignores the demands of embedded systems
> > it's probably better to use a different bluetooth stack.
>
> This would be my response as well. Marcel has purposely made it difficult to
> locate older versions of BlueZ in the (IMO) misguided attempt to force
> everyone to test and use the new stuff. I can see WHY he's chosen to use
> d-bus, but yes; it's seems to be unsuitable for light embedded systems and
> you're probably better off with another stack. There aren't many uses for a
> message bus in small embedded systems.
D-Bus is the solution for a generic IPC between applications or daemons
and the size of the system doesn't matter. I never said that D-Bus is
perfect, but it is time that all the embedded people that complain about
D-Bus actually start fixing it. Believe it or not, D-Bus is the way to
go for shrinking the memory footprint in your embedded systems, because
all applications will use the same IPC.
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On Thursday 10 May 2007 4:01 am, Erwin Authried wrote:
> Until now, it seems that nobody has ported d-bus to uClinux. Doing that
> isn't trivial, because there are several uses of fork() that isn't
> available in uClinux. In openwrt, there isn't any mention of d-bus at
Actually, I built dbus-libs and most of dbus-utils under m68knommu without too
much trouble; Now I did have some manual hacking to do, and there were a few
tools which did not build, but I did get hciattach, hciconfig, hcitool and
hcid built. I could have sworn I had the sdp and pan utils too, but my build
environment is a bit of a mess these days.
> all. Most probably, the footprint is too large for memory-restricted
> systems. Because of that and the fact there are very few (if any)
> projects for embedded systems that use d-bus it's hardly worth the
> effort to port it. Bluez has worked quite well for embedded systems with
> older versions, but since it ignores the demands of embedded systems
> it's probably better to use a different bluetooth stack.
This would be my response as well. Marcel has purposely made it difficult to
locate older versions of BlueZ in the (IMO) misguided attempt to force
everyone to test and use the new stuff. I can see WHY he's chosen to use
d-bus, but yes; it's seems to be unsuitable for light embedded systems and
you're probably better off with another stack. There aren't many uses for a
message bus in small embedded systems.
-A.
-------------------------------------------------------------------------
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hello,
I suppose your hcid is running as root, and you checked its output to
ensure it can properly "grab" the org.bluez names for himself, and that
there is no error at that point.
Regards,
Pierre-Yves
Mark S. Townsley wrote:
> Hi Johan:
>
> If you have a DBUS client that is working making use of some Bluez-DBUS
> API, can I take a look at it as example?
>
> I am using C and just to confirm, I also went to the Python-Bluez
> binding making use of the DBUS API. And I got the same error message.
>
> If it is a config issue, I would like to know what I should be putting
> into my dbus.conf and hcid.conf?
> Thanks
>
>
> On 5/9/07, *Johan Hedberg* <[email protected]
> <mailto:[email protected]>> wrote:
>
> Hi Mark,
>
> On May 9, 2007, at 19:27, Mark S. Townsley wrote:
> > I am trying to follow your advice and use the D-BUS API instead of
> > the low-level HCI API.
> > However, no matter which D-BUS method I issued, I got back this
> error:
> >
> > The name org.bluez was not provided by any .service files
> >
> > I tried to search online but could not find any answer. I searched
> > the archive, nothing comes up. Can you provide your expertise on
> > this one? What are these .service files? How can I make one for
> > org.bluez?
>
> I'm kind of surprised you haven't figured this out already. All you
> need is a running hcid process, and you need to use the system bus
> (it's not clear from your description whether you used the session or
> the system bus). hcid provides the D-Bus well known name org.bluez on
> the system bus. Because your D-Bus client doesn't find org.bluez
> (i.e. hcid is not running) it tries to see if it is activatable but
> does not find any .service file which would describe how to activate
> it (because hcid is not meant to be activated by D-Bus, but should
> e.g. be run from an init script).
>
> Johan
>
>
> -------------------------------------------------------------------------
> 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-users mailing list
> [email protected]
> <mailto:[email protected]>
> https://lists.sourceforge.net/lists/listinfo/bluez-users
>
>
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-users
-------------------------------------------------------------------------
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi David,
> > Since I haven't heard of hcilib before your post, I am not sure that
> > this holds valid. The BlueZ project doesn't use hcilib and also doesn't
> > support hcilib. So ask the hcilib maintainer.
>
> Actually I got the name wrong --- I was working off the header files, which
> refer to hcilib. The shared library itself is called libbluetooth, and this is
> shipped as bluez-libs, and is used by hcid itself.
as I said, I've never heard of hcilib and so I have no idea if it is an
actual library or only some additional header files or whatever.
In case of libbluetooth you will find enough examples in bluez-utils and
as you mentioned, hcid is using it.
The HCI raw socket that is used by libbluetooth and hcid is not a nice
programming interface and actually I already have plans to restrict or
completely remove it. The D-Bus abstraction works really nicely and
makes Bluetooth simple. Direct HCI programming is not easy and we needed
two years to get the current hcid in shape for the defined tasks. To
make this point even more clear. Only the kernel should mess around with
HCI directly. Userspace can never get it fully correct.
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Marcel Holtmann wrote:
[...]
> Since I haven't heard of hcilib before your post, I am not sure that
> this holds valid. The BlueZ project doesn't use hcilib and also doesn't
> support hcilib. So ask the hcilib maintainer.
Actually I got the name wrong --- I was working off the header files, which
refer to hcilib. The shared library itself is called libbluetooth, and this is
shipped as bluez-libs, and is used by hcid itself.
[...]
> Again. Ask the hcilib maintainer.
I'm afraid that you are the maintainer.
--
David Given
[email protected]
This message is subject to Tao's e-mail terms ( http://e.tao-group.com/1 )
Tao Group Ltd, 62/63 Suttons Business Park, Suttons Park Avenue,
Reading, Berkshire RG6 1AZ. Registered in England, number 2722079
-------------------------------------------------------------------------
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Erwin,
> > > That's just not *reasonable* on a system with low memory, especially since
> > > Bluetooth will be the only thing that uses it.
> >
> > And how is the D-Bus overhead a BlueZ problem. Again if the current
> > D-Bus daemon and its library is not suitable, then fix it.
> >
> Until now, it seems that nobody has ported d-bus to uClinux. Doing that
> isn't trivial, because there are several uses of fork() that isn't
> available in uClinux. In openwrt, there isn't any mention of d-bus at
> all. Most probably, the footprint is too large for memory-restricted
> systems. Because of that and the fact there are very few (if any)
> projects for embedded systems that use d-bus it's hardly worth the
> effort to port it. Bluez has worked quite well for embedded systems with
> older versions, but since it ignores the demands of embedded systems
> it's probably better to use a different bluetooth stack.
and again. That is a D-Bus issue. Make the D-Bus maintainers fix it. All
the blaming doesn't help since D-Bus is the generic IPC and to keep
embedded system small it should be the only IPC.
If people don't like the D-Bus usage of BlueZ, they can use the 2.x
branch or any other Bluetooth stack.
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Am Donnerstag, den 10.05.2007, 09:09 +0200 schrieb Marcel Holtmann:
> Hi David,
>
> > >> to be quite frankly, then don't ask me about it. If you wanna screw
> > with
> > >> your system you are on your own.
> >
> > You seem not to have much experience with embedded systems.
>
> actually I have quite some experience with embedded systems and I used
> to think the same way as you do right now, but D-Bus is the way to go
> even for embedded systems. There is no excuse. If D-Bus is not suitable
> then fix D-Bus and don't blame the system using it.
>
> > On my system, there are two instances of dbus-daemon occupying 432 pages and
> > 304 pages respectively, an instance of dbus-launch with 244, and an instance
> > of hcid with 348. There are also two *more* instances of dbus-daemon, but they
> > may be specific to the user and so irrelevant. Even so, that's still a total
> > of 1328 pages, or 5312kB.
> >
> > That's just not *reasonable* on a system with low memory, especially since
> > Bluetooth will be the only thing that uses it.
>
> And how is the D-Bus overhead a BlueZ problem. Again if the current
> D-Bus daemon and its library is not suitable, then fix it.
>
Until now, it seems that nobody has ported d-bus to uClinux. Doing that
isn't trivial, because there are several uses of fork() that isn't
available in uClinux. In openwrt, there isn't any mention of d-bus at
all. Most probably, the footprint is too large for memory-restricted
systems. Because of that and the fact there are very few (if any)
projects for embedded systems that use d-bus it's hardly worth the
effort to port it. Bluez has worked quite well for embedded systems with
older versions, but since it ignores the demands of embedded systems
it's probably better to use a different bluetooth stack.
Regards,
Erwin
-------------------------------------------------------------------------
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi David,
> >> to be quite frankly, then don't ask me about it. If you wanna screw
> with
> >> your system you are on your own.
>
> You seem not to have much experience with embedded systems.
actually I have quite some experience with embedded systems and I used
to think the same way as you do right now, but D-Bus is the way to go
even for embedded systems. There is no excuse. If D-Bus is not suitable
then fix D-Bus and don't blame the system using it.
> On my system, there are two instances of dbus-daemon occupying 432 pages and
> 304 pages respectively, an instance of dbus-launch with 244, and an instance
> of hcid with 348. There are also two *more* instances of dbus-daemon, but they
> may be specific to the user and so irrelevant. Even so, that's still a total
> of 1328 pages, or 5312kB.
>
> That's just not *reasonable* on a system with low memory, especially since
> Bluetooth will be the only thing that uses it.
And how is the D-Bus overhead a BlueZ problem. Again if the current
D-Bus daemon and its library is not suitable, then fix it.
If you wanna deal with the Bluetooth HCI by yourself, then you are on
your own now. The BlueZ project moved into the D-Bus direction with the
3.x releases and that is a fixed decision.
> Since all this code is going to have to go through the kernel interface anyway
> to get anything done, it's far more appropriate to use that instead.
> Particularly since there's a helpful library, hcilib, that wraps the kernel
> interface and makes it easy to use. (And which, BTW, is recommended by all the
> tutorial code I've been able to find.)
Since I haven't heard of hcilib before your post, I am not sure that
this holds valid. The BlueZ project doesn't use hcilib and also doesn't
support hcilib. So ask the hcilib maintainer.
> I was hoping that someone would be able to point me at the document that
> specifies what this interface actually *is*.
Again. Ask the hcilib maintainer.
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi Johan:
If you have a DBUS client that is working making use of some Bluez-DBUS API,
can I take a look at it as example?
I am using C and just to confirm, I also went to the Python-Bluez binding
making use of the DBUS API. And I got the same error message.
If it is a config issue, I would like to know what I should be putting into
my dbus.conf and hcid.conf?
Thanks
On 5/9/07, Johan Hedberg <[email protected]> wrote:
>
> Hi Mark,
>
> On May 9, 2007, at 19:27, Mark S. Townsley wrote:
> > I am trying to follow your advice and use the D-BUS API instead of
> > the low-level HCI API.
> > However, no matter which D-BUS method I issued, I got back this error:
> >
> > The name org.bluez was not provided by any .service files
> >
> > I tried to search online but could not find any answer. I searched
> > the archive, nothing comes up. Can you provide your expertise on
> > this one? What are these .service files? How can I make one for
> > org.bluez?
>
> I'm kind of surprised you haven't figured this out already. All you
> need is a running hcid process, and you need to use the system bus
> (it's not clear from your description whether you used the session or
> the system bus). hcid provides the D-Bus well known name org.bluez on
> the system bus. Because your D-Bus client doesn't find org.bluez
> (i.e. hcid is not running) it tries to see if it is activatable but
> does not find any .service file which would describe how to activate
> it (because hcid is not meant to be activated by D-Bus, but should
> e.g. be run from an init script).
>
> Johan
>
>
> -------------------------------------------------------------------------
> 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-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-users
>
Hi Johan:
Thanks for your reply. I am using the system bus on my client.
And I have both DBus and hcid running. I am using all the low-level HCI
calls and they are working fine. That is until I want to check linkkeys and
remove some myself. The HCI method does not remove for me. And Marcel
suggest using DBUS API HasBonding().
So my DBUS is running all along. My hcid is running all along. And inside
my code, I am asking for system bus also.
I will try to attach my code later but I am doing/checking all that you have
mentioned.
Thanks
Mark
On 5/9/07, Johan Hedberg <[email protected]> wrote:
>
> Hi Mark,
>
> On May 9, 2007, at 19:27, Mark S. Townsley wrote:
> > I am trying to follow your advice and use the D-BUS API instead of
> > the low-level HCI API.
> > However, no matter which D-BUS method I issued, I got back this error:
> >
> > The name org.bluez was not provided by any .service files
> >
> > I tried to search online but could not find any answer. I searched
> > the archive, nothing comes up. Can you provide your expertise on
> > this one? What are these .service files? How can I make one for
> > org.bluez?
>
> I'm kind of surprised you haven't figured this out already. All you
> need is a running hcid process, and you need to use the system bus
> (it's not clear from your description whether you used the session or
> the system bus). hcid provides the D-Bus well known name org.bluez on
> the system bus. Because your D-Bus client doesn't find org.bluez
> (i.e. hcid is not running) it tries to see if it is activatable but
> does not find any .service file which would describe how to activate
> it (because hcid is not meant to be activated by D-Bus, but should
> e.g. be run from an init script).
>
> Johan
>
>
> -------------------------------------------------------------------------
> 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-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-users
>
Hi Mark,
On May 9, 2007, at 19:27, Mark S. Townsley wrote:
> I am trying to follow your advice and use the D-BUS API instead of
> the low-level HCI API.
> However, no matter which D-BUS method I issued, I got back this error:
>
> The name org.bluez was not provided by any .service files
>
> I tried to search online but could not find any answer. I searched
> the archive, nothing comes up. Can you provide your expertise on
> this one? What are these .service files? How can I make one for
> org.bluez?
I'm kind of surprised you haven't figured this out already. All you
need is a running hcid process, and you need to use the system bus
(it's not clear from your description whether you used the session or
the system bus). hcid provides the D-Bus well known name org.bluez on
the system bus. Because your D-Bus client doesn't find org.bluez
(i.e. hcid is not running) it tries to see if it is activatable but
does not find any .service file which would describe how to activate
it (because hcid is not meant to be activated by D-Bus, but should
e.g. be run from an init script).
Johan
-------------------------------------------------------------------------
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
On 5/9/07, David Given <[email protected]> wrote:
> On my system, there are two instances of dbus-daemon occupying 432 pages and
> 304 pages respectively, an instance of dbus-launch with 244, and an instance
> of hcid with 348. There are also two *more* instances of dbus-daemon, but they
> may be specific to the user and so irrelevant. Even so, that's still a total
> of 1328 pages, or 5312kB.
maybe there is some old bluez version without dbus ?
by the way did u manage to cross compile dbus on your embedded ?
-------------------------------------------------------------------------
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Mark S. Townsley wrote:
[...]
> I tried to search online but could not find any answer. I searched the
> archive, nothing comes up. Can you provide your expertise on this one?
> What are these .service files? How can I make one for org.bluez?
I'm using a Ubuntu Feisty, which is only a few weeks old; bluez-utils appears
to be the critical package, containing hcid (that seems to do the work) and
/etc/dbus-1/system.d/bluetooth.conf (that declares the Bluetooth service). I
can't find any documentation describing how to set all this up, though...
[...]
> On 5/9/07, Marcel Holtmann <[email protected]> wrote:
>> to be quite frankly, then don't ask me about it. If you wanna screw with
>> your system you are on your own.
You seem not to have much experience with embedded systems.
On my system, there are two instances of dbus-daemon occupying 432 pages and
304 pages respectively, an instance of dbus-launch with 244, and an instance
of hcid with 348. There are also two *more* instances of dbus-daemon, but they
may be specific to the user and so irrelevant. Even so, that's still a total
of 1328 pages, or 5312kB.
That's just not *reasonable* on a system with low memory, especially since
Bluetooth will be the only thing that uses it.
Since all this code is going to have to go through the kernel interface anyway
to get anything done, it's far more appropriate to use that instead.
Particularly since there's a helpful library, hcilib, that wraps the kernel
interface and makes it easy to use. (And which, BTW, is recommended by all the
tutorial code I've been able to find.)
I was hoping that someone would be able to point me at the document that
specifies what this interface actually *is*.
--
David Given
[email protected]
This message is subject to Tao's e-mail terms ( http://e.tao-group.com/1 )
Tao Group Ltd, 62/63 Suttons Business Park, Suttons Park Avenue,
Reading, Berkshire RG6 1AZ. Registered in England, number 2722079
-------------------------------------------------------------------------
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Marcel:
I am trying to follow your advice and use the D-BUS API instead of the
low-level HCI API.
However, no matter which D-BUS method I issued, I got back this error:
The name org.bluez was not provided by any .service files
I tried to search online but could not find any answer. I searched the
archive, nothing comes up. Can you provide your expertise on this one?
What are these .service files? How can I make one for org.bluez?
I am forced to go back to the HCI API (at least they work for now) until I
figure out how to resolve this lack of .service files. Any tips/pointers
much appreciated.
Mark
On 5/9/07, Marcel Holtmann <[email protected]> wrote:
>
> Hi David,
>
> > > you choice, but that way is deprecated and might go away at any point
> in
> > > the future.
> >
> > My device doesn't *have* D-Bus.
> >
> > Actually, I forgot to mention that I can also use hcilib (as it's just a
> thin
> > wrapper over the ioctl layer). The only documentation for that appears
> to be
> > the header file...
>
> to be quite frankly, then don't ask me about it. If you wanna screw with
> your system you are on your own.
>
> 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-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-users
>
Hi David,
> > you choice, but that way is deprecated and might go away at any point in
> > the future.
>
> My device doesn't *have* D-Bus.
>
> Actually, I forgot to mention that I can also use hcilib (as it's just a thin
> wrapper over the ioctl layer). The only documentation for that appears to be
> the header file...
to be quite frankly, then don't ask me about it. If you wanna screw with
your system you are on your own.
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Marcel Holtmann wrote:
[...]
> you choice, but that way is deprecated and might go away at any point in
> the future.
My device doesn't *have* D-Bus.
Actually, I forgot to mention that I can also use hcilib (as it's just a thin
wrapper over the ioctl layer). The only documentation for that appears to be
the header file...
--
David Given
[email protected]
This message is subject to Tao's e-mail terms ( http://e.tao-group.com/1 )
Tao Group Ltd, 62/63 Suttons Business Park, Suttons Park Avenue,
Reading, Berkshire RG6 1AZ. Registered in England, number 2722079
-------------------------------------------------------------------------
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi David,
> > check the dbus-api.txt document inside the bluez-utils source, because
> > it provides D-Bus methods for all common tasks.
>
> Unfortunately D-Bus isn't any use to me; I'm really looking for the sockets API.
you choice, but that way is deprecated and might go away at any point in
the future.
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Marcel Holtmann wrote:
[...]
> check the dbus-api.txt document inside the bluez-utils source, because
> it provides D-Bus methods for all common tasks.
Unfortunately D-Bus isn't any use to me; I'm really looking for the sockets API.
--
David Given
[email protected]
This message is subject to Tao's e-mail terms ( http://e.tao-group.com/1 )
Tao Group Ltd, 62/63 Suttons Business Park, Suttons Park Avenue,
Reading, Berkshire RG6 1AZ. Registered in England, number 2722079
-------------------------------------------------------------------------
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users
Hi David,
> I'm trying to write a Bluetooth interface layer for another API, targeting
> Bluez as the backend. Unfortunately I don't seem to be able to find any API
> documentation for how to drive Bluez. I've managed to reverse engineer a fair
> amount of it by studying the header files and the source code for libbluetooth
> and bluez-utils, but this is only getting me so far.
>
> (Currently, I'm trying to figure out how to turn discoverability on and off on
> the local machine. This appears to be harder than it looks.)
>
> I don't suppose someone can tell me where all this is documented?
check the dbus-api.txt document inside the bluez-utils source, because
it provides D-Bus methods for all common tasks.
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-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-users