On 02/02/2010 01:09 AM, João Paulo Rechi Vita wrote:
2010/1/29 João Paulo Rechi Vita<jprvita(a)gmail.com>:
> Hi all,
> I'm trying to add support for the Handsfree Gateway role Gustavo just added
> to BlueZ and oFono. The BlueZ patches can be found on  and  and the
> oFono part was just merged upstream.
> But when it comes to integrate them with Pulse, I'm getting a POLLHUP when
> trying to write on the fd. Also, it seems different gateways have different
> behaviours regarding when they connect the SCO link. Some phone connect
> them just after the RFCOMM link (some Nokia phones), when there is no call
> going on yet, and others just when a call is started (Android 1.5).
> Also, right now the same property (State) is beeing used to refer when the
> RFCOOM link is established (State=Connected) and when the SCO link is
> established (State=Playing). Shouldn't this be handled by separate props?
> And last but not least, is the new Media API intended to handle the audio
> part of handsfree gateways too? If so, maybe we should use all this work
> as a prototype for latter integration with the new API.
> Any help on testing and getting this working together or comments on the
> topic would be appreciated.
>  http://www.spinics.net/lists/linux-bluetooth/msg04250.html
>  http://www.spinics.net/lists/linux-bluetooth/msg04251.html
> João Paulo Rechi Vita
Just updating, this patch actually worked when testing with a
different adapter (Fujitsu-Siemens CSR-based). The adapter causing
problems was a Broadcom 2.1, the internal adapter of a Dell Mini10.
Also, suspending the source / sink actually doesn't interfere.
I did a small video of the whole stuff: http://www.vimeo.com/907879
Good work! Looks like it works pretty fine. :-). At the last of video, I
saw you load loopback module manually. Zheng Huan made a patch to load
loopback automatically. I believe Padovan has a copy of that. You may
also integrate it with upstream.
There are still some problems when testing against Nokia N900 and
2660. After the "enable-modem" step, the RFCOMM link is connected and
the SCO just after that, leading module-bluetooth-discover to load
module-bluetooth-device. Sometimes after that the polling on the
stream fd get a POLLHUP and the module-bluetooth-device unloads
itself. Other times the POLLHUP doesn't happen and the remaining steps
go without any problem.
Ideas on how to improve this scenario will be very helpful.
AFAK, the SCO connection request is from AG side and BlueZ will check if
no SCO stream comes from AG(??), it will shutdown the connection. In my
memory, I don't get POLLHUP event in my original patch. You can turn on
debug flag to see more BlueZ output.