[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libhci update

On Thu, Apr 9, 2009 at 12:00 AM, Iain Hibbert <plunky_(_at_)_rya-online_(_dot_)_net> wrote:
> On Thu, 9 Apr 2009, Bruce Simpson wrote:
>> I disagree. I did a fairly in-depth code audit of PyBlueZ, LightBlue, and
>> BlueCove. All of them use BlueZ hci_* APIs for a number of things, mostly
>> to do with querying properties of the local interfaces.
> I looked briefly at BlueCove the other day and it seems to use a module to
> interface with the BlueZ/Linux API but it also has Windows and Mac modules
> amongst others. If it needs a FreeBSD or NetBSD module then that doesn't
> seem so difficult?

right, that is something i kinda wondering too. of course, i have no
idea how hard it would be to plug new bluetooth module into bluecove.
perhaps cost of adding the new bluetooth module more than implementing
something that looks like bluez?

>> The problem is that the horse has already left the cart.
> That happened many years ago when Microsoft was the leader in the
> marketplace. If you want to stay with the horse, use Windows.

the real question is: do we really want to follow the horse? :)
personally, i think that we should keep an eye on bluez etc. to see
where its going, but blindly follow it, is not something we want to
do, imo,

having said that, we have to recognize the fact that there is lots of
code that is bluez specific. so, how about we separate flies from
meatballs, and, meet halfway:

1) we put bsd-style bluetooth api and make sure it is shared with as
many bsd's (and possibly other os's) as possible. i  personally would
like to continue to work with Iain and get his input. this api is
going into the base system and will be bsd-licensed. obviously, we
will keep an eye on bluez while designing and implementing bsd
bluetooth api.

2) to ensure compatibility with bluez we create a separate library and
put it into the ports/ collection. it can even use original libhci
headers and re-use original libhci code if needed. missing/different
parts will have to be re-implemented in terms of bsd bluetooth api.
this way it would probably be easier to play catch up game with bluez
and it will be less of pain for folks who use bsd bluetooth api.
basically, if you choose bluez api be prepared to change your code
every time bluez folks change something.

>> There have been books published on how to use Bluetooth from Java and
>> other higher level languages than C. It seems unreasonable, in my view,
>> to expect folk developing applications in a commercial model, to have to
>> adapt their code for BSD targets beyond say 2 or 3 ifdef's.
> so write a module that interfaces (for example) the Java (BlueCove?) API
> to the FreeBSD OS layer. Its not that different from the BlueZ/Linux API
> and you can probably just do some copy and paste work. Thats how the GPL
> world works. Yes, you will not be able to integrate that work directly
> into FreeBSD but then I doubt a Java interface is ever going to be
> accepted into base anyway. Donate it to BlueCove.

well, it depends on how hard it is to add such module. i can certainly
see and understand yours and Bruce's point.

>> I realize this might be an inelegant approach, but it's based on
>> observation of harsh commercial realities.
> If its commercial, get those companies to contribute some BSD code.

oh, well, sometimes it is not as easy as it sounds.

>> Thanks for this. I would far rather not introduce a runtime or link-time
>> dependency on -lnetgraph if I can possibly avoid it. I'll digest further
>> and try to see if this can be incorporated.
> But I thought, on FreeBSD the whole bluetooth stack is netgraph based..?

yes, but in userspace you almost never need to use anything netgraph
related. almost everything can be done through sockets.

> My stance on the compatibility issue is that there are some things in the
> BlueZ/Linux C API (the major thing being 'devid' to address the radio)
> that are tied to the actual OS support and are unsupportable unless you
> provide exactly the same API in the OS. But, OS support is way too low
> level for an application to deal (with as you say), and a higher level API
> is needed that does not contain such specifics.

mostly agreed. its not really that bad with devid. we could invent
some "static" mapping between devname and devid. Bruce used id's from
netgraph,  i used (dev_type|unit_no) for mapping, and, i'm sure, you
can find something as simple as this. it really does not matter that
much as long as the application that uses devid's is not making any
assumptions about them (for example does not hardwire devid 0 - or
whatever - anywhere to talk to the first available bluetooth device).

> The BlueZ guys are, I think, working on a dbus API that will be used by
> GNOME and KDE and hopefully it won't be tied to the Linux OS API so
> closely, so that we can write dbus modules and have applications just work
> on our OS.  I have not been providing any input or review of that API
> though, it would be good if somebody would step up and point out where the
> API is tied too closely to the Linux OS interface and get them to make it
> a bit more generic.

right, and that is a very good point. that is something that i have to
deal with every day at $realjob. things in linux world change very
rapidly. from commercial point of view it is very annoying. its not
that uncommon that entire subsystems are being thrown away and
re-written from scratch without too much consideration. that is why i
think having a separate libhci/ port is making more sense here.

>> I looked at the Bluetooth specs and I can see that the inquiry sequence
>> doesn't hog all of the radio spectrum in use, but the implementation on
>> the CSR dongles won't raise any other events whilst the inquiry is in
>> progress.
> Is this purely a CSR problem?  My laptop has a Broadcom chip in and I
> notice that it can make multiple connections concurrently in that on
> bootup, it connects to both my mouse and keyboard by itself sometimes -
> the CSR dongle I used previously would connect to the keyboard fine but
> always fail the second connect with "Command Disallowed".  So much so that
> I thought perhaps about serialising connection attempts in the kernel.

that's right, some dongles would not do 2 or more create_connection
commands at the same time. i do not think specification actually
mandates this, so it is probably vendor/chip/firmware specific.

as far as periodic inquiry goes, its probably not the rf spectrum
hogging. its probably related to the way hardware and/or link manager
is implemented, i.e. from specification


A unit that wants to discover other Bluetooth units enters an inquiry substate.
In this substate, it continuously transmits the inquiry message (which is the ID
packet, see Section on page 55) at different hop frequencies. The
inquiry hop sequence is always derived from the LAP of the GIAC. Thus, even
when DIACs are used, the applied hopping sequence is generated from the


the key thing is that device has to continuously transmits the inquiry
message at different hop frequencies. at the same time the same device
may participate in another connection (which may require hopping as

> I've never looked at periodic inquiry though..

me too. but now i'm interested :)

freebsd-bluetooth_(_at_)_freebsd_(_dot_)_org mailing list
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe_(_at_)_freebsd_(_dot_)_org"

Visit your host, monkey.org