Tag: maemo

Aura

In the last weeks Miguel, Calvaris and myself, developed an application for the N9/N950 mobile phone and we called it Aura.

Basically it uses the device’s camera (either the main one or the frontal one) for video recording, as a normal camera application, but also it exposes a set of effects that can be applied, in real time, to the video stream.

For example, here is a video using the historical effect:

Aura is inspired in the Gnome application, Cheese, and it uses many of the effects available in Gnome Video Effects.

The list of effects that were possible to port to the N9/N950 are: dice, edge, flip, historical, hulk, mauve, noir/blanc, optical illusion, quark, radioactive, waveform, ripple, saturation, shagadelic, kung-fu, vertigo and warp.

Besides of these software effects, it is possible to add, simultaneously, another set of effects that the hardware is capable, such as sepia colors. These hardware capabilities do not impose extra processing as the software effects do.

Because of this processing cost, imposed by the non-hardware video effects, Aura has a fixed video resolution. Otherwise the performance would make the application unusable. Also, we had a missing feature: the still image capture. But, hey! there is good news: Aura is fully open source, you can checkout the code at github and we happily accept patches.

Honoring Cheese, the name of Aura is taken from a kind of Finnish blue cheese.

We hope you enjoy this application as we enjoyed developing it.

Moving out apt metadata

As some of you may know, in the N900, the root file system is stored in a OneNAND chip with 256M of space. Meanwhile /home and /home/user/MyDocs are in a eMMC in two different partitions: ~2GB (ext2) for /home and ~29GB (vfat) for /home/user/MyDocs.

The OneNAND is faster than the eMMC, and it’s intended to host only the Maemo main system, moving out the third party applications to the eMMC. Though, this new layout has brought new limitations, the more visible one is the /opt problem [2].

One of the debates about what left and what not in the OneNAND is the apt’s database and metadata. Moving out the apt’s database out from the OneNAND to the eMMC, in my personal opinion, is very risky: It will slow down the database processing (which is already slow given the size of the Fremantle repositories), and if the eMMC gets corrupted, the base system wouldn’t be upgreadable either, because apt couldn’t read its database. And that’s why I’m against the proposal.

Nevertheless I’m aware that the apt’s metadata and database could be huge, consuming much of the precious OpenNAND storing space. Just to mention it,  I’ve found myself, in my development cycles, moving out those files.

That’s why I cooked this script: move-apt-dirs.sh

WARNING: this script is not official. You’re at your own if you run it: no promises, no guaranties.

shinning new HAM

A new version HAM will hit the streets soon, and we, the HAM team, are very proud of all the effort done.

There have been 178 commits since the first public release in the HAM repository, all of them affording user experience and trying to cover several corner cases on the SSU realm, specially dealing with reduced disk space in the OneNAND.

New section view in HAM
New section view in HAM

There are several new features and some eye candy:

  1. The section view has been improved greatly GtkIconView instead of the old buttons grid.
  2. Several user interaction (work flows and dialogs appearance) optimizations.
  3. Keep the cursor position in the package lists among operations.
  4. Add live search support, dropping the old search dialog.
  5. Avoid the update icon blink when the screen is blank, saving power
  6. maemo-confirm-text can show the package name who launched it.
  7. Minor fixes in logic strings and text display.
  8. Speed up the HAM launching loading the back-end using a lazy strategy.
  9. Speed up the package list processing in the back-end, so the package list are shown more quickly in the UI.

For the packagers there are also some bits:

  1. Adapt the .install files in order to interact with the packaged catalogs.
  2. Initial support for OVI store packages.
  3. Add a dbus function to search packages so other applications can interact with HAM.

And for the SSU, specially handling the reduced space disk in the root file system:

  1. Use always the eMMC for downloaded packages, avoiding the rootfs even as fallback.
  2. Stop as much process as possible when going into the SSU (stop prestarted apps, camera-ui, browser, rtcom-messaging-ui, alarmd, etc.) in order to reduce the double mappings of large files.
  3. Go into rescue mode if the SSU fails and change its looks to a less scary one.
  4. Sync the disk before fetching it status, moving the operation to the back-end.
  5. Because the documentation use a lot of disk space, we hack a way to get rid of it during the SSU.
  6. Use the higher disk compression during the SSU

Special thanks to Lokesh, David Kedves, Mario, Marius, Gabriel,  and all whom patient had helped us to make HAM a better piece of software to Fremantle users.

The SSU nightmare

In the Maemo domain, there’s a concept called SSU, Seamless Software Updates, which is the mean to update the whole operative system without reflashing the device.

This concept is relatively new in the mobile device domain, where reflashing has been the common upgrade path. But this idea is as old as GNU/Linux distributions.

Maemo uses the Debian format packages and dpkg /APT for their handling.

Meanwhile in Debian we are used to the dist-upgrade command in APT to upgrade to the new OS release, in Maemo is not the case because each OS release has a specific hardware target, so there is no need to handle complex dependency handling.

And that is the historical reason that the Hildon Application Manager does not use the APT algorithms for dependency handling. Instead of that, it use custom chicken-like algorithms: if the dependencies are not fulfilled without any foreseen problem, the package installation, upgrade or removal is rejected.

The Maemo OS upgrades are done through a meta-packages, which is merely a list of package dependencies to conform the new release. And this is all the magic in the famous SSU.

But this approach posses a couple drawbacks, which, in Fremantle, had grown disproportionally given the dimensions of the project.

First, the number of packages which conform a new release is so big, that the package section in the list file is bigger than the buffer size allocated by APT to parse it. We already filed a bug in Debian about this matter. It seems the problem is an integer overflow.

Second. It is quite easy to break the SSU process: if you install a third party application with a hard dependency to an OS package, the meta-package of the next release will fail, given the chicken-like nature of H-A-M when solving dependencies problems.

The adopted solution is impose a dependency policy for third party packages, which current implementation had triggered a community discussion.

The other proposed solution, use the tiger-like algorithms available in APT, was discarded given the risk of the needed changes in the apt-worker versus the available time frame.

No, there is not conclusion yet about the third party policy issue.

Hildon Application Manager goes public

Almost since my arrival to Igalia I started to work in the Hildon Application Manager or H-A-M for friends. The project was developed using SVN in garage, but after the GUADEC in Turkey, we move it to GIT, within an internal server.

But after an unexpected and bold movement of Marius Vollmer, the latest development version of H-A-M, for Fremantle more specifically, was pushed into the wild. Thanks mvo!

H-A-M was finally sync with a repository in Gitorious, making available its source code for everyone. So, everyone is invited to submit your patches! 😀