[Pkg-bluetooth-maintainers] Bug#488306: Bug#488306: bluez-utils: README.Debian.gz unusable. How to enter the PIN?

Fri Jun 27 22:07:50 UTC 2008

#include <hallo.h>
* Filippo Giunchedi [Fri, Jun 27 2008, 10:29:44PM]:

> > how do I enter the PIN during pairing? Your README.Debian.gz tells me
> > about a C file, that's all usefull information I can get from it. First,
> > are you REALLY EXPECT a user to compile this source? Second, how t.h. do
> > I tell and to whom about how to use the output of this compilation?
> 
> The compilation part comes from a discussion with upstream because the provided
> passkey-agent.c is just an example. Anyway, as of today to my knowledge there is
> no passkey agent for non-graphical environments. I'd like to work on one which
> reads a file with PIN specification from user home, I have to found the time
> yet.

IC, thanks in advance.

> > 
> > Honnestly, the current doc sucks. Please provide somethign I use can
> > start with. The comments "to the tech-savvy" are completely
> > inappropriate there -- please put your techy-user bashing to some foot
> > note, as a normal Joe user I don't care! Please gimme a hint on how to
> > proceed instead!
> > 
> > PS: in the meantime I managed that installing kbluetooth and then
> > starting one of the programs inside (don't remember which, but this also
> > MUST be documented) adds some magic tray icon which seems to appear
> > rarely asking me for the PIN (still works unreliable). This is NOT
> > SOMETHING I HAVE TO GUESS, I expect such essential details to be
> > documented at a prominent place.
> 
> The control files gives an hint about suggesting bluez-gnome | kdebluetooth,

The control fiels don't tell you much about the purpose. There are
enough maintainers using Suggests: to advertise bloated GUIs (and
mentioning gnome... and kde... together sounds like that), so I just
don't expect a cruicial requirement to be in that field.

And the main problem with the README.Debian.gz paragrah is that it's
hard to read without having background knowledge. But at the same time
$user needs to understand that because debugging at this point is not
very enjoyable. I mean, if I didn't know that there must be something
which sooner or later needs to get a password from me I would have no
clue about the reason for failing connection attempts. AFAICS NOTHING
ever appeared in the syslog and there were no STDERR messages like
"could not connect to PIN providing service, check the agent".

> plus it is explicitly stated that bluez-gnome provides the required passkey
> agent. I do agree that suggesting here kdebluetooth as well would be optimal.
> You might also want to help with the documentation as a first-hand user with
> experience about the pitfalls.

First, please drop dead links from README.Debian:

http://www.holtmann.org/linux/bluetooth/ (404)
http://www.bluez.org/documentation.html (redirects to main page, no docs
there).

Actually, second reading this part of README.Debian.gz explains a lot;
it's just too compressed.

I suggest expanding it a bit:

PIN (or passkey) management
---------------------------

Interaction with the local user can be required while BT connection is
being established (pairing process) and the PIN is not yet known or
needs to be changed. 

To retrieve the passkey (or PIN) from the user a service program (agent)
running in user's interactive session needs to be prepared and listen
for requests of the bluez daemons when pairing begins.

Examples of such programs are kblueplugd (kdebluetooth package) and
bluetooth-applet (bluez-gnome package). See Appendix A for other ways of
PIN submission.

Appendix A
----------

An example of a minimalistic passkey agent can be found in
/usr/share/doc/bluez-utils/examples/passkey-agent.c.gz (dbus development
files are required for the compilation).

Note to users of ancient versions: The old infrastructure
/etc/bluetooth/passkey has been removed since the agent is supposed to
be started by a user session. It is not meant to be system-wide. 

Note to the tech-savvy:
If you are stuck in console and absolutely need to pair with your
bluetooth device have a look at
/var/lib/bluetooth/<your_device_address>/pincodes.  Please note that
this mode of operation is _not_ _supported_.  The format is (one per
line): <remote_address><whitespace><pincode> Don't mess with files in
/var/lib/bluetooth/ unless you know what you are doing.
I repeat: manually adding a pincode for a remote device is NOT
SUPPORTED.

> > Second hurdle:
> > 
> > now I managed to get pairing working with the kde systray plugin
> > interaction. Fine. I enabled HID in /etc/default/bluetooth. Fine.
> > Right now I am typing with the keyboard. The Touchpad does not work,
> > this issue needs some investigation.
> 
> For the HID part it is an issue about the new upstream version using a different
> architecture with services as plugins and not separate processes. Anyhow I'm
> waiting to switch to the new architecture as it seems the new services do not
> provide the same set of feature as the old ones (yet at least, to be
> investigated further)

I don't know much about bluez development ATM.

> About the touchpad issue is it on the keyboard?

Actually "funny" things happen. Apparently the touchpad is a kind of
subdevice of the keyboard, i.e. it provides mouse capabilities according
to Xorg log. However it does not work, and (much worse) X
crashes every 10-60 minutes because some input device seems to be
disconnected (maybe a hidd problem, dunno).

I have seen similar crashes before, it happens when some input module suddenly
terminate which often happened after system hibernation/resume and
subsequential device file reopening trouble. That problems, however,
have almost been "solved" after I enabled the input device hotpluging
mode in recent Xorg packages (actually it was still crashing in one of
ten times in the last weeks).

Like I said, all that requires more investigation. ATM it looks more
like an Xorg problem.

> Final thought: I understand you might be frustrated because the thing didn't
> work the first time as expected, using a more constructive tone might help
> getting things fixed though.

Well, I have to say sorry. I just felt like returning back to those days
in 1990ies (with bloody driver instabilities in every corner, docs only
readable for geeks, no good ways to trace problems,
deprecated/misleading howtos everywhere, etc.).

Regards,
Eduard.

(**) PSTC Bluetooth Keyboard: always reports core events
(II) PSTC Bluetooth Keyboard: Found 2 absolute axes.
(II) PSTC Bluetooth Keyboard: Configuring as pointer.
(II) PSTC Bluetooth Keyboard: Found 3 relative axes.
(II) PSTC Bluetooth Keyboard: Configuring as pointer.
(EE) PSTC Bluetooth Keyboard: Unable to parse 'RelAxis 0' as a map specifier.
(EE) PSTC Bluetooth Keyboard: Unable to parse 'RelAxis 1' as a map specifier.
(**) PSTC Bluetooth Keyboard: Configuring 2 absolute axes.
(II) PSTC Bluetooth Keyboard: Checking button DIGI_STYLUS (74)
(II) PSTC Bluetooth Keyboard: Checking bit 330
(EE) PSTC Bluetooth Keyboard: AbsoluteTouch: 'DIGI_Touch' does not exist.
(II) PSTC Bluetooth Keyboard: Found 3 mouse buttons
(II) PSTC Bluetooth Keyboard: Configured 6 mouse buttons.
(**) Option "xkb_model" "evdev"
(**) Option "xkb_layout" "de"
(**) Option "xkb_variant" "nodeadkeys"
(II) XINPUT: Adding extended input device "PSTC Bluetooth Keyboard" (type: KEYBOARD)
(**) PSTC Bluetooth Keyboard: 2 valuators.
(**) PSTC Bluetooth Keyboard: Configuring in Absolute mode.
(**) PSTC Bluetooth Keyboard: Registering 6 buttons.
(II) PSTC Bluetooth Keyboard: Init
(II) PSTC Bluetooth Keyboard: On
(EE) Read error: No such device (19, -1 != 24)
(II) PSTC Bluetooth Keyboard: Off
(II) PSTC Bluetooth Keyboard: Off
(II) UnloadModule: "evdev"

Backtrace:
0: /usr/bin/X(xf86SigHandler+0x6a) [0x47588a]
1: /lib/libc.so.6 [0x7ff080a061d0]
2: /usr/bin/X(SwitchCoreKeyboard+0x15d) [0x45d93d]
3: /usr/bin/X(mieqProcessInputEvents+0x16d) [0x4d7f1d]
4: /usr/bin/X(ProcessInputEvents+0x1c) [0x47602c]
5: /usr/bin/X(Dispatch+0x260) [0x44e2e0]
6: /usr/bin/X(main+0x47d) [0x436b2d]
7: /lib/libc.so.6(__libc_start_main+0xf4) [0x7ff0809f31c4]
8: /usr/bin/X(FontFileCompleteXLFD+0x281) [0x435e69]