public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: Matthew Garrett <mjg59@srcf.ucam.org>
To: BlueZ development <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] DBus interface - determining whether	a	device	exists
Date: Thu, 17 Aug 2006 13:25:59 +0100	[thread overview]
Message-ID: <20060817122559.GA6422@srcf.ucam.org> (raw)
In-Reply-To: <1155823499.4075.157.camel@aeonflux.holtmann.net>

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 | mjg59@srcf.ucam.org

-------------------------------------------------------------------------
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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

  reply	other threads:[~2006-08-17 12:25 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-16 15:34 [Bluez-devel] DBus interface - determining whether a device exists Matthew Garrett
2006-08-16 20:41 ` [Bluez-devel] [PATCH] - add ConnectRemoteDevice method to dbus Matthew Garrett
2006-08-16 23:13   ` Marcel Holtmann
2006-08-16 23:16 ` [Bluez-devel] DBus interface - determining whether a device exists Marcel Holtmann
2006-08-16 21:46   ` Matthew Garrett
2006-08-17  1:21     ` Cezar Sá Espinola
2006-08-17  8:15       ` Matthew Garrett
2006-08-17 12:57         ` Marcel Holtmann
2006-08-17 11:22           ` Matthew Garrett
2006-08-17 13:51             ` Marcel Holtmann
2006-08-17 12:56     ` Marcel Holtmann
2006-08-17 11:35       ` Matthew Garrett
2006-08-17 14:04         ` Marcel Holtmann
2006-08-17 12:25           ` Matthew Garrett [this message]
2006-08-17 12:45             ` Johan Hedberg
2006-08-17 12:52               ` Matthew Garrett
2006-08-17 13:01                 ` Johan Hedberg
2006-08-17 13:03               ` Bastien Nocera
2006-08-17 18:36                 ` Marcel Holtmann
2006-08-18 12:29                   ` Frederic Danis
2006-08-18 18:06                     ` Marcel Holtmann
2006-10-18 13:37                       ` Frederic Danis
2006-10-18 14:03                         ` Johan Hedberg
2006-10-20 17:07                           ` Frederic Danis
2006-10-20 17:08                           ` Frederic Danis
2006-11-07 17:28                             ` Frederic Danis
2006-11-10  8:12                               ` Johan Hedberg
2006-11-10 16:40                                 ` Marcel Holtmann
2006-11-10 16:39                                   ` Frederic Danis
2006-11-10 19:04                                     ` Johan Hedberg
2006-08-17 18:44             ` Marcel Holtmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060817122559.GA6422@srcf.ucam.org \
    --to=mjg59@srcf.ucam.org \
    --cc=bluez-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox