[Pkg-bluetooth-maintainers] bluez-utils_3.5-1 package

[Marcel Holtmann]

Hi Filippo,

> > And last, but not least, the Debian specific passkey thing must go away.
> > This is a Debian specific way and no other distribution is doing
> > something like this. It is total crap and will make the correct use of
> > the passkey agent interface from other applications impossible. You must
> > trust me here. You lack the understanding on how this is meant to work
> > and you are abusing it with the number of processes that you start and
> > it is not even gonna work as you think. The device specific agents will
> > timeout or get removed after its first use and the default passkey agent
> > will block applications like bt-applet. A passkey is meant to be started
> > by a user session and not system wide from an init script.
> 
> What to do if Xwindow is not available?
> Suppose you are in console and do an outgoing connection or pairing, what the
> passkey agent is supposed to do?
> 
> So let's see I if got it:
> - document somewhere that the user should start the (commandline, in this case) agent
> - the (commandline) agent will read passkeys from the user's $HOME
> can this be a viable solution for you?

the current passkey agent concept only allows one default passkey agent
and the first one simply wins. So in general that is bt-applet when you
login into your session. We still need to add support for fast user
switching and screensaver mode. However these two things don't concern
the hcid. It is only bt-applet specific.

If you wanna login into the console and play around with command line
tools, then you should know what you are doing. The best solution would
be to have a tool that can create the pairing with a remote device for
you. It can use a device specific passkey agent. So you call this first
and then you keep on working. Once you are paired hcid will take care of
the rest for you.

And as I mentioned you should keep passkey-agent.c in /usr/share/docs as
an example on how to write a passkey agent. Don't put it in the path or
elsewhere. It is not meant for daily use. It is an example.

It is better to break the console instead of breaking the GNOME support.
Personally, I would simply wait and see what happens. I am still waiting
for the KDE guys to come around with the passkey agent. And you can
still use the /var/lib/bluetooth/<bdaddr>/pincodes if you are in the
console and stuck.

Regards

Marcel