No GTA03 in 2009 :(

2-3 back came a sad and shocking news (atleast to me) that Openmoko has sacked/let go of 50% of its work force and has ceased all developments for GTA03. Furthermore Openmoko has stopped funding FSO. Both of which were grim developments to hear.

On a brighter note, FSO has started work on the Vala/C implemention of the reference Python implementation named cornucopia, which mainly aims at the general defragmentation of all the middleware code out there for handheld devices. Whats more, the first subsystem to be ported to this new codebase will be odeviced, which happened to be my project for the Google Summer of Code 2008.

For more, check this recent blog entry by Mickey.

Patches all the way …

Summer ends but the insanity continues.

In Chennai we have three seasons, summer (nov-march), f***ing hot summer (april – june), a mildly wet but still hot summer (july-oct). In case you are wondering where I am pointlessly heading to, I was talking about the Google Summer of Code 2008 which ended successfully for me ; the code which I submitted was only about 56KB which means I was the laziest among the 9 other GSoC’ers for Openmoko. On the whole, I think Openmoko had a wonderful SoC this year.

I will continue working on the freesmartphone.org initiative and do my little bit to help around. I was planning to release the ipks along with FSO milestone 3, but it turned out that my build tree wouldn’t let me to do that without a fight (at `NOTE: Running task 256 of 718′ now), will post the link once I have the packages. Get it here. (Thanks to mukt.in team for hosting it)

Meanwhile, Software Freedom Day will be celebrated worldwide on September 20 (third saturday of September) and the ILUG-C gang will be there at Kamban Engineering College, Thiruvannamalai this year. So if you are in Chennai at that time and want to do something fun for the weekend, please volunteer!.

P.S: I am planning to give away my Freerunner for free, first to comment this post gets it..

..NOT!

odeviced: Accelerometers, PowerControl, IdleNotifiers and Input plugins

Phew. GSoC 2008 program is going to end in a couple of days and boy, did I have fun. Most of the code for the second phase was actually pushed last week. Anyway, here are the updates.

• Accelerometer plugin for Freerunner. Now you can use odeviced to retrieve accelerometer values for the position of the device along the x,y,z axes.
• Completed Powercontrol plugin. Kept putting this off, but got myself to complete it today.
• IdleNotifiers enabling apps to keep track of the state of the device viz. IDLE, BUSY…etc
• Input plugin for signalling input events on DBus. Like button presses, etc. Should make this asynchrounous once vala offers support for async DBus on the server side (‘read’ systemcall can block)
• Initial Audio plugin, am keeping this as a TODO outside GSoC.

The daemon is far from complete and GSoC was meant to be just the beginning to get the basics right. Integration of odeviced as a subsytem of a frameworkd implementation (theres already a python implementation) in C is something I am looking forward to contribute in the next few months. It would be uber cool, if someone lends a helping hand for now to make odeviced work on other devices on which openmoko (and FSO) can run.

I am not sure if people will find this interesting, but still

• The plugins average around 14kB in size, with powercontrol being the biggest of all. (25KB)
• The main odeviced binary is around 26KB, which IMO, is quite teency weency.

(But given the fact that the code links against GLib and DBus, I have no idea if these numbers mean anything at all. I would be grateful if anyone thinks this is something to cheer about)

P.S: I am looking for a temporary place to host the ipks for the lazy ones, will post the link once I get that. Meanwhile, get the code here.

Woot..Passed the mid-term evals

After a week’s waiting my mentor informed me that I had passed the mid-term evaluations. (he said that my performance for the first phase exceeded his expectations. ).

Its been a long time since I actually blogged about the progress. After I got the Freerunner in my hand (muhuhahahaa), it was more fun since there were subtle changes in the way the code ran on the device. Tracking down segfaults was uber awesome.

Plugins are now written *entirely* in vala. Earlier, this used to be an ugly abomination of hand-written and vala generated C code. Now, where good ol’ C is necessary, .vapis’ have been added that wrap around code written in C.

Additionally plugins for rtc, input and led were added. Input plugin is incomplete though. The code isn’t perfect yet, so need to refine them and make them a bit tight in some places. rtc and led especially needs some tweaks.

I guess most of the second phase will be spent on syncing with frameworkd. Now, the python device daemons have been integrated into a single daemon with odeviced as one of the subsytems. (Earlier this was separate). The python daemon is uber-cool by itself, but imagine a C implementation of the entire frameworkd. Light on resources and excellent in performance, if done right.

Git repository here.

Finally, The Freerunner is here..

Wow, DHL dudes are fast. They took just 4 days to ship the device considering there was a sunday in-between. Thanks to Daniel for sending the devices to the SoC’ers.

I don’t have a dedicated camera, so pics are a bit sucky

(Evil maniacal laughter) Here are the pics…muhuhahaha

odeviced: More sysfs abuse (Screenshot attached! :P)

A few days gone by, and endless wrestling with git wherein I was not able to push code. Turned out, I was using the wrong URL to push ..doh!

But anyway, the code is beginning to stabilise a bit (Read no unexpected segfaults, only expected ones..). The last few days were spent in changing the method names in accordance with OTAPI naming conventions after my mentor went through my code.

There is also another important change. The sysfs nodes for backlight and power plugins were hardcoded in their configuration files. So, I came up with some helpers that creates DBus paths automatically based on the device class which they belong to. Here’s a picture of today’s code in action,

Notice the d-feet DBus debugger towards the lower left? It shows all the automatically created DBus object paths based on the device class which the plugin stands for. And the terminal to the right shows some debug messages. Note how odeviced spits out the current battery status viz. “Charging, Discharging”. The corresponding “battery-status-changed” DBus signal is emitted as well (along with “low-battery-warning” signal which *ahem* is emitted when battery is low).

For more follow this thread..

I got a job at Google *glee* (honest)

I am pretty sure my friends would go “WTF, you are too dumb for Goog” by now.

Guess what, I am a full time employee of Google now!. (*ahem* for three months).

I was more of an impression that I was technically an intern for three months. But after reading Aju’s post, it turns out all Summer of Code students are technically full time employees. (Anyone thinking otherwise please comment).

This means I get uber bragging rights.

What happens after 3 months when I am jobless again?

Simple. Just tell everyone “I quit” because they refused to send me another t-shirt.

Speaking of GSoC, the progress report of my project can be found here. For some strange reason I was not able to push code to the git repository. Find today’s snapshot here.

Battery Plugin and more..

After a little chat with mickeyl, I realised that exposing crucial functions like load() and unload() was not that of a good idea considering how odeviced is supposed to closely interact with the underlying devices. Consequently there has been some changes over the last week,

• No DBus interface for the service.
• Plugins have now access to a set of helper functions. Only two at the moment (Think setting up DBus object paths)
• Plugins once loaded become resident, that is they cannot be unloaded. If plugins are to be disabled during startup, just remove them from the “enable” field in the global configuration file.
• Per plugin configuration. Each plugins now have their own configuration. Makes more sense, since this mean plugins can have greater freedom with their settings. I really like how the newly checked in battery plugin exploits this.
• Freshly checked in battery plugin. Makes use of sysfs for its functions viz. get_current_brightness, set_brightness, get_maximum_brightness.

SysFS (/sys in 2.6.x.x) is sort of similar to the /proc filesystem and acts as an interface for user-space applications to control/access various devices. One of the neat things about sysfs is the fact that all files consist of only a single entry. This means I don’t have to write a separate parser to extract data from them. So a simple fprintf or fscanf or even the seemingly mundane “echo” can be used to control the devices.

I am also planning to work on the python shell for odeviced for a while. This will be really convenient for testing the service. Something like this,

> Wifi is_on wlan0
True


The code can be checked out from here. I can’t wait till I get hold of a FreeRunner to test odeviced out.

The code is in…

Yay. Got the repository for odeviced set up at http://git.freesmartphone.org

Boy, do I love git.

First frigging milestone..

Why Milestone? Nope, I didn’t come up with fancy code or a “beautiful” one for that matter (Came up with a way to unload plugins). Milestone, because today was the first day I was squeezing up my half empty head to work around a teency weency problem. In short, I am happy I was actually thinking today about squishing a segmentation fault which was bringing the whole house down due to dbus and the kinky wifi plugin.

Now a word of warning. The wifi plugin is a circus freak of sorts. Being the lazy bum I am, I found it a drag to manually get into the trouble of coming up with xml introspection data for the “org.freesmartphone.Device.plugins.wifi” interface.

Instead I just came up with a grand plan of letting valac generate wifi.c and wifi.h, which I could modify later. Piece of cake? Sure…

After the wifi plugin is loaded it works pretty well. The keyword being “After”…By the way, check the progress report which I sent to the smartphone-standards list. That should give you an idea of how odeviced works and looks like. In fact, it works pretty satisfactorily discounting the segmentation faults  , which is easily reproducible in the following ways,

• Don’t load the wifi plugin on startup, set enable=0 in odeviced.conf. Instead load it manually after odeviced starts up and begins to idle.
• If the wifi plugin is already loaded, unload it and then try to load it again.

Part of this problem might be my arrogance of not to use GTypeModules for dynamically typing the plugins. I need to discuss with my mentor, mickeyl about this once he gets back to business after LinuxTag.

The barely bare bones powercontrol plugin loads and unloads without any problems, but it doesn’t do anything as remotely useful as the wifi plugin!! Just contains an init function that has a printf in it (bleh!, thank goodness it didn’t bail out).

Oh and the all important tarball is here. Highly effective than laughing gas!

…Another gdb session beckons