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

[Marcel Holtmann <marcel holtmann org>]

Hi David,

> 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

the Bluetooth adapters are all class devices and unless the kernel guys
finally merges class device into devices we are a little bit stuck here.
However I finally got around and created a pseudo platform device for
Bluetooth this. It will be used for virtual and UART based Bluetooth
adapters which are other not backup by any device at all. Not everything
is based on USB.

So the missing pieces are to link other Bluetooth kernel services like
RFCOMM, HID, BNEP or CAPI with the Bluetooth adapter. I haven't come up
the best approach to do this right. The obvious problem is if you have
a /dev/rfcomm0 device for example. How do you tell which Bluetooth
adapter it is assigned to. And of course RFCOMM is capable of picking
any available adapter if you give it the wildcard source address.

Regards

Marcel