Last Wednesday (March 3rd) we did a talk about Google Summer of Code at Unicamp. The talk was part of the weekly talk about Free Software in the University. It was presented by mentors and students from past GSoCs. We explained how GSoC works and how one can take part on it this year. I’ll post here some photos:
I’m proud to announce that BlueZ and oFono now support the Handsfree role of the Bluetooth Handsfree profile. This means that your Desktop now can now act like a headset bluetooth and handle calls from your cell phone. The work was done during the last 2 months here at ProFUSION.
On the BlueZ side a new API was designed using the fd-passing feature of DBus 1.3. This new API uses the concept of Agents where oFono plays the Agent role. In the HFP case the Agent role is to handle the AT engine stuff while BlueZ will only take care of the RFCOMM and SCO connections.
The RFCOMM socket is passed to the Agent in oFono via DBus, then oFono uses it to send and receive the AT commands to establish a Service Level Connection, i. e., make the handshake procedure. If it succeeds oFono will be ready to make and answers calls. Your HFP enabled phone will show up as a modem in oFono, like any other oFono modem.
The work was initially based on patches from Zhenhua Zhang(from Intel) and the audio interaction to handle the SCO data inside Pulseaudio was done by João Paulo Rechi Vita(from ProFUSION too). He also did the demo video below.
After pairing the devices using some BlueZ agent like kbluetooth or gnome-bluetooth, you’ll be able to see the modem in oFono and you can enable it ( i. e., make the handshake procedure to establish an HFP Service Level Connection) using the enable-modem script from the test directory on oFono source.
In order to test this you need the Audio Gateway interface enabled in BlueZ. For that, edit your /etc/bluetooth/audio.conf and add “Enable=Gateway” to it.
HFP code is already merged upstream on the BlueZ and oFono trees. The API is described in doc/hfp-api.txt in BlueZ source.
After a while with a BlueZ 4.39 ebuid Gentoo has updated today to the version 4.60 (the lastest one). It took a lot of work from me and others gentoo guys, especially Pacho Ramos. Thanks to all.
By adding this ebuild we were able to close other 4 bugs into the Gentoo bugzilla, but we still have bugs. Just search for bluez or bluetooth on the Gentoo Bugzilla and help us to fix Bluetooth on Gentoo.
Update your portage tree and try the new BlueZ ebuild. And if you find any issue, please file a bug into Gentoo Bugzilla. :-)
A prova de existência da inteligência artificial:
[03:55] –> obvio172 has joined this channel
[03:56] <obvio172> lopanbot: eh ou nao eh?
[03:56] <lopanbot> eh!
[03:57] *** padovan[AWAY] is now known as padovan.
[03:57] <padovan> eh ou nao eh?
[03:58] <padovan> lopanbot: eh ou nao eh?
[03:58] <lopanbot> eh!
Google Open Source team has just published yesterday a set of stats[1] about Google Summer of Code 2009 and Google Summer of Code during the years. The good news is that University of Campinas (Unicamp) is on the second place in number of accepted students to GSoC 2009, with 12 projects. We also are the second place in the history of the program with 37 projects. Congratulations to all guys from University of Campinas that take part on GSoC. We’ve been done a great job. Unicamp rocks! :-)
[1] http://google-opensource.blogspot.com/2009/09/tasty-new-google-summer-of-code-stats.html
Since the last post here (it was a long time ago :-) too much work was done, but ERTM isn’t fully implemented yet. So, what did I do last month?
I’ll explain each of the features I implemented on the next paragraphs, but if this are boring for you just take a look at the roadmap at the end of this post.
First I did the support to send and receive I-frames (the data frames) and created the support to RR S-frames to acknowledge the received I-frames. It first worked with a txWindow=1 (which means only one packet can be send without receive acknowledge from the receiver side). The next step was support a txWindow up to 63 (the maximum value specified). To bring this support I have been using sk_buff lists from the net core implementation.
Support for Segmentation and Reassembly(SAR) of L2CAP SDUs: this feature allows upper applications to use a buffer greater than the L2CAP size packet. The buffer is break down in many packet on the transmitter side and then reassembled on the receiver side and pushed to the upper layer.
REJ frame exception: When a packet is lost we need to start the recoveries procedures. BlueZ won’t support raise of REJ exception (we support only raise of SREJ exception by now, spec says that we can choose one of them). But we need to support the receipt of a REJ-exception (i.e. receive a REJ frame). On the receipt of a REJ frame the L2CAP entity needs to stop the transmission and starts to retransmit the requested packets. A REJ frame tells the ReqSeq(packet id sequence) and all packets up to ReqSeq – 1 shall be considered acknowledged, the others shall be retransmitted.
SREJ frame exception: BlueZ starts a SREJ exception when it detects lost packets. It sets its state to SREJ_SENT(It means that L2CAP entity is under recovery proccess) and sends a SREJ S-frame for each lost packets. The transmitter side shall resend the packets requested in the SREJ frames without stops transmission of new frames. SREJ exception saves retransmission of unneeded frames.
Retransmission And Monitor Timers: The Retransmission Timer shall be (re)started each time we send a I-frame. If it expires we send a RR-frame and start the Monitor Timer. The other side should response the RR frame immediately, if the the other side do not response and the Monitor Timer expires we resend the RR frame. A maximum value for the of Monitor Timer’s timeouts can be defined. If a L2CAP entity exceeds this value the channel shall be disconnected.
Busy condition on the remote side: If the remote side enters in a busy condition it will send a RNR frame. So, when the local side receives this frame it should mark the remote busy flag as true and stop the transmission of packets. It restarts the sending of packets only when the remote sides send a REJ, SREJ or RR frame. This says the remote busy condition was cleared.
Streaming mode: This mode of operation is useful to the Bluetooth Streaming Profiles such as A2DP and VDP(not yet implemented). It can take advantages of the Segmentation and Reassembly features.
FCS Option: It is a crc16 check for L2CAP packets. It is the default if both sides support it. If a L2CAP entity receives a packet with a broken crc16 it will drop. The receive procedure will miss it and start the recovery procedure.
Roadmap updated:
Now I’m working the busy condition exception and the support for the ERTM duplex channel. Today, just one side can send data packets. Then I’ll put ERTM as default when SOCK_STREAM is selected. I expect finish these issues on the coming weeks. After, I’ll spend my time fixing the bugs I find trough the code.
ps: Sorry for my too not bad English ;-)
I spent the last weeks work on my Google Summer of Code project. Code for items 1, 2 and 3 of the roadmap that I posted here[1] 3 week ago is almost done and in process to be merged into bluetooth-testing. Now I’m starting to work on item 4. First I’ll will look to support REJ S-frames and implement retransmission of L2CAP packets.
[1] http://padovan.org/blog/2009/07/bluez-first-patch-was-merged/
I was looking for a pastebin plugin for vim. I’ve found one[1], but it was not working, then I fixed it. The plugin is here[2]. And if is useful to you there is a git repo[3] too.
How to use:
Put it into ~/.vim/plugin to autoload the plugin every time you open VIM. You can also source it manually:
:source /path/to/pastebin.vim
You can set your favorite pastebin site and your name editing the pastebin.vim
From [1]: “To use the script is very simple. Just visually block (Shift-v) the lines of code you want to send to the Pastebin and enter the command :PasteCode. The blocked text will be sent to the Pastebin and the new URL will be shown on the Vim statusline.”
[1] http://djcraven5.blogspot.com/2006/10/vimpastebin-post-to-pastebin-from.html
[2] http://www.las.ic.unicamp.br/~gustavo/pub/vim/vim-pastebin/plugin/pastebin.vim
[3] http://github.com/pao/vim-pastebin/tree/master
I spent the last days studying how Enhanced Retransmission Mode(ERTM) should be implemented on L2CAP. Marcel recommended me to look at TCP[0] code. ERTM on L2CAP is very similar to TCP. Both have retransmission support, recovery error, acknowledgment of packets and timers.
That means that ERTM implementation will look like TCP implementation[1] on Linux. So, there is no need to write ERTM from scratch, I’ve already started to code and I’m basing my code on TCP code to get started with ERTM.
[0] http://en.wikipedia.org/wiki/Transmission_Control_Protocol
[1] http://vger.kernel.org/~davem/tcp_output.html
The first patch, that add support to L2CAP Enhanced Retransmission, was merged into bluetooth-testing yesterday. The patch adds support to configure L2CAP connections in Enhanced Retransmission(ERTM) and Streaming Modes besides the Basic Mode. Streaming Mode will not be implemented now, but it’s better make all configuration code for the 3 modes instead only ERTM and Basic Mode. This way we don’t need to touch twice into configuration code. The commit is here and that is the commit message:
Bluetooth: Add configuration support for ERTM and Streaming mode
Add support to config_req and config_rsp to configure ERTM and Streaming
mode. If the remote device specifies ERTM or Streaming mode, then the
same mode is proposed. Otherwise ERTM or Basic mode is used. And in case
of a state 2 device, the remote device should propose the same mode. If
not, then the channel gets disconnected.Signed-off-by: Gustavo F. Padovan <gustavo@las.ic.unicamp.br>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Now I’m going to implement support to send and receive I-frames and S-frames. Some part of the code for that . First I’m going to add support to transmissions with txWindow = 1 (i.e., only one packet can be sent per time without acknowledgment from the other side) and no retransmission support and I intend to finish it during this week.
Here is a quick roadmap for my work:
I expect that until end of August finish all this topics. So, let’s hack. =)
