Date: Thu, 9 Apr 2009 09:00:03 +0100 (BST) From: Iain Hibbert <plunky@rya-online.net> To: Bruce Simpson <bms@incunabulum.net> Cc: "freebsd-bluetooth@freebsd.org" <freebsd-bluetooth@freebsd.org> Subject: Re: libhci update Message-ID: <1239264003.862926.638.nullmailer@galant.ukfsn.org> In-Reply-To: <49DD40E2.5030403@incunabulum.net> References: <49D92E26.2030508@incunabulum.net> <bb4a86c70904061358l3983ed51m11265859a833f202@mail.gmail.com> <49DD40E2.5030403@incunabulum.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 > handling. 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 > 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. 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 http://www.netbsd.org/~plunky/sdp-20090227.tar.gz iain
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1239264003.862926.638.nullmailer>