Herostratus’ legacy

Planet Igalia — 4 comments
03
Aug 10

GUADEC 2010

Thanks to my employer, Igalia, this GUADEC was my third attendance to the conference in a row. You can see my previous impressions about the first one in Istambul and the next in Canarias. This year the conference took place in Den Haag, Netherlands.

About the GUADEC, I must state this: in my perception, Gnome is going through a crisis. A middle age crisis if you want. In 2008 Gnome was on a peak, attracting the attention of everyone, especially from the mobile industry. Everybody seemed to be a happy Gnome hacker. But then came 2009 and Nokia said farewell to GTK placing all its chips on Qt. The community seemed disenchanted and disappointed. In the air was floating a sense of disbandment.

And now that the project had lost much of the media’s attention, the community is questioning to herself where to go, which is… great! It means that the community has retaken the direction of the project, and the responsibility of its success, away from the huge corporations and the PR propaganda.

And that was the spirit of this GUADEC: hard work, serious proposals, and freedom. Yes, that sense of new freedom which can also be perceived and exposed as fear, uncertainty and doubts And those feelings were more remarked because of the absence of several of the old and renown hackers of the Gnome scene, such as Miguel, Federico or Behdad.

The main trend shown almost in each talk was the importance of the World Wide Web integrated to the Gnome user experience. That was what Luis Villa talked on his keynote, and was repeated in many other presentations. Xan López and Gustavo Noronha echoed this idea making emphasis on the usage of WebKitGTK+ to achieve it. WebKitGTK+ is a reusable library, with a stable API, in difference with Mozilla, for example, which only focus on Firefox.

On the other hand, and complementary to the idea of a Web Desktop, the use of Javascript was stressed by John Palmieri: Coding for the Desktop must be just as coding for the Web. And the Gnome Shell project is the flag ship of this concept, and it continues steadily as the window manager for Gnome 3.0

Here we can observe a shift of perspective since Istambul: in those days people were trying to bring the Web information into the Desktop (do you remember the Online Desktop?); nowadays the objective is to turn the Desktop development into the same mind frame as Web development, thus the information integration would be more seamless.

An essential ingredient for this coupling is the introspection. And good achievements were seen along this past year. Must of the Gnome core libraries are making an effort to annotate their API’s, and Python, Vala and the GJS implementation are merging their introspection work.

But what everybody is asking “What’s going on with GTK+?”. Its development seems to be at a very slow pace, with no real innovation to show. In 2008 Mark Shuttleworth suggested to integrate Qt into Gnome, replacing GTK+, and this year another voice repeated the same suggestion at the General Meeting.

In a more technical issue, Benjamin Otte exploded against the so called “Walled Gardens”. Benjamin have been trying to bring video rendering in GStreamer with Cairo, but that effort means modify many different projects, bottom-up almost along all the stack. As a result, he has found many features overlapped among the different projects and also hit against the resistance from the coders of the different projects to collaborate each other, phenomenon that he called the “Walled Gardens”.

And maybe, just maybe, this is what is happening with GTK+, is a fortified garden, where selfless programmers are patiently sealing the castle for a future exposition in the wild. I don’t know, maybe GTK+ should break its X Windows ties. I don’t know. But GTK+ is not gaining any momentum for now among the user interface programmers.

Another voices raised the question about “What is Gnome from the developer perspective?”. Andrew Savory regretted the lack of a SDK for Gnome; meanwhile Alberto Ruiz praised its absence and pushed in favor of better developer documentation and tutorials. I think that Gnome, as a developing framework, is a loose set of (almost) homogeneous libraries, utilities and guide lines, where the idea of an IDE/SDK implies a centralization of all the projects which is practically impossible. And, because of this, more and more projects are integrated into the FreeDesktop community.

Also Dave Neary and German Poo showed their results from their own analysis in the Gnome repositories. Dave tried to answer the question “Who makes GNOME?”, so he extracted gross numbers from all the current data to get the actual great iron committer; meanwhile German tried to be more lean and took in count historical aspects as the different milestones of the project, sadly German only got a lighting talk to show all his results.

Finally, other projects are still floating around, the most important is Clutter, now integrating accessibility thanks to Alejandro Piñeiro. Zeitgeist seems to me a more and more marginal project in Gnome. Telepathy, which is the de facto IM communication library for Gnome applications, and many others.

In conclusion, my over all impression of the GUADEC 2010, is that the Gnome project is in a deep insight of what is it and where is it going. I reckon that during this period of introspection (wink) we will see few innovation, but rather the new foundations of the project are putting down the required roots for the future innovation.

dsp-exec landed on dsp-tools

In the DSP bridge realm, usually when the kernel module is loaded, it in turn loads the so called DSP base image, which is a file what encompass the DSP/BIOS kernel and the DSP/BIOS Bridge.

Usually, in a development cycle, you may want to test different base images, and removing and reloading the Linux bridgedriver module is not very practical. For this case, TI provides the cexec.out utility, which uses the bloated libdspbridge API, to load in runtime different DSP base images.

But we all know that cool boys use dsp_bridge instead of libdspbridge, which is much more clean, small and nice. And also we have a neat set of utilities called dsp-tools. Nevertheless a utility like cexec.out was missing, and because of that dsp-exec has born.

Last week, my patches were committed by FelipeC into the stage repository in github, and I’m enjoying them while I’m poking around in the audio decoding

Planet Igalia — No comments
21
Jun 10

by the way

I am attending GUADEC

Planet Igalia / Planet Maemo — 2 comments
13
Jun 10

jpeg decoder in gst-dsp

Do you remember this comment? Well, I took the challenge, and it has been hard to accomplish.

I started with an early implementation of FelipeC, but then I realised that I didn’t understand a bit about what it was going on.

So, I outlined a strategy with two milestones: try to clean up the TI OpenMAX IL implementation and then to add the jpeg decoder to gst-dsp.

In order to clean up the TI’s OMXIL, FelipeC recommended me to rewrite libdspbridge using dsp_bridge beneath, but I didn’t see a real gain on that task. It makes sense for a progressive TI-OMXIL update without breaking the ABI, but that was not my purpose, so I stepped further and decided to rewrite the LCML in terms of dsp_bridge instead.

The LCML is the acronym for Linux Common Multimedia Layer, and it is a shared library, loaded at run-time by the OMX components, and it provides the communication between the ARM-side application and the multimedia DSP socket node (SN). It is build upon the libdspbridge for the interaction with the DSPBridge kernel module.

My task was to rewrite the LCML, removing the libdspbridge linking dependency. You can see the result in my lcml-ng branch.

Along the rewrite process I understood the communication protocol used by the socket nodes. The clean up was really painful because the LCML code is very messy and poorly designed. And I have to say this, the Hungarian notation must be buried deep down into the oblivion.

It was my intention to keep the ABI compatibility but I rather preferred be readable, so I ended breaking it.

With a clear idea of how the LCML library works, I retook the challenge, with some degree of success: the SN was loaded up and allocated correctly, and also I found that the input port only admits one buffer, and not two as rest of the video decoders in gstdspvdec. But, when everything looked promising and the input buffer was pushed, the SN threw an critical error event and the output buffer was never received.

I had to do more than merely understand the LCML, I had must rewrite the JPEG decoder OMX component too. But this time the code was even more obfuscated than the one in the LCML.

And I had an epiphany: developing software in community implies have clean and readable code, for sake of the peer reviewing, each one with heterogeneous backgrounds. Meanwhile, under the closed and internal development approach, the QA is based on black box testing, where the cleanness of the code is not a praised virtue, but somewhat the opposite.

I rewrote all the jpeg decoder bits, from the component to its test application, but I have not pushed that branch yet into gitorious.

Finally I came across with the missing parts: each buffer pushed into the SN must have metadata, which is a structure with information about the buffer; in the case of the jpeg decoder, there were also a couple of magic numbers. The output buffer also comes with metadata, which, among other information, expresses if the buffer was decoded correctly.

Yesterday, before meeting my mates for cinema, I emailed a couple patches with the initial support for the jpeg decoding in gst-dsp.

The next task is find a strategy for the buffer number assignation on each port, so it could be defined as late as possible.

Planet Igalia / Planet Maemo — 3 comments
17
May 10

my DSP related activities

When I started to play with the Beagleboard, my objective was to poke with the DSP accelerated codecs through OpenMAX and GStreamer. But soon I realized that it would be a hard task to achieve since the framework, developed by Texas Instrument, is in part proprietary (though free), and the another is open source, but it is not developed with an open source community in mind.

When I started to pulled it out, the first decision I had to face was to choose a cross compiling environment. As you know, there are plenty: scratchbox, OpenEmbedded, buildroot, PTXdist, etc. But just because people I know from TI began to write recipes for Poky, I devoted some time learning about it. Although, after a while, I jumped into OpenEmbedded. The reason were the slow updating rate against upstream which Poky had (and as I don’t follow the project anymore, I’m not aware about its current state).

But bitbake and OpenEmbedded are not the magic wand to build up a complete image to boot up in a device. There are a lot of things to define previously. Just to mention one, the distribution to build. By default OpenEmbedded offers Angstrom. But I did not want a full featured distribution, I wondered for something thin and lean, only a serial shell to start with, something I could set as a workbench for my multimedia experiments.

And for that reason marmita born.

As you may see, I mimicked the “Poky’s way”, making an overlay of OpenEmbedded, but as soon as I was getting involved in the OE’s community, I realized that maybe that it was not the correct decision, maybe I should push my changes into Angstrom instead.

Anyway, right now I have a steady set of recipes which allows me to build images for the Beagleboard, with the latest dspbridge kernel branch, and many of the TI bytes (either proprietary and open source) required for running the DSP accelerated codecs.

On the other hand, I have revamped the DSP how-to at elinux.org wiki, with the instructions to build up a kernel with DSP/BIOS Bridge support, and the means to test the communication with the DSP through it.

Along this process I became aware of the TI problems to release his DSP user space stack to the open source community. Even though the kernel side is moving quite well towards the kernel mainline, the user space bits are not doing that well, even more, they will be completely deprecated soon, because the kernel interface is still evolving.

At the lowest layer, on the ARM side of the DSP users pace stack, there is a library known as libbridge, which is basically an abstraction of the ioctl to the dspbridge kernel module, and it offers an interface with a nice semantics, but it is too much aligned to the old win16/32 API style (a bad idea in my opinion).

But the problem does not start with the API style, it begins at locating the library inside of a chaotic bunch of files, insanely bundled in a git repository, along with binaries (either for Windows and Linux), tarballs, and all sort of unrelated documentation.

Furthermore, the image building machinery within TI is a custom set of invasive makefiles, which all the projects must include and being conform with them. As result of this highly coupled build engine, extracting and isolating a project for it release is a painful and error prone process.

Given those problems, I got lost as soon as I began. So I decided to emulate the Felipe Contreras‘ approach: get rid of libbridge and use his minimalistic dspbridge ioctl wrapper: dsp_bridge, what he uses for gst-dsp. In order to train myself in these topics I wrote a clone of the TI’s ping application, using the dsp_bridge instead. And later on I wrote the DSP socket node counterpart. Both included in the dsp-samples repository.

Currently, the ping application is also included in the Meego’s dsp-tools repository.

Nevertheless, most of the DSP multimedia codecs are exposed, out of the box, through the TI’s OpenMAX IL implementation. And it depends on libbridge. For that reason I ripped out the libbridge from the userspace-dspbridge repository and pushed it into a different repository, cleaned it up its building machinery and removed other unneeded bytes too.

Finally, I had to do the same for the OpenMAX IL, which is not only messed up with the inside building machinery, but it is not released through a git repository yet, using instead old fashioned tarballs.

The future work will be integrate gst-openmax into marmita and try to participate with gst-dsp development. Also, FelipeC came up with the idea of rewrite libbridge in terms of dsp_bridge, task that I have been exploring lately.

Planet Igalia — No comments
30
Apr 10

using bugzilla, the right way

Yes, I admit it, I hate bugzilla. I mean, the bug tracking is something indispensable for every software project, but digging in its web interface for quick searches, I just find it unbearably awful.

But I guess I came across with the right tool for overcome this web madness: pybugz

On the other hand, I’ve to say that I agree about using bugzilla to keep track of patches, it’s a bad idea too. A properly organised mailing list and maybe a patchwork, if the traffic is massive, as helper.

Planet Igalia — No comments
09
Mar 10

Jhbuild beneath OpenEmbedded

Since a while I’ve been working on a OpenEmbedded overlay called marmita. But this post is not about it. Where I want to aim now is about a nice trick: how to use Jhbuild using an OpenEmbedded setup.

First of all, install jhbuild. And, of course, install Marmita.

In Marmita, just as in Poky, in order to get into the OE environment, the user source the script marmita-init-build-env.

Then, I setup another script, which is though to be the rcfile of a new bash session: marmita-simple-cross-compiling-env.

So, at this moment we have set all those environment variables needed to run a jhbuild session. There is also an alias for the jhbuild build, which specifies the jhbuildrc file, crafted for a cross-compiled environment: marmita.jhbuildrc.

For the moment I’ve only built GStreamer. And as a matter of fact, in the process, I came up with a simple patch for gst-plugins-bad.

By the way, the destination directory is in the /opt directory, under the stage directory; so, if you want to play with the generated output in a device, just copy that directory tree into the device’s file system.

Yes, I cannot say that I achieved a full integration between jhbuild and OE, but what I can state is that cooperation is quite possible.

Planet Igalia — No comments
09
Mar 10

apache configuration for video tag in firefox

In contrast with Epiphany-WebKit, Firefox seems to be quite picky at rendering videos through the HTML5 tag <video>: it demands the correct HTTP headers.

It doesn’t assume anything. If the stream doesn’t have the correct headers, Firefox just will put a black box in you face without any further explanation.

In order to overcome this issue, struggling a little with the sparse information available through the Internet, I came with this .htaccess file:

AddType video/ogg          .ogv
Header set Access-Control-Allow-Origin "*"
Header unset Etag
FileETag None

First of all, my Apache server doesn’t recognize the video/ogg mime type.

Second, the header MUST NOT include the ETag key.

And finally, there’s new header, which isn’t fully implemented by the all browsers, but it will be, and will mess up all our pages with embedded videos, is the cross domain accessibility.

More information:

http://diveintohtml5.org/video.html
http://www.bluishcoder.co.nz/2008/11/video-audio-and-cross-domain-usage.html
http://en.flossmanuals.net/TheoraCookbook/MyHosting
http://www.askapache.com/htaccess/apache-speed-etags.html
http://httpd.apache.org/docs/2.0/mod/mod_headers.html

Planet Igalia — 2 comments
13
Feb 10

Grilo meets Vala

Last week, after the internal presentation of Grilo, I got pretty excited about the project: basically, using Grilo I could make epris consume feeds from Jamendo.

I started to generate the bindings for Vala. I never thought it could be that hard: the heavy use of atypical callbacks in Grilo made me find a bug in the code writer of Vala. And eventually I came with a small patch, which I’d just pushed.

Those problems brought into the discussion to use GAsyncResult within Grilo instead of the custom callbacks mechanism. We’ll see where we can go.

Finally I got my small test snippet. Cute, isn’t it?

Today also pushed another patches I’d in my Vala queue. The interesting part is, after talking with Zeeshan, I understood that the gstreamer vapi must be generated with the latest release of GStreamer. Something logical but I never stopped to think about it.

Planet Igalia / Planet Maemo — No comments
09
Feb 10

Slides of my talk at FOSDEM 2010

I still don’t know how to submit my slides into the FOSDEM website, so I’m linking them here by now:

Herostratus’ legacywords from a lazy coder