Thread (1 message) 1 message, 1 author, 2011-07-07

Re: Media API with more than one headset

From: Peter Kornatowski <hidden>
Date: 2011-07-07 19:57:09

Hi Luiz,

At 14:49 07.07.2011, Luiz Augusto von Dentz wrote:
Hi Peter,

On Thu, Jul 7, 2011 at 11:25 AM, Peter Kornatowski [off-list ref] wrote:
quoted
Hi Luiz,

At 22:35 06.07.2011, Luiz Augusto von Dentz wrote:
quoted
Hi Peter,

On Wed, Jul 6, 2011 at 10:54 PM, Peter Kornatowski [off-list ref] wrote:
quoted
I downloaded and checked the new bluez version 4.95. I'm wondering why
the
patch of Lukasz didn't get applied? As I wrote in my last e-mail, it
works
for not losing playing mode of all headsets when disconnecting just one.
I don't remember actually seeing a proper patch to the mailing list,
that might explain why it wasn't applied yet.
So Lukasz, could you make a proper patch out of it, cause it's your code?
quoted
quoted
Did someone of you had a chance to look into the other problems I wrote
about in my last e-mail? This would help me a lot.
Nope, I was actually waiting for more input since you mentioned this
only happened with some code your wrote.
The first problem I wrote about also occures with the 
simple-endpoint script
quoted
located in the test directory of bluez. You just have to add the "Acquire"
call to "SetConfiguration" to actually set the headset in playing mode. I
also posted the lines of code I added, so you can easily try to reproduce
it. The second problem just occurs with my code, that's right. 
But maybe you
quoted
have some general ideas. Otherwise I'll have to dig in by myself. But it
would be very helpful when you look at least into the first problem.
Your are probably is trying to Acquire the transport before
SetConfiguration completes so that will return an error since the
configuration is not accepted yet by the endpoint. If that is causing
a crash than it needs to be fixed, otherwise you basically need to
reply to SetConfiguration before trying to Acquire the transport.
I'm calling Acquire when SetConfiguration is called by bluez (isn't 
that the correct spot, cause there you get the transport path?). I 
attached the whole modified script, so you can see exactly what I'm doing.
It also works for the first headset or if all headsets are in 
connected mode and you start the script, so generally it should be ok.
But it doesn't work if you start the script and then connect the 
first headset (or start the script after just one headset is in 
connected mode). Then the headset gets into playing mode, but bluez 
tries to put it into playing mode on the other endpoint, too (at 
least it looks that way to me cause SetConfiguration is being called 
twice). So then Acquire is being called twice, too. For one call I 
get the file descriptor, but for the other call I get "Operation Not 
Authorized". Maybe because the second SetConfiguration is called for 
the other endpoint, which is on the other adapter with which the 
headset is not paired (each headset is only paired with one adapter). 
On the other hand, the transport path from both SetConfiguration 
calls is for the same adapter... But when you then connect the second 
headset (which is paired with the other adapter), bluez doesn't call 
SetConfiguration for it (probably because this endpoint is still 
"blocked" by the first headset, but it shouldn't be).
Additionally, when you try to end the script with ctrl+c now, 
bluetoothd segfaults with: segfault at 3c ip b75359d5 sp bfd25c10 
error 4 in libdbus-1.so.3.5.7[b7521000+48000]
I tried the whole use case as user and as root, but no difference. I 
also attached the syslog output (bluetoothd started with -d).

--
Luiz Augusto von Dentz
--
Thanks,
Peter

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help