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 <pkorn@xxxxxxx> wrote: > Hi Luiz, > > At 22:35 06.07.2011, Luiz Augusto von Dentz wrote: >> >> Hi Peter, >> >> On Wed, Jul 6, 2011 at 10:54 PM, Peter Kornatowski <pkorn@xxxxxxx> wrote: >> > 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? > >> > 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> 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> 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
Attachment:
connect_first_headset.syslog
Description: Binary data
Attachment:
simple-endpoint-dual
Description: Binary data
