Hi Peter, On Thu, Jul 7, 2011 at 10:57 PM, Peter Kornatowski <pkorn@xxxxxxx> wrote: > 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. As I explained in the last email you have to reply to the SetConfiguration before you are able to do Acquire, that is on purpose to avoid a possible deadlock where you are the application is waiting for Acquire to complete but bluetoothd is waiting the application to reply to SetConfiguration, bluetoothd won't block but the application may block trying to Acquire and by doing that it is not able to reply to SetConfiguration. > 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). The Operation Not Authorized in because you didn't reply to SetConfiguration, also bluetoothd will try to match the profile capabilities with the endpoint capabilities and then call SetConfiguration to the endpoint to confirm if it is able to handle the transport, in theory I don't see any problem to the same endpoint to get multiple SetConfiguration as long it is for different devices, but perhaps we need to limit to only one transport per endpoint which is usually the case for a2dp since the sep has the in_use flag. > 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). The syslog doesn't seems to indicate any crashes, did you left it out? Btw, to get more information about the crash please run bluetooth with valgrind e.g: sudo G_SLICE=always-malloc G_DEBUG=gc-friendly,resident-module valgrind --trace-children=yes ./bluetoothd -dn -- Luiz Augusto von Dentz -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
