Re: [Bluez-devel] DBus interface - determining whether a device exists

Matthew Garrett
2006-08-17T11:35:38Z

On Thu, Aug 17, 2006 at 02:56:00PM +0200, Marcel Holtmann wrote:

> You must understand that you can't do this with Bluetooth. If you wanna
> know if you can connect to a device then the baseband has to page the
> other device. This is an expensive operation and it will stall all
> ongoing paging or inquiry operations. So in general you don't wanna do
> this unless you are in a special environment and know what all users are
> doing. For the normal desktop case we simply don't know this. So it is
> not a good idea. Not speaking of the higher power consumption of such
> operations.

In this specific case, it's done at login time. That's a point where we
/do/ know whether or not there are any existing connections (I'm
ignoring the multiple user case, because the DBus API doesn't really
deal with that at the moment anyway).

> You also have to think about moving targets. For example at an airport
> where a lot of devices will pass you. Trying to page them and waiting
> for a page timeout is an even more expensive operation.

Sorry, possibly I should be clearer about the behaviour I'm talking
about here.

Imagine the case where a user has bound a set of headphones. They've
chosen to make them their default audio device. At login time, we wish
to attempt to reconnect to the headphones. It would be nice to be able
to do so by checking whether the device exists or not first.

At the moment, the method for doing that would appear to be to store the
following information:

1) The bluetooth address
2) The fact that it's a set of headphones
3) Whether it uses rfcomm or l2cap

and then at login time do service discovery (because we don't know
whether the channel may have changed) and attempt to set up a
connection. The alternative would be to store:

1) The bluetooth address

and then at login time attempt a baseband connection to the device. If
it exists, then we can do service discovery and worry about the other
pieces of information. If we can't set up a baseband connection, we
don't need to bother.

The second approach strikes me as simpler than the first approach, but
it requires the ability to set up that baseband connection which you're
clearly unhappy with. Is the first approach how I should be doing this?

> So what you actually want is to set a device in periodic inquiry mode
> and then make it constantly report devices in range.

Well, no - I don't actually care what happens to the device after that.
If the user moves the device out of range, or if the user logs in
without the device being switched on, then it's acceptable to require
the user to manually reenable the device. But it's entirely reasonable
for the user to say "If the device is switched on when I log in, please
automatically connect to it". That's the problem that I'm trying to
solve. Unlike periodic inquiry, this wouldn't result in any significant
increase in power consumption. It's a one-shot-per-session thing.

--
Matthew Garrett | mjg59@srcf.ucam.org