Hi Patrick,
On 02/21/2012 04:27 PM, Patrick Ohly wrote:
On Tue, 2012-02-21 at 15:45 +0100, Mikel Astiz wrote:
Hi Patrick,
On 02/21/2012 03:26 PM, Patrick Ohly wrote:
On Mon, 2012-01-30 at 08:57 +0100, Mikel Astiz wrote:
Any idea what might be necessary to get access to the phone book?
There's nothing in the phone's UI to enable it (Android 2.2, HTC
Sense).
You probably need to connect HFP first, otherwise some phones might
reject the PBAP session. If you're interested, I suggest you try oFono.
Just make sure you have "Enable=Gateway" in /etc/bluetooth/audio.conf
and then you can use ofono/test/enable-modem to connect HFP.
Into which section of /etc/bluetooth/audio.conf does the
"Enable=Gateway" belong? My copy of it (4.98-2, Debian testing) doesn't
have "Enable" anywhere and at first glance I have also not found any
documentation about the config files.
You would typically write it below the commented line
#Disable=Control,Source
As I said, you will at least need Enable=Gateway. This should expose the
org.bluez.HandsfreeGateway D-Bus interface for the paired device, which
you can either use directly or otherwise through oFono, with enable-modem.
I thought I had it there, but probably not. Anyway, now the interface is
there and enable-modem gets one step further.
Also, if you are using SSP (simple pairing), you might experience some
problems, like the phone rejecting the connection. That might come later
though.
Perhaps that's why it now fails:
Feb 21 16:11:52 pohly-mobl1 bluetoothd[30888]: connect(): Permission denied (13)
dbus.exceptions.DBusException: org.ofono.Error.Failed: Operation failed
How do check which kind of pairing is used? I re-paired via the GNOME
Bluetooth UI, it automatically suggested a PIN and asked whether the
device showed the same one.
Well, if you had to enter a pin code, then it's legacy pairing, which
works fine. If you just confirmed a pin code that was given, then it's
SSP, which is affected by a known bug in the kernel.
You can either (a) patch your kernel, (b) disable SSP, or (c) initiate
the connection from the phone. I suggest the last one since it is
straightforward.
Also note that you need a running BlueZ agent. You can use the
test/simple-agent script in BlueZ, which will probably ask for
confirmation when the phone tries to initiate the connection.
There must be something more fundamentally wrong with my device,
browsing or sending files also fails.
I came back to this as part of adapting the PBAP backend to recent
changes on the master branch. Code is in the pbap branch (not rebased,
just pull):
commit 46d7d344f3692c1ec539d5db54ff6944032ac936
Merge: c12cde0 f345038
Author: Patrick Ohly<[email protected]>
Date: Tue Feb 21 14:26:56 2012 +0100
PBAB: Merge branch 'master' into pbap + D-Bus method calls
The mechanism for making D-Bus method calls changed on the master
branch. The normal call operator now does a blocking method call,
which breaks code depending on the former non-blocking semantic.
All D-Bus methods calls in the PBAB backend are now blocking. This
allows removing all callback methods and the start/stop main loop
tricks. A lot easier to read and problems while executing the method
calls are now properly reported back to the user of the backend via
exceptions.
Beware, my changes are untested because I don't have PBAP access working
here at the moment.
I just pulled your changes, did some simple tests, and they seem to
work.
Good :-)
FYI, I plan to finish the multi-cycle next. But I keep getting
distracted and don't know when I'll be able to finish it. So if you need
something, please ping me.
Good to know. Please keep us informed then if you have any progress.
Cheers,
Mikel
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
