QtMediaHub on MIPS with Qt5 and DirectFb

Ever since the start of the Qt project I am working on DirectFB in Qt5 (and Qt4) with the remote goal of getting QtMediaHub to run. It started with catching up with the rather nice refactoring of lighthouse in Qt5, fixing memory and resource leaks in Qt5, DirectFB and mostly in the DirectFB lighthouse plugin.

It moved to dealing with broken "make install", broken QML2 examples and documentation, figuring out how to get patches for QtV8/V8 into the project, adding MIPS code for the Qml mode (a new global object), global compare for MIPS and finally working on OpenGL integration for QML2.

In this specific case I had an OpenGL ES 2.0 library coming from a vendor and created the 'directfbegl' plugin to use EGL to go from IDirectFBSurface to an eglSurface. I think in this specific case there is unified 2D and 3D buffer space which should allow a lot of cool stuff.

It mostly works, QML2 has some way to go to work on battery powered devices but it is looking quite nice.

OpenOCD and SIMtrace

This is just a short note to myself (and then copied into our SIMtrace wiki).

This is working for OpenOCD (74558296d1e185fc4a7522f08832eceed460cbd7) and the Amontec JTAGKey (but should work with any JTAG adapter). The easiest way is to start OpenOCD with default config files.

The SIMtrace v1.0 hardware is powered by the Atmel SAM7S microcontroller and the closest match for this platform is the atmel_at91sam7s-ek.cfg board configuration file.

First try

$ sudo openocd -f interface/jtagkey.cfg -f board/atmel_at91sam7s-ek.cfg
...
Error: An adapter speed is not selected in the init script. Insert a call to adapter_khz or jtag_rclk to proceed...

Second try

You can patch one of the two files, create a new config file and load it with -f
or specify the command. The below example specifies it on the command line.

$ sudo openocd -f interface/jtagkey.cfg -f board/atmel_at91sam7s-ek.cfg -c "adapter_khz 30"

Final config

$ echo "adapter_khz 30
> arm7_9 dcc_downloads enable
> init
> reset init
> " > myinit.cfg

$ sudo openocd -f interface/jtagkey.cfg -f board/atmel_at91sam7s-ek.cfg -f myinit.cfg

One of the calls appear to fix 'halt' not really halting the SoC, I have not investigated which of the options is doing it.

Flashing First try

$ telnet 127.0.0.1 4444
> flash write_image /tmp/main_simtrace.samba 0 bin
wrote 0 bytes from file /tmp/main_simtrace.samba in 0.238727s (0.000 KiB/s)

With a quick look into the NOR Flash code, it appears to fail as it does not
find a flash region at the address it is looking for one and then reports to
you the success of 0 bytes (instead of a failure).

Flashing Working

$ telnet 127.0.0.1 4444
> flash write_bank 0 /tmp/main_simtrace.samba 0
wrote 37020 bytes from file /tmp/main_simtrace.samba to flash bank 0 at offset 0x00000000 in 39.175068s (0.923 KiB/s)
> reset init
> resume

DirectFB contribution to the Qt Project

The Qt project was launched today, I got my 15 DirectFB patches merged, got some first experience with Gerrit, created an account for the Qt wiki, fixed some documentation, so all in all I think it is the great start of the Qt Project we have been waiting for! So thank you very much for all you involved with it!

Now to something completely else, somehow I like to see the parts that are not great yet. But most importantly it is a great opportunity for everyone to get involved with the Qt project and improve things. So here is my short wishlist for the Qt project.

• Single account for the Bugtracker, Wiki, other services.


• Read-Only access to gerrit.


• Public CI based on Jenkins, right now build failures will still point to internal Nokia servers. I assume KDE can help a bit with the Jenkins setup.


• Make it possible for non-mainstream QPA backends and platforms to be part of the CI System, if proven stable be considered core builders.


• The wiki being part of the Qt project should be part of the Qt Project, the license should probably be made compatible with the license of the Qt documentation, to allow copying from one to the other.

Once again, thank you Nokia, thanks everyone involved!

First days with Ubuntu 11.10

• Crypto Password for /home is echoed back... no canonical mode set..


• A single process can take down a multi-core system... poor scheduler performance?


• New volume applet has no support for changing volume by keyboard... and no way to change the volume of the microphone


• GTK+ file dialog has wrong margins... visual offsense... left and right area have different height

Creating a small GUI for the SIMtrace application

Earlier this year I created a Hardware company with a friend to supply to our GSM community and beyond. One of our first products is the SIMtrace Hardware (CC Licensed, actually it should work with any Smartcard). Today I had to wait a bit and decided to convert the CLI application that talks to the firmware to a GUI application. I did this by running the CLI part in a QThread and using QMetaObject::invokeMethod to callback to my GUI.

I started off creating the Qt application with VIM and a browser to help me to remember some function names. After a while I had enough of this and used Qt Creator and enjoyed the auto completion, it had no problem reading our C header files of libosmocore and provided auto completion for these too. Once again I am amazed how nice Qt Creator is and how little code I needed to create the below.

From October 13, 2011

QPixmap and what I did not know

In general QPixmap is the class I dislike the most in the Qt graphics stack. It is not because it did anything wrong, or has annoying bugs. It is merely that painting on a QPixmap can produce a huge slowdown. Maybe it is even the immediate painting model I dislike so much.

In theory the QPixmap should represent the graphics memory and in theory painting this to another piece of graphics memory should be very fast. But reality is different, e.g. with directFB/X it is possible that your graphics memory resides in the host memory because you have allocated too much. X (EXA, UXA...) has migration strategies, directFB will just allocate it in system memory and it will stay there. So your graphics memory class might not be always allocated in graphics memory.

The athur painting capabilities of Qt4 were very nice but Hardware/X/directFB might not be capable of handling all the advanced concepts (perspective transformation, drawing other pixmaps scaled) and the paintengines then need to fallback into the raster path, but the raster path needs to work on a QImage and this is where stuff get terrible. There will be a download of the memory (slow), there might be a change in color (ARGB -> pre multiplied ARGB?), then the fallback, and then uploading of the memory again. So even classes like QGraphicsBlurEffect go through QPixmap -> QImage -> QPixmap (or at least used to).

So the basic problem with QPixmap and the immediate painting model is, only once you are done with painting everything, you know if starting with a QPixmap would have made sense. If Qt5 wouldn't be all about OpenGL, I would have lobbied hard to make QPixmap an internal class and use it to 'cache' QImage that have peen painted a lot.

After all this love/hate with QPixmap there were still things I didn't know. For Qt5 I am working on the directFB lighthouse plugin and started to work on make more tests pass. The thing I did not know was that by default the QPixmap has no alpha channel, only if either a mask is set or the pixmap is filled with a color that has an alpha channel the QPixmap will end up having an alpha channel and be ARGB. This means that a lighouse plugin providing a QPlatformPixmap implementation needs to be able to provide an ARGB and a RGB based pixmap and switch between them.

GNU Smalltalk deployment with images and image resumption

Once up on a time I was sitting in a cold hall at the Barcelona exhibition ground, a power outage has taken down several DVB-H platforms (racks consisting of servers, streamers, RF equipment...) and once power was restored red LEDs were blinking, systems not coming up automatically, hordes of engineers trying to boot the right kernel, trying to remember the multicast routes they had typed in by hand, chaos, hectic. It was interesting to witness that as we could lay back, continue with our work, as our platform was configured to come up automatically and it did.

One has to assume that stuff breaks, software, disk, RAM, CPU, power supply, anything. The only answer to that is be prepared, build your software to deal with failure (or nicely try to restart), make sure all systems start automatically, have backups, have a plan.

For my GSM (telephony) in Smalltalk components I didn't do that yet, mostly because my code was not very mature, I was still building up the trust relationship and so my deployment consisted of manually running GNU screen, then GNU Smalltalk, manually loading my code, starting things up. It was about time to correct that.

The tool of choice is the gst-remote application, it will run a GNU Smalltalk image, it can daemonize and it will listen for input from other systems. While moving to this deployment my fellow Smalltalkers were kind enough to fix some bugs on the way. There was an issue of gst-remote exiting when saving an image, the Delay class not functioning properly on resume, the wrong FileDescriptors being closed on image resumption. It is very nice to get help that fast!

My deployment now consists of building GNU Smalltalk packages, having a Smalltalk script to load the package and call start method of that package followed by taking a snapshot and exiting. I can then resume the image and if the software is prepared to deal with image resumption it will work.


Eval [
| name image |
name := Smalltalk arguments first.
image := Smalltalk arguments second.

(PackageLoader packageAt: name)
fileIn;
start.
ObjectMemory
snapshot: image;
quit.
]