Bluetooth and HAL (Was Re: PPTP Plugin Updated -- Ver. 0.6.9 Generally PPP capable?)

[David Zeuthen <davidz redhat com>]

Hi,

(adding the HAL list as Cc)

On Wed, 2006-06-07 at 14:00 +0200, Marcel Holtmann wrote:
> > I planned on mirroring bluetooth information in hal, rather than leaving 
> > it up to applications to query bluez directly. There's two reasons for 
> > this:
> 
> Be careful how you do the mirroring. We spent a lot of time discussing
> what methods and signals are actually needed. Especially if you have a
> passive application etc. I would prefer that you call into the BlueZ
> D-Bus whenever possible instead of storing the information by yourself.

Right, as Matthew said I think we want it to look like this

 pci
  usb controller
      bluetooth controller       <-- can do Scan() on HAL here to
                                     refresh the list of devices

          phone                  <-- can do DiscoverServices() on HAL
                                     here to refresh what services are
                                     available. Can also do Pair() to
                                     pair with the device.
             obex ftp              
             dial up networking  <-- Can do SetupTTY() on HAL here to
                                     get a tty to start the DUN. This
                                     will create yet another device

                 serial port     <-- Created in response to SetupTTY(),
                                     is just another serial port device,
                                     will have additional HAL
                                     capabilities such as marking it as
                                     being a Hayes compatible modem etc.
                                     Possible to merge AT init strings
                                     via HAL fdi files since you can
                                     match on the phone's make and model

          mouse                      (another BT device, has methods
                                      Pair(), DiscoverServices() etc.)

             input device        <-- just a standard input device like
                                     the one hal exposes for e.g. PS/2
                                     and USB mice

This is ideally how I like to look; with this Bluetooth devices nicely
blend into the HAL device tree. That is why I think it would be nice if
sysfs exposed what Bluetooth devices were available. Without this I
think it's pretty hard to infer e.g. that /dev/input/event42 stems from
a Bluetooth device. I'm not asking for service information, just asking
for the actual bluetooth devices to appear in sysfs (the kernel already
knows about them).

However, if it's easily easy to get this from Bluez userspace daemons on
Linux rather than sysfs, then fine with me. Btw, slightly more than a
year ago I fooled around with patching the kernel for this, here it is

 http://people.freedesktop.org/~david/bt.txt
 http://people.freedesktop.org/~david/davidz-bluetooth.patch

> > 1) It makes it easier for applications if there's one source of 
> > information about hardware they can drive. Networkmanager, for instance, 
> > will want to know about bluetooth devices, ir devices, any 
> > serially-connected modems we can probe, usb modems (where supportable) 
> > and so on.
> 
> If we can achieve this, I am all for it. However it is not really
> trivial and we must make sure that certain information are kept in a
> central place or requested every time. You will see some corner cases
> with a couple of devices over time. For example when they change the
> RFCOMM channel number if you reboot them. Scary stuff like that, that
> even we haven't addressed so far.

Right, we want to make this right and I'm happy we're having this
discussion

> > 2) For certain trivial purposes, it means that the application doesn't 
> > need to rely on the bluez API - any different bluetooth stack can just 
> > be hidden behind hal.
> 
> The BlueZ D-Bus API is designed to hide from BlueZ library or kernel
> specific things. So in general you can reuse it for FreeBSD etc. Any
> Gnome application using the BlueZ D-Bus API should work on any system
> that provides a Bluetooth stack this interface.
> 
> Don't try to duplicate that effort, because it is a mess and some
> internal code of hcid is really scary.

Right, we don't want to duplicate anything. We just want to make sure
that the user has a single unified place to get information about both
the hardware be it (USB, Bluetooth or whatever) and the functional
abstractions (input, networking etc.) it provides. I'm happy to see HAL
use existing code as much as possible.

So for e.g. input and audio devices I expect the Bluetooth input and
audio drivers to just give me respective /dev/input/event*
and /dev/snd/* devices and they will fit into HAL nicely. Then pairing
with a bluetooth headset or speakers will "just work" in e.g. GNOME
because someone already did the effort to make hotplugging USB headsets
work with all the nasty details that entails. 

Another point is when X.org gains the ability to be configured in other
ways than via /etc/X11/xorg.conf. Then you will simply have a "X11
server configuration daemon" running in your desktop session that will
read user preferences from gconf (in GNOME) about e.g. what input
devices to attach to the X.org server. To do this effectively (not to
mention in a OS independent way) said daemon simply queries HAL.

Of course, stuff as PAN networking may be slightly harder to fit with
HAL because in some ways it's pretty Bluetooth specific. So, not
everything will work in the HAL model because we want to keep things
simple to use. Personally I think the pand stuff should be in
NetworkManager proper but that may be pushing it at this point :-)

So that's exactly what HAL is about... providing a simple abstract
interface and making the desktop work with that. I can't see why we it
shouldn't do Bluetooth devices.

What do you think?

Cheers,
David