[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libhci update
- To: Bruce Simpson <bms_(_at_)_incunabulum_(_dot_)_net>
- Subject: Re: libhci update
- From: Iain Hibbert <plunky_(_at_)_rya-online_(_dot_)_net>
- Date: Thu, 9 Apr 2009 09:00:03 +0100 (BST)
- Cc: "freebsd-bluetooth_(_at_)_freebsd_(_dot_)_org" <freebsd-bluetooth_(_at_)_freebsd_(_dot_)_org>
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?
I looked at LightBlue but I don't remember anything about it, was it
perchance really incomplete and very BlueZ/Linux based?
> 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.
> 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.
> 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.
> We certainly need an easy to use API which doesn't concern high level
> language users with too many of the specifics of low level I/O event
as you say, the Java API is one such.
> 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..?
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.
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.
> 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
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.
I've never looked at periodic inquiry though..
> > right, that would likely be complete replacement of libsdp and sdpd.
> If that's what it amounts to, I'll get my hands dirty. It's just
> essential for what my partner and I are trying to do, that we have
> high-level language bindings for Bluetooth features essential to
> building a server application, working on FreeBSD.
I have written at least a set of SDP primitives that I'm intending to
import to NetBSD 'soon' (I have only one computer and am concentrating on
5.0 release first because running different OS versions is messy)
I think the latest archive was at
freebsd-bluetooth_(_at_)_freebsd_(_dot_)_org mailing list
To unsubscribe, send any mail to "freebsd-bluetooth-unsubscribe_(_at_)_freebsd_(_dot_)_org"