Writings Photos Code Contact Resume
planet maemo

You are here

Reverse engineered libomap3camd header file for N9 and N950

Submitted by msameer on Sun, 17/02/2013 - 4:46pm

A short introduction about N9 camera stack:
Camera stack for N9 is built on top of V4L2 subdev and media controller interfaces.
A GStreamer source element called subdevsrc (And subdevsrc2 starting from PR 1.2) sits on top of the kernel interfaces.
A closed source component called libomap3camd (OMAP3 camera daemon library) contains all the 3A (Auto exposure, Auto white balance and Auto focus) algorithms in addition
to image capturing. It simply gathers statistics from hardware components such as ISP histpgram (And others) and controls the camera pipeline to adjust image quality.

What do we have?
Nokia was kind enough to provide a compiled binaries subdevsrc and libomap3camd to the MeeGo project. However they have not released the header files for libomap3camd.

This puts us (The community) in an unfavorable situation. We cannot easily manipulate our GStreamer stack, update or fix bugs in subdevsrc (Whose source code is publicly available).

How about the future?
You can obtain the code from its git repository.
Using the reverse engineered libomap3camd header, I managed to rebuild subdevsrc for NEMO
and got meego-handset camera to work and capture an image :-)

The code built is from this commit:

commit effd37efa3ba026221e0f84ef370d06f1a122b6c
Author: Tommi Myöhänen <tommi.myohanen@digia.com>
Date:   Thu Mar 17 12:38:40 2011 +0200

    Release gst-nokia-videosrc (0.57.0-1)

I failed to build the latest git master due to the old GStreamer photography interface available in Nemo/Mer.

How did all this happen?
It took a day or a bit more of a weekend.
I started by building subdevsrc and creating various enums and structures needed to get it to build (with dummy values).
I then started poking around using the latest nemo mobile release and ltrace.
GstSubdevSrc used 4 functions out of which, cam_set_feature is the most important one.
This approach didn't really work quite well. It seemed that the number of cam_feature_set calls found by ltrace doesn't match those in the code and it seemed that the code used to build the nemo subdevsrc isn't really available.

Here comes N9 to the picture. Thanks to the "beloved" AEGIS framework, ltrace didn't work.
I tried to mock a libomap3camd shared object and LD_PRELOAD it but that also didn't work.

I sat down and wrote a minimal application that would manipulate subdevsrc properties and observe the value of registers (r0 has the library handle but r1 and r2 are really interesting) when gdb breaks on cam_feature_set and I managed to get some values but that was clearly not enough. Even gdb sometimes doesn't break at all :(

The gem was the discovery of a subdevsrc package along with its debugging symbols:
gstreamer0.10-nokia-videosrc-dbg=0.52.19-1+0m6 and gstreamer0.10-nokia-videosrc=0.52.19-1+0m6.
Download and install them (Use inception) and wow! All data structures can be dumped easily using gdb ptype and all enum values can be printed using gdb print.
The only exception was maker_note_t which needed another hack.

And now?
I guess now we can easily update GSTreamer and subdevsrc to the latest and even fix any bugs that we find. I am not sure how crippled our libomap3camd is and whether we can get all subdevsrc working but we are at least in a better position.

N9/N950 camera with zoom during video recording!

Submitted by msameer on Thu, 10/11/2011 - 12:17pm

If you are using PR 1.1 then you can simply enable zoom during video recording.

Just create a file /etc/camera.conf and add the following lines:

recording-zoom = true

restart camera, enjoy and send postcards to the Harmattan camera team :)

I hope someone will create an Ovi store app for that ;)

Increase the font size of the N9 conversation view.

Submitted by msameer on Wed, 02/11/2011 - 10:42pm

If you care about the readability more than you care about the eye candy then that's for you ;-)

1) You need to enable developer mode and ssh to the N9.

2) # mkdir -p /usr/share/themes/blanco/meegotouch/libmessagingwidgets0/style/

3) # vi /usr/share/themes/blanco/meegotouch/libmessagingwidgets0/style/libmessagingwidgets0.css

4) Insert the following lines:

BubbleItem MLabelStyle#BubbleItemMessageIncoming {
font: $FONT_FAMILY 32px;

BubbleItem MLabelStyle#BubbleItemMessageOutgoing {
font: $FONT_FAMILY 32px;

BubbleItem MLabelStyle#BubbleTimeStampLabelOutgoing {
font: $FONT_FAMILY light 32px;

BubbleItem MLabelStyle#BubbleTimeStampLabelIncoming {
font: $FONT_FAMILY light 32px;

5) # su - user
6) $ killall -KILL messaging-ui
7) Enjoy :-)

Twitter OAuth Proxy

Submitted by msameer on Tue, 14/09/2010 - 8:55pm

I'm using Twitter plugin for Contacts and Conversations to twitter on my N900.

Twitter recently moved to OAuth. Problem is the Maemo package is outdated and seems to be unmaintained.

I did some research and came across a blog entry about exploring OAuth-protected APIs and some code. Nice idea but not usable for me.

I ended up sitting down and writing a small python script that will re-route your HTTP requests to api.twitter.com after adding all the OAuth bills and whistles, read the reply from twitter and send it back. Neat ? :-)

There's also supertweet.net which I've discovered after I finished writing my script but seems they don't support all of the twitter API call while my script does that.

The script is simple without much error checking but it's been working for me for a few days already.

Last thing, I'm not interested in running a service like supertweet. I'll not be implementing the full OAuth protocol. Need to use it ? Register your own application.

Get the code while hot!

git clone git@gitorious.org:twitter-proxy/twitter-proxy.git

Next step: Thinking of maintaining the twitter plugin for Maemo. I already compiled the latest code and it sort of works fine :-)

ISI specifications for Nokia modems.

Submitted by msameer on Sun, 25/04/2010 - 9:48pm

A serious limitation of the N900 connectivity subsystem IMHO is the inability to create multiple connections. One can only have one connection at a time. This was a problem when I started investigating MMS support for N900.

Of course one can use some undocumented API like fMMS to have more than one GPRS connection. There's only 1 problem with that approach. You can end up with IP/subnet clash.

I've been thinking about a kind of hacky solution for the MMS problem: Let's have a tun interface with a known IP such as or 192.0.2.x. We force all of our traffic through that interface and "something" sits in the middle to route the data between tun and the GPRS modem.

Sounds easy but not that easy.

The only information available about ISI modems and GPRS manipulation is some patches adding GPRS support to Ofono.

I've been playing with them for a few days. I managed to get a PDP context which fails to activate.

Hmmm, Googling a bit revealed the Symbian Modem Adaptation project. The code is there but it wasn't enough.

What I didn't notice initially was a semi-hidden link to the wireless modem API server. There I found not only complete documentation for ISI; but also header files with al the constants. More than the ones available from the GPRS patches.

Now manipulating the modem is just the matter of reading the documentation (READ the license aggrement first before you get them), creating a bunch of phonet sockets, using sendmsg() and recvfrom() and parsing the output.

Now I wont wonder why does my phonet packet:

23:19:10.543792 Out ethertype Unknown (0x00f5), length 47:
        0x0000:  006c 3100 1a00 6a37 0600 2100 0000 0205  .l1...j7..!.....
        0x0010:  0e08 696e 7465 726e 6574 0040 0190 04    ..internet.@...

look different than the one sent by the connection manager:

23:16:58.296905 Out ethertype Unknown (0x00f5), length 47:
        0x0000:  006c 3100 1a00 6800 0600 2100 0000 0205  .l1...h...!.....
        0x0010:  0c08 696e 7465 726e 6574 0090 0402 00    ..internet.....

I'm using 0x0e while they use 0x0c

There'a also a hidden excel (DUH!) sheet showing which ISI API is mandatory and which is not.

Happy hacking!

P.S. This might be old information but I've just discovered it.

MMS support development to be suspended until the end of February.

Submitted by msameer on Wed, 03/02/2010 - 6:11pm

The gitorious repository now contains a broken mms-manager, a non functional mms-ui (because I changed the DBus interface ;-)), a preliminary mms viewer and a broken network connection manager. How pretty is that ? ;-)

I've been redesigning the DBus interfaces and I think I reached something. The UI can be easily adapted after that.

However, I'll be on vacation until the end of February. I can't work on mms until I'm back.

I'll try to commit and push the code I have on my laptop but the stuff will still be broken.

This is just a quick status.

Good wishes for the newly married couple ;-)

mms-support progress

Submitted by msameer on Sat, 09/01/2010 - 4:42pm

Hi again!

I'm still working on the MMS support for fremantle.

I've created a gitorious mms-support repository that hosts all my code. Clone it and check ;-)

git clone git://gitorious.org/mms-support/mms-support.git

I've improved the parser a bit. It should be capable of parsing the headers in my operator's notify-ind.

I've also implemented a wap push handler (Interface stolen from Frals ;-)) and managed to receive the notify-ind on my N900 :-D

There's also an untested connection-manager using libconic (Untested because there's no UI yet to configure it). I hate using conic for such things but it's the only available public interface :-(

I need to figure out how fit the whole thing together.

And no UI of any kind yet.

More posts later.

mkmms available.

Submitted by msameer on Mon, 04/01/2010 - 1:29am

As promised yesterday, I'll start cleaning up my code a bit preparing to post it here.

Here's mkmms. It's a minimalistic application that allows you to create an MMS and attach ONLY 1 file which can be jpg, png, gif or txt (I hadn't tested anything beyond jpg).

Note that it's alpha quality.

There's also a parser that will print some info about any MMS passed as an argument but it's commented out.

Use it like this:

./mkmms <to address> /home/mohammed/me.jpg m-send-req.mms subject

It needs QtCore and only that.

Don't ask about the license. It uses some bits from Qt extended, some from mmsdec and some are my own but you should be OK if you assume GPL for now.

I wrote it to make sure the MMS library works and to generate MMS messages to test.

Next, I need to clean up my sending code and post it.

Now a bit about MMS:
MMS is just a bunch of attachments cooked together using the WSP encapsulation protocol.
A typical MMS consists of a header and a body. The header contains the From, To, CC, BCC, Subject, ... parts.

The body contains the actual parts. A part can be a video, an image, some text or anything (Not exactly sure).

Now there's something called SMIL out there.

SMIL is some sort of XML that tells the "phone" how to render the MMS. MMS can contain a SMIL part and that's usually the first part of the body (I think the standard demands it being the first part) but it doesn't have to be there.

For now, I'll ignore something called SMIL at all.

Next: Sending MMS to the actual gateway.

Not First MMS sent via N900 (Fremantle)

Submitted by msameer on Sun, 03/01/2010 - 4:27am

I've spent the past few days trying to get MMS to work on the N900.

EDIT: Seems frals has managed to beat me!

I started by trying to enable receiving so I can try to monitor DBUS and see what's going on. This failed and my operator (Elisa Finland) sent me an SMS stating that they can't send me the MMS configuration and I have to send an MMS first (According to Google translate's Finnish to English translation).

I then decided to try implementing sending.

I needed a custom MMS encoder so I can build my MMS. I also discovered that I know nothing about these things and started working on an MMS encoder/decoder.

I used a sample MMS, enjected my number and kept trying.

After long hours of working, I managed to hear my N95 vibrating and it was it :-D

This is just a proof of concept. Sending works. I need to figure out how to receive the wap push notification and how to bring up the GPRS connection in a clean way.

I'll post detailed instructions and the code I used when I get some sleep ;-)

Here's the HTTP headers sent:

Content-Type: application/vnd.wap.mms-message
User-Agent: NokiaN95_8GB/31.0.015; Series60/3.1 Profile/MIDP-2.0 Configuration/CLDC-1.1
x-wap-profile: http://nds1.nds.nokia.com/uaprof/NN95_8GB-1r100.xml
Accept: */*, application/vnd.wap.mms-message, application/vnd.wap.sic
Accept-Charset: utf-8\r\nAccept-Language: en

Ah, and I didn't yet parse the reply I've received from elisa's server ;-)

Finally, a nice screenshot of my terminal:

Corporates are evil.

Submitted by msameer on Sat, 29/08/2009 - 9:33am

After the N900 has been announced. I was saying this to a friend of mine:

[Me] so
[Me] remember our discussion about a Linux powered phone ? ;)
[Me] sorry I convinced you that Linux on phones is a no while I knew we were doing it :)