2006-08-16 15:34:32

by Matthew Garrett

[permalink] [raw]
Subject: [Bluez-devel] DBus interface - determining whether a device exists

I'd like to use the DBus interface to determine whether or not a
Bluetooth device is currently in range of the computer in order to work
out whether or not it's possible to connect to it. Checking through the
API suggests that there's currently nothing suitable for doing that.
What would be the best way to implement it?

Thanks,
--
Matthew Garrett | [email protected]

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel


2006-08-18 18:06:12

by Marcel Holtmann

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

Hi Frederic,

> >we also store the last seen (inquiry) and last used (connected) time of
> >any device. This can be also used to populate the HAL list. For example
> >it should include all bonded devices and additionally devices that have
> >been connected in the last 7 days or so.
> >
> In this case, I think it can be usefull to have same APIs in DBus for
> "used devices" than for "paired devices". You can find in attachement a
> patch that add ListUsed and RemovedUsed methods to hcid.
> Hope this helps.

I am not happy about the RemoveUsed method. I am not sure if one
application should be able to say when a used device will be removed
from the list. I think this should be application specific.

I also might prefer to name the method ListRemoteDevices to list all
paired, seen and used remote devices. We can then have special versions
of this method for specific tasks. For example ListRecentRemoteDevices
with a date parameter that will only list paired and used devices in
that time frame.

Regards

Marcel



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2006-08-17 18:44:06

by Marcel Holtmann

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

Hi Matthew,

> > For this specific case we should only page the device if the audio
> > device has been opened and there is actually an audio stream. I is not
> > important if the device is in range or not. If it is not in range then
> > you won't hear anything or we need to choose a fallback. I think that
> > these stuff doesn't belong in the core Bluetooth daemon. You want to
> > have an btaudiod that handles all these stuff in the back for you. The
> > user only configures once the possible connections to headphones and
> > headsets and then the daemon will take care of everything.
>
> The problem isn't just in actually setting up the connections, it's in
> providing the information about available devices to other applications.
> Nowadays, the right layer for device enumeration is HAL. If I tell my
> system about a mobile phone, then the correct behaviour is for it to
> appear as a HAL object. In order for Network Manager to offer me the
> choice of connecting via my phone, the phone needs to be in HAL. So,
> somehow, at login time the phone needs to be added.
>
> There's two ways of dealing with this. The one that I prefer is that we
> make some effort to determine that the phone actually exists, and then
> add it to HAL in the same way that we would if we'd just done device
> discovery and the phone was discoverable. This needs us to have some
> mechanism for determining whether the phone actually exists. The second
> is that we store the HAL data and repopulate HAL at login time. This is
> more hacky, since we're adding information without even having made a
> token effort to determine whether the device exists or not.

is the HAL data user specific and do we always need to populate it on
login time. I think doing it once at boot and then update it on regular
basis once hcid has more information about devices and/or new devices.

Regards

Marcel



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2006-08-17 18:36:01

by Marcel Holtmann

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

Hi Bastien,

> > > I guess that since we don't have any guarantees that the device exists
> > > at any given point in time anyway, this makes less difference and we
> > > should just populate HAL regardless. I suppose I'm open to that.
> >
> > Maybe you could simply use the list of bonded devices to populate HAL?
> > You could use the ListBondings method and BondingCreated/BondingRemoved
> > signals for that.
>
> This is how MacOS X populates its selection lists. They have the list of
> paired devices, as well as "Favourite" devices.

we also store the last seen (inquiry) and last used (connected) time of
any device. This can be also used to populate the HAL list. For example
it should include all bonded devices and additionally devices that have
been connected in the last 7 days or so.

Regards

Marcel



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2006-08-17 13:03:33

by Bastien Nocera

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

On Thu, 2006-08-17 at 15:45 +0300, Johan Hedberg wrote:
> Hi Matthew,
>
> On Thu, Aug 17, 2006, Matthew Garrett wrote:
<snip>
> > I guess that since we don't have any guarantees that the device exists
> > at any given point in time anyway, this makes less difference and we
> > should just populate HAL regardless. I suppose I'm open to that.
>
> Maybe you could simply use the list of bonded devices to populate HAL?
> You could use the ListBondings method and BondingCreated/BondingRemoved
> signals for that.

This is how MacOS X populates its selection lists. They have the list of
paired devices, as well as "Favourite" devices.

--
Bastien Nocera <[email protected]>


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2006-08-17 13:01:42

by Johan Hedberg

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

On Thu, Aug 17, 2006, Matthew Garrett wrote:
> On Thu, Aug 17, 2006 at 03:45:14PM +0300, Johan Hedberg wrote:
>
> > Maybe you could simply use the list of bonded devices to populate HAL?
> > You could use the ListBondings method and BondingCreated/BondingRemoved
> > signals for that.
>
> Is that persistant over restarts of the daemon?

Yes.

Johan

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2006-08-17 12:52:12

by Matthew Garrett

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

On Thu, Aug 17, 2006 at 03:45:14PM +0300, Johan Hedberg wrote:

> Maybe you could simply use the list of bonded devices to populate HAL?
> You could use the ListBondings method and BondingCreated/BondingRemoved
> signals for that.

Is that persistant over restarts of the daemon? I've remembered why
repopulating HAL is difficult - only root can add devices (for fairly
obvious reasons). I'll have to see what I can do about that.

--
Matthew Garrett | [email protected]

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2006-08-17 12:45:14

by Johan Hedberg

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

Hi Matthew,

On Thu, Aug 17, 2006, Matthew Garrett wrote:
> The problem isn't just in actually setting up the connections, it's in
> providing the information about available devices to other applications.
> Nowadays, the right layer for device enumeration is HAL. If I tell my
> system about a mobile phone, then the correct behaviour is for it to
> appear as a HAL object. In order for Network Manager to offer me the
> choice of connecting via my phone, the phone needs to be in HAL. So,
> somehow, at login time the phone needs to be added.
>
> There's two ways of dealing with this. The one that I prefer is that we
> make some effort to determine that the phone actually exists, and then
> add it to HAL in the same way that we would if we'd just done device
> discovery and the phone was discoverable. This needs us to have some
> mechanism for determining whether the phone actually exists. The second
> is that we store the HAL data and repopulate HAL at login time. This is
> more hacky, since we're adding information without even having made a
> token effort to determine whether the device exists or not.
>
> I guess that since we don't have any guarantees that the device exists
> at any given point in time anyway, this makes less difference and we
> should just populate HAL regardless. I suppose I'm open to that.

Maybe you could simply use the list of bonded devices to populate HAL?
You could use the ListBondings method and BondingCreated/BondingRemoved
signals for that.

Johan

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2006-08-17 12:25:59

by Matthew Garrett

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

On Thu, Aug 17, 2006 at 04:04:59PM +0200, Marcel Holtmann wrote:

> For this specific case we should only page the device if the audio
> device has been opened and there is actually an audio stream. I is not
> important if the device is in range or not. If it is not in range then
> you won't hear anything or we need to choose a fallback. I think that
> these stuff doesn't belong in the core Bluetooth daemon. You want to
> have an btaudiod that handles all these stuff in the back for you. The
> user only configures once the possible connections to headphones and
> headsets and then the daemon will take care of everything.

The problem isn't just in actually setting up the connections, it's in
providing the information about available devices to other applications.
Nowadays, the right layer for device enumeration is HAL. If I tell my
system about a mobile phone, then the correct behaviour is for it to
appear as a HAL object. In order for Network Manager to offer me the
choice of connecting via my phone, the phone needs to be in HAL. So,
somehow, at login time the phone needs to be added.

There's two ways of dealing with this. The one that I prefer is that we
make some effort to determine that the phone actually exists, and then
add it to HAL in the same way that we would if we'd just done device
discovery and the phone was discoverable. This needs us to have some
mechanism for determining whether the phone actually exists. The second
is that we store the HAL data and repopulate HAL at login time. This is
more hacky, since we're adding information without even having made a
token effort to determine whether the device exists or not.

I guess that since we don't have any guarantees that the device exists
at any given point in time anyway, this makes less difference and we
should just populate HAL regardless. I suppose I'm open to that.

Thanks,
--
Matthew Garrett | [email protected]

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2006-08-17 14:04:59

by Marcel Holtmann

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

Hi Matthew,

> > 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).

actually the API can handle it, but we don't honor different users from
the backend part at the moment. We talked about it, but it was put off
as something to address later when all Bluetooth parts are working
smoothly together.

> > 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?

I personally don't like to page a bunch of devices at login time. This
can end up in a bad user experience. For example if they use a Bluetooth
mouse and keyboard. This might block with some older chips or they
experience some rough time.

For this specific case we should only page the device if the audio
device has been opened and there is actually an audio stream. I is not
important if the device is in range or not. If it is not in range then
you won't hear anything or we need to choose a fallback. I think that
these stuff doesn't belong in the core Bluetooth daemon. You want to
have an btaudiod that handles all these stuff in the back for you. The
user only configures once the possible connections to headphones and
headsets and then the daemon will take care of everything.

This will be complete new D-Bus API for Bluetooth. I talked about my
ideas for it at the OLS, but no actual code has been written so far.

> > 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.

Except that you wanna keep up the connection. Even with sniff mode, this
consumes more power than a disconnected device. This is one of the
reasons why mice and keyboards are shutting down the connections after a
specific idle time. Same applies to other devices. If you don't actually
need the connection, then don't have it. In the case of headphones you
don't wanna have a connection if you don't have any audio.

I know that these models doesn't really fit into the Linux way at the
moment, but we will see them more and more. Bluetooth is only the first
technology used a "disconnected model". Wireless USB and UWB will have
to deal with it, too. And power consumption is a big factor. I just
applied a patch to use ppoll() instead of poll() for a couple of our
deaemons.

Regards

Marcel



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2006-08-17 13:51:04

by Marcel Holtmann

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

Hi Matthew,

> > what you actually want is something like l2ping so see if a device is
> > alive or not. At the moment I am not considering such an extension,
> > because we shouldn't page devices to see if they are active or not.
>
> Why not? It seems more sensible to do that than to blindly attempt to
> set up a hid connection without knowing whether the device actually
> exists or not.

the HID case doesn't fly. All HID devices only need an initial connect
and the they reconnect to the host.

But again, the costs of getting this knowledge are to expensive. In most
cases you have to serialize page attempts and make sure you don't
interrupt inquiries or disturb other connections. For example the high
quality audio part might not really like that you try to page other
devices a lot of times. It will work, but if the audio stream breaks to
often you have a bad user experience.

Once we offer such a method it gets used and it will get abused for
weird tricks application wanna play. So you need a better argument to
convince me to include something like this.

Regards

Marcel



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2006-08-17 11:35:38

by Matthew Garrett

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

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 | [email protected]

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2006-08-17 11:22:26

by Matthew Garrett

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

On Thu, Aug 17, 2006 at 02:57:55PM +0200, Marcel Holtmann wrote:

> what you actually want is something like l2ping so see if a device is
> alive or not. At the moment I am not considering such an extension,
> because we shouldn't page devices to see if they are active or not.

Why not? It seems more sensible to do that than to blindly attempt to
set up a hid connection without knowing whether the device actually
exists or not.
--
Matthew Garrett | [email protected]

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2006-08-17 12:57:55

by Marcel Holtmann

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

Hi Matthew,

> > > Right. But the DBus interface doesn't seem to provide any mechanism for
> > > initiating a connection to the device. GetName and the like appear to
> > > provide cached results even if the device is now out of range, which
> > > isn't what I want.
> > Hi Matthew,
> >
> > What about RFCOMM ConnectByChannel? Wouldn't it do the job?
>
> Well, it's not necessarily an RFCOMM connection. I'd prefer to just be
> able to store the fact that a device exists rather than what sort of
> connection and on what channels, especially since Marcel mentioned that
> the channel may well have changed if the Bluetooth device has been
> rebooted.

what you actually want is something like l2ping so see if a device is
alive or not. At the moment I am not considering such an extension,
because we shouldn't page devices to see if they are active or not.

Regards

Marcel



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2006-08-17 12:56:00

by Marcel Holtmann

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

Hi Matthew,

> > this is a general Bluetooth problem. If you don't have a connection
> > between two devices then there is no radio traffic. This is one of big
> > difference between Bluetooth and WiFi.
>
> Right. But the DBus interface doesn't seem to provide any mechanism for
> initiating a connection to the device. GetName and the like appear to
> provide cached results even if the device is now out of range, which
> isn't what I want.

the GetName results are cached. That is correct, but they are also
updated every time we get new information about it. For example if hcid
sees a ACL connection, it requests the remote name again. This is a
cheap operation at no costs and keeps the name up-to-date. Also if you
see an extended inquiry or a name resolve itself it will update the
cache and send out a RemoteNameChanged signal. The same applies to other
information like class of device etc.

> There's an obvious use case for having a function that is, effectively,
> "Can I currently connect to the device with this bluetooth address". The
> patch I sent provides that, but if that's unacceptable then what should
> the interface look like?

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.

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.

So what you actually want is to set a device in periodic inquiry mode
and then make it constantly report devices in range. However this should
be an optional operation, because the power consumption argument is here
valid, too. For most Bluetooth 1.2 and 2.0 dongles you then get inquiry
results that also include the RSSI value. From these you can make an
assumption if a device is near enough. There is threshold of RSSI that
indicates a device will not be in range for a connection even if an
inquiry sees it.

So from my part I am happy to see support for periodic inquiry and this
is what you actually should go with. I can't think of an API at the
moment, but I must admit that I didn't put any big effort into it right
now. Feel free to propose something.

Regards

Marcel



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2006-08-17 08:15:03

by Matthew Garrett

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

On Wed, Aug 16, 2006 at 10:21:19PM -0300, Cezar S=E1 Espinola wrote:
> > Right. But the DBus interface doesn't seem to provide any mechanism for
> > initiating a connection to the device. GetName and the like appear to
> > provide cached results even if the device is now out of range, which
> > isn't what I want.
> Hi Matthew,
> =

> What about RFCOMM ConnectByChannel? Wouldn't it do the job?

Well, it's not necessarily an RFCOMM connection. I'd prefer to just be =

able to store the fact that a device exists rather than what sort of =

connection and on what channels, especially since Marcel mentioned that =

the channel may well have changed if the Bluetooth device has been =

rebooted.

-- =

Matthew Garrett | [email protected]

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easi=
er
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D1=
21642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2006-08-17 01:21:19

by Cezar Sa Espinola

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

> Right. But the DBus interface doesn't seem to provide any mechanism for
> initiating a connection to the device. GetName and the like appear to
> provide cached results even if the device is now out of range, which
> isn't what I want.
Hi Matthew,

What about RFCOMM ConnectByChannel? Wouldn't it do the job?

Best Regards,
Cezar

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2006-08-16 21:46:06

by Matthew Garrett

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

On Thu, Aug 17, 2006 at 01:16:17AM +0200, Marcel Holtmann wrote:

> this is a general Bluetooth problem. If you don't have a connection
> between two devices then there is no radio traffic. This is one of big
> difference between Bluetooth and WiFi.

Right. But the DBus interface doesn't seem to provide any mechanism for
initiating a connection to the device. GetName and the like appear to
provide cached results even if the device is now out of range, which
isn't what I want.

There's an obvious use case for having a function that is, effectively,
"Can I currently connect to the device with this bluetooth address". The
patch I sent provides that, but if that's unacceptable then what should
the interface look like?

Thanks,
--
Matthew Garrett | [email protected]

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2006-08-16 23:16:17

by Marcel Holtmann

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

Hi Matthew,

> I'd like to use the DBus interface to determine whether or not a
> Bluetooth device is currently in range of the computer in order to work
> out whether or not it's possible to connect to it. Checking through the
> API suggests that there's currently nothing suitable for doing that.
> What would be the best way to implement it?

this is a general Bluetooth problem. If you don't have a connection
between two devices then there is no radio traffic. This is one of big
difference between Bluetooth and WiFi.

The only possible solution is to have the other device always be in
discoverable mode and use periodic inquiry with the RSSI values or
defines something for extended inquiry to transmit additional
information.

Regards

Marcel



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2006-08-16 23:13:25

by Marcel Holtmann

[permalink] [raw]
Subject: Re: [Bluez-devel] [PATCH] - add ConnectRemoteDevice method to dbus

Hi Matthew,

> I'm not sure if this is the best approach, but still:
>
> The included patch adds a ConnectRemoteDevice method to the Bluez DBus
> interface. It's the effective equivalent of hcitool cc. The idea is to
> have somthing that can be used by a session daemon when it wants to
> reconnect to devices on login.

we left this out on purpose. The disconnect was a compromise for systems
where we might end up with stuck connections. The "hcitool cc ..." is
for debugging purpose only and so this patch is not acceptable.

Regards

Marcel



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2006-08-16 20:41:32

by Matthew Garrett

[permalink] [raw]
Subject: [Bluez-devel] [PATCH] - add ConnectRemoteDevice method to dbus

I'm not sure if this is the best approach, but still:

The included patch adds a ConnectRemoteDevice method to the Bluez DBus
interface. It's the effective equivalent of hcitool cc. The idea is to
have somthing that can be used by a session daemon when it wants to
reconnect to devices on login.

Index: dbus-adapter.c
===================================================================
RCS file: /cvsroot/bluez/utils/hcid/dbus-adapter.c,v
retrieving revision 1.70
diff -u -r1.70 dbus-adapter.c
--- dbus-adapter.c 15 Aug 2006 14:55:55 -0000 1.70
+++ dbus-adapter.c 16 Aug 2006 20:35:50 -0000
@@ -1648,6 +1648,56 @@

}

+static DBusHandlerResult handle_dev_connect_remote_device_req(DBusConnection *conn, DBusMessage *msg, void *data)
+{
+ DBusMessage *reply;
+ DBusError err;
+
+ struct hci_dbus_data *dbus_data = data;
+
+ const char *peer_addr;
+ bdaddr_t peer_bdaddr;
+ int dd, ptype;
+ uint16_t handle = 0;
+
+ dbus_error_init(&err);
+ dbus_message_get_args(msg, &err,
+ DBUS_TYPE_STRING, &peer_addr,
+ DBUS_TYPE_INVALID);
+
+ if (dbus_error_is_set(&err)) {
+ error("Can't extract message arguments:%s", err.message);
+ dbus_error_free(&err);
+ return error_invalid_arguments(conn, msg);
+ }
+
+ if (check_address(peer_addr) < 0)
+ return error_invalid_arguments(conn, msg);
+
+ str2ba(peer_addr, &peer_bdaddr);
+
+ dd = hci_open_dev(dbus_data->dev_id);
+ if (dd < 0)
+ return error_no_such_adapter(conn, msg);
+
+ ptype = HCI_DM1 | HCI_DM3 | HCI_DM5 | HCI_DH1 | HCI_DH3 | HCI_DH5;
+
+ /* Send the HCI connect command */
+ if (hci_create_connection (dd, &peer_bdaddr, htobs(ptype), 0, 0x01, &handle, 25000) < 0) {
+ error("Connect failed");
+ hci_close_dev(dd);
+ return error_failed(conn, msg, errno);
+ }
+
+ hci_close_dev(dd);
+
+ reply = dbus_message_new_method_return(msg);
+ if (!reply)
+ return DBUS_HANDLER_RESULT_NEED_MEMORY;
+
+ return send_reply_and_unref(conn, reply);
+}
+
static DBusHandlerResult handle_dev_create_bonding_req(DBusConnection *conn, DBusMessage *msg, void *data)
{
char filename[PATH_MAX + 1];
@@ -2365,6 +2415,7 @@

{ "DisconnectRemoteDevice", handle_dev_disconnect_remote_device_req },

+ { "ConnectRemoteDevice", handle_dev_connect_remote_device_req },
{ "CreateBonding", handle_dev_create_bonding_req },
{ "CancelBonding", handle_dev_cancel_bonding_req },
{ "RemoveBonding", handle_dev_remove_bonding_req },
Index: dbus-api.txt
===================================================================
RCS file: /cvsroot/bluez/utils/hcid/dbus-api.txt,v
retrieving revision 1.40
diff -u -r1.40 dbus-api.txt
--- dbus-api.txt 9 Aug 2006 20:10:50 -0000 1.40
+++ dbus-api.txt 16 Aug 2006 20:35:51 -0000
@@ -553,6 +553,15 @@

Question: Can we find a better name?

+ void ConnectRemoteDevice(string address)
+
+ This method creates a baseband connection to a specific
+ remote device.
+
+ Possible errors: org.bluez.Error.InvalidArguments
+ org.bluez.Error.NoSuchAdapter
+ org.bluez.Error.Failed
+
void DisconnectRemoteDevice(string address)

This method disconnects a specific remote device by

Index: dbus-test
===================================================================
RCS file: /cvsroot/bluez/utils/hcid/dbus-test,v
retrieving revision 1.22
diff -u -r1.22 dbus-test
--- dbus-test 9 Aug 2006 20:10:50 -0000 1.22
+++ dbus-test 16 Aug 2006 20:35:52 -0000
@@ -45,6 +45,7 @@
"ClearRemoteAlias",
"LastSeen",
"LastUsed",
+ "ConnectRemoteDevice",
"DisconnectRemoteDevice",
"CreateBonding",
"CancelBondingProcess",
@@ -343,9 +344,14 @@
print self.device.LastUsed(self.cmd_args[0])
else:
print 'Usage: %s -i <dev> LastUsed address' % self.name
+ elif self.cmd == 'ConnectRemoteDevice':
+ if len(self.cmd_args) == 1:
+ print self.device.ConnectRemoteDevice(self.cmd_args[0])
+ else:
+ print 'Usage: %s -i <dev> ConnectRemoteDevice address' % self.name
elif self.cmd == 'DisconnectRemoteDevice':
if len(self.cmd_args) == 1:
- print self.device.LastUsed(self.cmd_args[0])
+ print self.device.DisconnectRemoteDevice(self.cmd_args[0])
else:
print 'Usage: %s -i <dev> DisconnectRemoteDevice address' % self.name
elif self.cmd == 'CreateBonding':

--
Matthew Garrett | [email protected]

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2006-10-18 14:03:52

by Johan Hedberg

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

Hi Fred,

On Wed, Oct 18, 2006, Frederic Danis wrote:
> You can find attached a new patch implementing ListRemoteDevices and
> ListRecentRemoteDevices.

Couple of notes about your patch:

> +static void list_remote_devices_do_append(char *key, char *value, void *data)
> +{
> + struct remote_device_list_t *param = data;
> + char *address;
> + struct tm date;
> +
> + if (slist_find(param->list, key, (cmp_func_t) bacmp))
> + return;

bacmp takes bdaddr_t pointers not char pointers. You probably want to
use strcasecmp.

> + slist_append(param->list, address);

This should be:
param->list = slist_append(param->list, address);

> + /* Add Bonded devices to the list */
> + create_name(filename, PATH_MAX, STORAGEDIR, adapter->address, "linkkeys");
> + textfile_foreach(filename, list_remote_devices_do_append, &param);
> +
> + /* Add Last Used devices to the list */
> + create_name(filename, PATH_MAX, STORAGEDIR, adapter->address, "lastused");
> + textfile_foreach(filename, list_remote_devices_do_append, &param);
> +
> + /* Add Last Seen devices to the list */
> + create_name(filename, PATH_MAX, STORAGEDIR, adapter->address, "lastseen");
> + textfile_foreach(filename, list_remote_devices_do_append, &param);
> +
> + reply = dbus_message_new_method_return(msg);
> +
> + dbus_message_iter_init_append(reply, &iter);
> +
> + dbus_message_iter_open_container(&iter, DBUS_TYPE_ARRAY,
> + DBUS_TYPE_STRING_AS_STRING, &array_iter);
> +
> + slist_foreach(param.list, remote_devices_do_append, &array_iter);
> +
> + slist_free(param.list);

slist_free only frees the nodes in the list but not the data they point
to (the strings which have been allocated with strdup). So you probably
want to call slist_foreach(param.list, (slist_func_t) free, NULL) before
slist_free or free the data in remote_devices_do_append.

> + /* Add Bonded devices to the list */
> + create_name(filename, PATH_MAX, STORAGEDIR, adapter->address, "linkkeys");
> + textfile_foreach(filename, list_remote_devices_do_append, &param);
> +
> + /* Add Last Used devices to the list */
> + create_name(filename, PATH_MAX, STORAGEDIR, adapter->address, "lastused");
> + textfile_foreach(filename, list_remote_devices_do_append, &param);
> +
> + reply = dbus_message_new_method_return(msg);
> +
> + dbus_message_iter_init_append(reply, &iter);
> +
> + dbus_message_iter_open_container(&iter, DBUS_TYPE_ARRAY,
> + DBUS_TYPE_STRING_AS_STRING, &array_iter);
> +
> + slist_foreach(param.list, remote_devices_do_append, &array_iter);
> +
> + slist_free(param.list);

And same applies here.

Johan

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2006-11-10 19:04:37

by Johan Hedberg

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

Hi Fred,

On Fri, Nov 10, 2006, Frederic Danis wrote:
> Here is a new version of the patch updated. apitest is updated.
> Hope it is OK.

It's in the CVS now. There were a few more white space issues I fixed as
well as some wording in dbus-api.txt (we use "adapter" to mean a local
device and "device" to mean a remote device).

Johan

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2006-11-10 16:40:12

by Marcel Holtmann

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

Hi Johan,

> > Are you OK with this patch ?
>
> I'm fine with it (although I don't have a good use case for it). However,
> it'll still need Marcel's blessing before being included.

looks okay to me. Except there are two or three minor whitespace issues
in the patch. One in a function call and others for the casts. Please
fix them and then I am okay with that patch. I would prefer that apitest
also gets updated to use these two new methods.

Regards

Marcel



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2006-11-10 08:12:32

by Johan Hedberg

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

Hi Fred,

On Tue, Nov 07, 2006, Frederic Danis wrote:
> Are you OK with this patch ?

I'm fine with it (although I don't have a good use case for it). However,
it'll still need Marcel's blessing before being included.

Johan

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

2006-11-07 17:28:43

by Frederic Danis

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

Hello,

Are you OK with this patch ?

Regards

Fred

-----------------------------------------------
It is not by improving the oil lamp that one invents the electric bulb!
-----------------------------------------------
Danis Frederic PalmSource Europe
Software engineer
Mail : mailto:[email protected]
-----------------------------------------------



Frederic Danis a =E9crit :
> Hello Johan,
>
> Here is a new version of the patch updated.
> Thanks for your comments.
>
>
> Fred
>
> ------------------------------------------------------------------------
>
> diff -Naur hcid.orig/dbus-adapter.c hcid.new/dbus-adapter.c
> --- hcid.orig/dbus-adapter.c 2006-10-17 17:54:10.000000000 +0200
> +++ hcid.new/dbus-adapter.c 2006-10-20 15:58:53.000000000 +0200
> @@ -25,10 +25,12 @@
> #include <config.h>
> #endif
> =

> +#define _GNU_SOURCE
> #include <stdio.h>
> #include <errno.h>
> #include <fcntl.h>
> #include <unistd.h>
> +#include <time.h>
> #include <sys/param.h>
> #include <sys/ioctl.h>
> #include <sys/socket.h>
> @@ -2615,6 +2617,126 @@
> return DBUS_HANDLER_RESULT_HANDLED;
> }
> =

> +struct remote_device_list_t {
> + struct slist *list;
> + time_t time;
> +};
> +
> +static void list_remote_devices_do_append(char *key, char *value, void *=
data)
> +{
> + struct remote_device_list_t *param =3D data;
> + char *address;
> + struct tm date;
> +
> + if (slist_find(param->list, key, (cmp_func_t) strcasecmp))
> + return;
> +
> + if (param->time){
> + strptime (value, "%Y-%m-%d %H:%M:%S %Z", &date);
> + if (difftime(mktime(&date), param->time) < 0)
> + return;
> + }
> +
> + address =3D strdup(key);
> + if (!address)
> + return;
> +
> + param->list =3D slist_append(param->list, address);
> +}
> +
> +static void remote_devices_do_append(void *data, void *user_data)
> +{
> + DBusMessageIter *iter =3D user_data;
> +
> + dbus_message_iter_append_basic(iter, DBUS_TYPE_STRING, &data);
> +}
> +
> +static DBusHandlerResult adapter_list_remote_devices(DBusConnection *con=
n, DBusMessage *msg, void *data)
> +{
> + struct adapter *adapter =3D data;
> + DBusMessageIter iter;
> + DBusMessageIter array_iter;
> + DBusMessage *reply;
> + char filename[PATH_MAX + 1];
> + struct remote_device_list_t param =3D {NULL, 0};
> +
> + if (!dbus_message_has_signature(msg, DBUS_TYPE_INVALID_AS_STRING))
> + return error_invalid_arguments(conn, msg);
> +
> + /* Add Bonded devices to the list */
> + create_name(filename, PATH_MAX, STORAGEDIR, adapter->address, "linkkeys=
");
> + textfile_foreach(filename, list_remote_devices_do_append, &param);
> +
> + /* Add Last Used devices to the list */
> + create_name(filename, PATH_MAX, STORAGEDIR, adapter->address, "lastused=
");
> + textfile_foreach(filename, list_remote_devices_do_append, &param);
> +
> + /* Add Last Seen devices to the list */
> + create_name(filename, PATH_MAX, STORAGEDIR, adapter->address, "lastseen=
");
> + textfile_foreach(filename, list_remote_devices_do_append, &param);
> +
> + reply =3D dbus_message_new_method_return(msg);
> +
> + dbus_message_iter_init_append(reply, &iter);
> +
> + dbus_message_iter_open_container(&iter, DBUS_TYPE_ARRAY,
> + DBUS_TYPE_STRING_AS_STRING, &array_iter);
> +
> + slist_foreach(param.list, remote_devices_do_append, &array_iter);
> +
> + slist_foreach(param.list, (slist_func_t)free, NULL);
> + slist_free(param.list);
> +
> + dbus_message_iter_close_container(&iter, &array_iter);
> +
> + return send_message_and_unref(conn, reply);
> +}
> +
> +static DBusHandlerResult adapter_list_recent_remote_devices(DBusConnecti=
on *conn, DBusMessage *msg, void *data)
> +{
> + struct adapter *adapter =3D data;
> + const char *string;
> + struct tm date;
> + DBusMessageIter iter;
> + DBusMessageIter array_iter;
> + DBusMessage *reply;
> + char filename[PATH_MAX + 1];
> + struct remote_device_list_t param =3D {NULL, 0};
> +
> + if (!dbus_message_get_args(msg, NULL,
> + DBUS_TYPE_STRING, &string,
> + DBUS_TYPE_INVALID))
> + return error_invalid_arguments(conn, msg);
> +
> + if (strptime (string, "%Y-%m-%d %H:%M:%S", &date) =3D=3D NULL)
> + return error_invalid_arguments(conn, msg);
> + param.time =3D mktime(&date);
> +
> + /* Add Bonded devices to the list */
> + create_name(filename, PATH_MAX, STORAGEDIR, adapter->address, "linkkeys=
");
> + textfile_foreach(filename, list_remote_devices_do_append, &param);
> +
> + /* Add Last Used devices to the list */
> + create_name(filename, PATH_MAX, STORAGEDIR, adapter->address, "lastused=
");
> + textfile_foreach(filename, list_remote_devices_do_append, &param);
> +
> + reply =3D dbus_message_new_method_return(msg);
> +
> + dbus_message_iter_init_append(reply, &iter);
> +
> + dbus_message_iter_open_container(&iter, DBUS_TYPE_ARRAY,
> + DBUS_TYPE_STRING_AS_STRING, &array_iter);
> +
> + slist_foreach(param.list, remote_devices_do_append, &array_iter);
> +
> + slist_foreach(param.list, (slist_func_t)free, NULL);
> + slist_free(param.list);
> +
> + dbus_message_iter_close_container(&iter, &array_iter);
> +
> + return send_message_and_unref(conn, reply);
> +}
> +
> const char *major_class_str(uint32_t class)
> {
> uint8_t index =3D (class >> 8) & 0x1F;
> @@ -2746,6 +2868,9 @@
> { "DiscoverDevicesWithoutNameResolving", adapter_discover_devices },
> { "CancelDiscovery", adapter_cancel_discovery },
> =

> + { "ListRemoteDevices", adapter_list_remote_devices },
> + { "ListRecentRemoteDevices", adapter_list_recent_remote_devices },
> +
> { NULL, NULL }
> };
> =

> diff -Naur hcid.orig/dbus-api.txt hcid.new/dbus-api.txt
> --- hcid.orig/dbus-api.txt 2006-10-20 18:56:14.000000000 +0200
> +++ hcid.new/dbus-api.txt 2006-10-20 18:58:33.000000000 +0200
> @@ -789,6 +789,20 @@
> org.bluez.Error.InProgress
> org.bluez.Error.Failed
> =

> + array{string} ListRemoteDevices()
> +
> + List device addresses of all known adapters (seen, used or bonded).
> +
> + Possible errors: none
> +
> + array{string} ListRecentRemoteDevices(string date)
> +
> + List device addresses of all used or bonded adapters since date.
> +
> + date format is "YYYY-MM-DD HH:MM:SS GMT"
> +
> + Possible errors: none
> +
> =

> Signals void ModeChanged(string mode)
> =

> =

> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job ea=
sier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=
=3D121642
> ------------------------------------------------------------------------
>
> _______________________________________________
> Bluez-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
> =


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easi=
er
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D1=
21642
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel