Daemon News Ezine BSD News BSD Mall BSD Support Forum BSD Advocacy BSD Updates
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Automatic bluetooth device initialization

Maksim Yevmenkin wrote:

Paul,


fine. if you could please tell us a little bit more and explain
what is wrong with the current way of doing things in linux and/or
freebsd.



don't get me wrong, there isn't anything wrong with the current state
of bluetooth configuration utilities. If you've spent some time reading the freebsd handbook or some unofficial bluez tutorials and you're accustomed to the command line (like most of the people on 
this list, I assume) then you're just set.. ..but if you take into
account the regular desktop user (like how linux and freebsd are
trying to do right now) you see the need for something more intuitive
and immediate than the 'current way of doing things', this basically
involves some sort of user interface, at the very least. Even on this
i though we are talking about bluetooth device _initialization_. right now, in freebsd, user does not have to do anything except loading the drivers and plugging the device. all configuration parameters are in one file and documented. adjusting configuration for bluetooth devices in freebsd is not that much different from putting stuff into /etc/rc.conf etc.
i agree with you, there is no gnome/kde/whatever gui applet that knows about bluetooth in freebsd. i also admit that there are no gui based bluetooth tools in freebsd. however, this, in my opinion, has nothing to do with bluetooth devices initialization. 


mailing list, little time ago, there was a request about porting the
excellent kde bluetooth framework to freebsd, but, as you noted, in
it's current form kdebluetooth has very deep roots in bluez, and it
also has deep roots in KDE, so even adapting to another desktop manager would be difficult. To solve such (not uncommon) problems, 
the dbus system[¹] is being developed, dbus is getting very popular
(maybe too much) and it provides a simple and secure messaging system
to let different programs talk to one another, in our example, let
one program be the bluetooth daemon, it provides a well-known
interface and hides platform-specific implementation details, on the
other side we have the other programs, which are just frontends (with
a Qt/Gtk/textual interface, it doesn't matter) and can run on every
operating system where the aforementioned interface is available, I
think something like this wouldn't hurt to any "desktop-unix"
operating system.
while i appreciate your effort in this area, i'm skeptical that d-bus and/or whatever api will solve this problem. i think, instead of introducing yet another compatibility layer that sits on top of native api, everyone would be much better off if native api was the same. what would solve this problem, imo, is the standard (something like posix) that would define api etc.
in the very beginning, i asked linux bluez folks if they are willing to release their user space code under dual (gpl/bsd) license. someone immediately shoot me down with the statement that bluez code is gpl and it will remain so forever. i admit, it was a very weak attempt and i did not push it any further. instead, i choose to write my own code under bsd license so it can be included into freebsd.
i took a very quick look at kde-bluetooth sources and i could not find anything that would suggest that kde-bluetooth is trying to work on non linux-bluez systems. it seems like all that needs to be done is to teach libkbluetooth about other non linux-bluez systems. 

The same holds for libbtctl of gnome-bluetooth.
I wouldn't dismiss an effort to standardize on a dbus API, though. I can see quite a few advantages in such an approach: 

- dbus is already ported to FreeBSD and many other systems
- porting kde-bluetooth or gnome-bluetooth would essentially require a new (albeit slim) portability layer in order to minimize synchronization effort with the upstream sources - the bluetooh subsystem speed requirements are not very high, as to prohibit a (hopefully efficient) portability layer - it seems much more feasible to target the compatibility on a dbus API than to reach consensus on a posix-like API
Nevertheless, if you are confident that we can achieve standardization in a lower level, I'm definitely all for it. 


Regards,
Panagiotis