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 thesimple-endpoint scriptquoted
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 youquoted
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
- connect_first_headset.syslog [application/octet-stream] 11802 bytes
- simple-endpoint-dual [application/octet-stream] 2734 bytes