Linux bluetooth development
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: BlueZ development <bluez-devel@lists.sourceforge.net>
Subject: Re: [Bluez-devel] Addition for hcid passkey dbus request
Date: Tue, 01 Aug 2006 00:15:15 +0200	[thread overview]
Message-ID: <1154384115.4982.30.camel@aeonflux.holtmann.net> (raw)
In-Reply-To: <20060731181105.GI29916@suse.de>

Hi Stefan,

> > I planned to register kbluetoothd as default passkey agent and listen for all 
> > passkey request. Have to recjet this and think about a new solution. I am 
> 
> I believe that you still can do this.
> 
> > confused now, how to achieve that the pin dialog now can detect if it is the 
> > initiator side. When another application triggers the pairing without calling 
> > CreateBonding().
> 
> Well, improve kbluetoothd in a way, that it is just way more convenient
> to pair devices by using it than with any other application :-)
> Once you know that you initiated the pairing, you can pre-fill the pin
> field with a generated value.
> 
> Basically, i think we do not want many applications doing the pairing
> stuff, there should be one application (per desktop environment...), that
> handles this stuff well in a centralized place. For KDE, this could be
> kbluetoothd (or maybe a control-center plugin, which could then communicate
> with kbluetoothd). This probably give the best user experience.

don't try to over-engineer this. We thought about all this stuff
already. You can make kbluetoothd the default passkey agent and then you
can register a device specific passkey agent. This stuff is stacked and
hcid will first look for a device specific agent before calling the
default agent.

So you need a default passkey agent that will be always available (take
care of D-Bus disconnects btw.) and it has to handle unexpected pairing
requests. In the case you connect to a phone and you want to pair (in
somekind of connection wizard), then you register a device specific
passkey agent and call CreateBonding(). It is that simple.

If something is actually not working as expect or documented in
dbus-api.txt then this might be simply a bug. The current D-Bus API for
BlueZ should be enough to handle all basic tasks. We thought really
careful about all methods and signals that are needed. However we might
have missed something, but you need a good argument to convince me that
something additional is needed.

Regards

Marcel



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

  reply	other threads:[~2006-07-31 22:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-31 13:18 [Bluez-devel] Addition for hcid passkey dbus request Daniel Gollub
2006-07-31 13:26 ` Johan Hedberg
2006-07-31 18:11   ` Marcel Holtmann
2006-07-31 16:50     ` Daniel Gollub
2006-07-31 19:17       ` Marcel Holtmann
2006-07-31 18:07         ` Daniel Gollub
2006-07-31 18:11           ` Stefan Seyfried
2006-07-31 22:15             ` Marcel Holtmann [this message]
2006-07-31 22:21           ` 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=1154384115.4982.30.camel@aeonflux.holtmann.net \
    --to=marcel@holtmann.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