Raspberry Pi

I’ve got a Raspberry Pi since a while back. I placed an order the morning the Pi was released. However, I also have a newborn and a four years old, so progress on the Pi has been slow. Now, finally, I have a setup that I’m pleased with.

I use my Nokia N900 charger, a non-name powered USB HUB, and a d-link DWA-131 wifi USB dongle. This page is a great resource for selecting periphials. The only draw-back right now is that the HUB and Pi draw power using separate supplies. Sharing a single 5V feed would reduce the need to free wall sockets from two to one :-)

For casing, I use a self-printed Raspberry Pi case with GPIO-access. However, I’ve not had time to fiddle around with the GPIOs just yet. The case fits nicely onto my noname USB HUB, so I’ve joined the two using a piece of velcro. The look is not very stylish, but the packaging is nice.

For software, I use the Raspbian image featuring debian built for armv6 with hard-float. I also use the qt50-snapshot from here (look under nightlies). That image is missing qmlscene and qmake, so for development, I guess I have to setup a cross compiler, or spend 4-5 days compilation time building a Qt 5 snapshot on the Pi myself. Not having qmake is sort of ok – compilation times are bound to be long, but qmlscene would had been nice, to be able to do local QML development.

I’ve had Qt 5 working from a snapshot for Debian wheezy with softfloat which had qmlscene pre-built. The framerate is nice, so it felt as if there was true potential there. I’m looking forward to being able to build my own little C++ QML extension and try it out for real.

Pics, code and more info will follow.

Do not dash in deb

When building Harmattan apps using Qt Creator, it is important not to have dashes in your project name. If you do, the generated desktop file will refer to foo-bar, while the app binary and icon will be named foobar. It is a simple fix, but can be confusing at first.

Symptoms: app starts when launching from Qt Creator, but icon looks odd and app cannot be launched on the device.

Packaging Qt 5

As Qt 5 approaches alpha, it is more and more interesting to try using it outside the comfort of developer machines. For that, packages are needed.

Thanks to vgrade I found the qt-spec-effort project on Gitorious. This git contains a nice script that populates an OBS with the Qt packages. Perfect for my needs. I had to employ some minor tweaking to get things going, so my clone can be found here.

One thing that possibly could affect Qt 5 is the version of XCB, the new X protocol C bindings. When upgrading the existing packages for libxcb and friends I ran into a split package. Apparently, xcb-util was split into five packages (xcb-util, xcb-util-wm, xcb-util-renderutil, xcb-util-image, xcb-util-keysyms), so the packaging turned out to be a bit more tedious than expected. Still, the spec-files are available from the xcb-spec-effort git that I setup. The only consequence of this was that I had to be more specific when specifying dependencies for Qt 5’s qtbase (it is all on Gitorious).

So, now, all I need is a good way to measure and optimize QML performance. The swaplogger tool serves the first purpose (spec file in this clone). Now, all that is left is the optimization part :-)

Building the QML Run-time

I visited OpenSourceDays 2012 this weekend. I did my presentation and met some people, but could not attend any other sessions. This was part due from the site being out of power when I got there (talk about Murphy at a large scale) and part because I wanted to enjoy beautiful Copenhagen with my family.

In my presentation I wanted to discuss how to approach the problem of building a run-time environment for a QML user experience. The choice is (as always) between time and quality. In this particular case, quality means how free the user experience designer is from the run-time implementation.

After the talk, I enjoyed a discussion with Mario Boikov. I argue that it is ok to use root context properties, i.e. global singleton variables in QML-space, to share states. He argued that presenting everything as QML registered types that QML instantiates gives better QML. I agree and disagree, as always ;-).

By using root context properties, it is clear to QML that it is a singleton instance. It is also a very handy way to expose plain QObjects to QML. Just add the odd Q_PROPERTY and Q_INVOKABLE macro and add it.

By exposing state-representing objects as registered types, one has to handle the singleton back-end (if it exists) through a wrapper class registered to the QML type system. This adds complexity on the C++ side. This, I feel, is ok, as the C++ developers are the ones with system knowledge. Any complexity related to technology should be handled here. From QML, this approach gives you prettier bindings. You can find a property of the service to something, and you can avoid the Connections solution to reacting to signals.

What you do lose on the QML side, is the clear message that the particular object is a singleton. You also (potentially) introduce allocations and deallocations of the wrapper object. This shouldn’t be an issue, especially not as such a QML design would trigger those either way. Still, as an old school embedded engineer, memory fragmentations is a scary thing.

QML is a wonderful thing, but the language and tooling are new to us all. I suppose discussions as the one above will lead to some sort of best practice being established. In the mean time, lets benchmark and compare notes. What gives the prettiest code, where do you lose performance, what did the Trolls intend for us :-)

The Irony of the Real World

Qt does not sell mobiles. As a consumer, Qt is a technicality. Right now, the experience and availability of apps sell phones. Qt is just a tool for us developers to implement those experiences. Despite this, it is interesting to compare the Nokia N9 and the new WP7-based Lumia handsets. The market’s reaction to both, and the irony of it all.

Sweden is a highly developed smartphone market. Almost everyone has a smartphone. Flat rate data subscriptions are cheap. Both N9 and Lumia are sold here, and are advertised.

The reviews are interesting. In mobil.se’s comparison, the N9 lose out because the platform is bound to die, thus have fewer apps. In the same organisations yearly awards, the N9 win three out of four applicable categories (the Sony Ericsson Mini Pro won the value-for-your-money-award). The N9 also went straight to the top of the selling charts at katshing.se, and in the telekomidag.se review of Lumia, the final words praise the N9 “Sister model N9 with MeeGo was a (albeit late) eye-opener, for Lumia is feeling more of oh well-character. Skilled in every way – but we have seen most things before.” (google translation of “Systermodellen N9 med Meego var en (om än för sen) aha-upplevelse, för Lumia blir känslan mer av jaha-karaktär. Kompetent på alla sätt – men vi har ju sett det mesta förut.”)

Following this trail, the latest sad figures from Nokia report that things aren’t going that well. Telling your customers and employees that your current unique product is dead, then delivering a mainstream product later does not help improve business. Bloomberg has looked at various analysts’ estimations of sales figures, and they estimate 1.4 million N9 where sold 2011, while the Lumia is estimated to have sold 1.3 million (estimates range from 800k – 2M).

The interesting part in all these comparisons is that the N9/MeeGo platform is not being pushed by Nokia. They do not want to sell it. The Lumia, on the other hand, is being pushed by the biggest marketing budget Nokia ever has spent on a single product. The Lumia series is being expanded, apps are emerging.

I am sure that Nokia/Microsoft will succeed. I had a VHS system at home, even though Betamax was technically superior. The cost for success will be to turn Nokia from a leading brand into a mainstream supplier, no more important than HTC or Samsung. Sad for Nokia, sad for Finland, sad for what could have been for Qt. Launching N950 alongside N9 and following up with multi-core models would had been great. Also, seeing that MeeGo Harmattan more or less was Maemo with Qt, Intel’s drop-out would not have been the end of the world.

Still, from a Qt developer, this, in combination with the openly governed Qt Project means that Qt will stay a cross platform tool. The risk of seeing it being sucked into a life as a (great!) single platform is no more. Qt/iOS, Qt/Android and Qt/MeeGo give a bigger target area than WP7 has. And if the WP8 platform is to follow desktop, Nokia just jumped from one burning platform to another, since they are going HTML5.

Intel Graphics – 3D Artifacts

So I’m running a 13″ MacBook Pro with Ubuntu. It has the 2.7GHz Dual-core Intel Core i7 processor with integrated graphics. I’m running the i915 driver (which is what Ubuntu set me up with). Now, everything seems ok, until I run something 3D with (I think) transparent surfaces.

I can spot the issue in SuperTuxKart, but in Minecraft, I don’t have to look for it. It looks awful. I’ve included two screenshots – one from daytime and one from night. Notice that the noise in the image actually is noise, i.e. it changes all the time.

Also, when running the Minecraft game, the rest of the desktop gets messed up too (font rendering, etc) but as soon as I turn it off, everything is working again. Very annoying.

Anyone out there, perhaps you, who know how to solve this? I’d be really thankful!

Opportunities

As fall approaches and the weather turns wet, I have happy announcement to make. Pelagicore, where I work, and our efforts in using Open Source in the in-vehicle infotainment business have been noticed. We just received 20MSEK investment from Fouriertransform (English / Swedish). This means even more Linux and Qt hacking for me! *happy*

Rendering Issues

I’ve run Kubuntu on an old MacBook Pro (revision 5.1) for over a year now, and it has worked great. However, last week, it became more or less unusable. It seems that some sort of blending operation results in noise.

When using the machine with some composition effects, it was completely unusable – moving a window resulted in a square or static noise. All edges of plasma widgets where covered in noise, etc. Disabling all effects meant that I can use the machine again, however, some noise prevails.

As you can see from the screenshot at the top of this post, it is visible in the panel. It is also visible in elements such as the slider and the upper right corner of the desktop folder plasma widget. Another factor is that the noise sometimes disappear when a repaint is forced, but it is “physical” enough to get caught in a screenshot.

So, dear lazy web, do you recognize this from somewhere? Is it the drivers? Is it something in kwinrc? Or is it hardware (perhaps graphics memory) failing?

Update. Thiago from Tro^H^H^HNokia Qt Development Frameworks^W^W^W^WIntel (apparently at a new job) told me to clear the image caches. Read the comment, follow the instructions, and everything works again!

Mythbuntu 11.04 and the Remote

I decided to do some server maintenance today, so I upgraded my Mythbuntu client to version 11.04. I upgraded the backend server as well, but that went smoothly, so I guess that isn’t of public interest.

The client is based on the Asus AT3ION-I Deluxe motherboard. Having upgraded the client, the boot time went from seconds to minutes, and the remote stopped working. After some dmegs, lsmod and Google action it turned out that this was due to the mceusb driver. It loads when the remote is detected, it then crashes, makes the hid-philips-asus.sh script lock the boot process for about three minutes and prevents the correct driver from being loaded. The fix, to blacklist mceusb, is described in the ArchLinux wiki.

N900^H^H – Less Could be More

I’m a happy user of the N900 – an ageing device. As I recall it, I saw it for the first time in real life at Qt DevDays 2009. So, basically, my phone is older than my laptop, and I’m happy about it.

Yesterday, Nokia removed two zeroes from my old workhorse and announced the N9 – a Qt driven phone. You can find a detailed spec here (thanks Ubuntufreak). What I’m excited about is:

  • Unibody. Nokia’s phones have been a bit on the plastic side for my taste in the past.
  • Capacitive (i.e. multi-point) touch. This has really been the N900’s weak point recently.
  • Proper Linux, i.e. MeeGo. No virtual machine layer as in Android, native binaries on a powerful platform.
  • Qt – everywhere!

So, now the only remaining question is – is this a device that will keep me happy for the next three years?