A Big Slice of Raspberry Pi

Unlike most people who’ve got a Raspberry Pi, I actually know what I’m going to do with mine.

Actually, mine hasn’t arrived yet - Celso was kind enough to lend me one of his until that happens, since I “got” mine from the QtonPi project - the Raspberry Pi Foundation agreed to distribute a few units to Qt developers, and I enrolled with a very specific project in mind: digital signage.

So far none of the QtonPi units have actually arrived yet, but that turned out to be for the best since, in the end, I’ve wasted considerably less time dealing with early adopter pains.

A lot has happened in the software front since the thing first shipped - not only has a mostly stable and well-tended Linux distribution been released only this week, but finally things seem to be shaping up as far as decent hardware support is concerned, allowing me to skip over most of the problems.

Let’s face it, the Raspberry Pi is hardly a general purpose machine. Regardless of all the hype regarding it, and no matter whether you over-clock it or not, doing anything useful with it requires a fair amount of patience.

Having long dealt with ARM devices I find it much faster than, say, the NSLU2 this site was developed in a few years back, but some of the enthusiasm behind it has a somewhat quaint (okay, charming) ring given that the board currently ships without solid graphics drivers.

Oh, sure, there are a few binaries that tap the GPU directly for video decoding and 3D graphics, but the X server is not accelerated (it’s a stock framebuffer job), the 3D API that appears to be the most stable is OpenGL ES (a charmingly broken standard at best, a right nuisance to deal with at worst), and broad support for the built-in FPU (essential if you require nice fonts and speedy HTML page rendering) is as recent as last week.

As for tools, developing for it beyond the educational level requires a fair amount of patience and know-how, all the more so if you’ve spent most of your time dealing with Intel hardware (a handicap most people my age don’t have).

But it also requires a fair amount of digging even if you haven’t, given that most software packages are too fresh to be considered stable, the staple libraries of a graphics developer (like SDL) are hampered by the lack of GPU support, the HDMI output is somewhat finicky, and the framebuffer driver seems to give up and blank out the screen after a bit of strenuous exercise.

So I’m going to rate it as a cheap, friendly, but still mostly incomplete hobbyist device until all of those are sorted out. But I love the potential.

Most of my friends and colleagues are trying to turn it into a home server or a game console of some sort - I’ve gone down that path myself including investigating gamepad support, and it’s likely to be fun to watch the emulation space unfold, but right now I have a more practical use for it.

As far as digital signage is concerned, the main goal is pretty simple: to get stuff up on an LCD display, period. We run a number of those at the office displaying status boards and analytics of various kinds, so the scenarios and content are pretty well defined.

But the process to achieve that has to take into account not just final presentation but also ease of maintenance and (most importantly of all) ease of content updates. Sure, you can throw up a few bitmaps and hard-code a few screen layouts, but that won’t be a decent solution by any stretch of the imagination.

It should be pretty obvious that given today’s technology, a full screen browser would be just the ticket, right?

Except running a full screen browser on the Raspberry Pi is (even on Raspbian) slow as molasses, especially if your content uses JavaScript and DOM manipulation to update portions of the screen.

And it gets predictably worse if (as our apps do) some of the things we want to put up on your displays include complex SVG charts that are dynamically rendered on the client side. Even where signage is concerned, it gets pretty boring (as well as downright distracting) to have stuff render jerkily.

Using the recently released Chromium build almost works but it’s still too painful to watch our stuff render, and in the end the built-in Midori browser and careful selection of content (as well as some server-side charting) is probably a safer bet, even though you’ll miss out on chromium –kiosk URL, which is what most people doing similar solutions appear to be using.

So if you must do something now, midori -e Fullscreen -a URL is your best friend, even if it sometimes leaves a thin strip of browser chrome across the top¹.

Also, don’t forget to install the ttf-msfonts-installer package and fiddle around with font settings to get the “standard” web fonts and make sure they render without looking iffy.

Given the Raspberry Pi’s meagre CPU and the trouble it has rendering complex layouts, I’ve given some thought to an alternative “quick” approach that consists of simply running a VNC client on it and pointing all the clients to a server with “proper” WebKit.

CPU load and bandwidth usage on the server should be negligible up to dozens of clients, but this falls down on the board’s side due to the lack of accelerated 2D graphics both in X and in the framebuffer, as well as a buggy directvnc package in Raspbian that doesn’t run without some coddling.

Comparison with an Android device clocked at about the same speed isn’t favorable - screen updates are immediate on my Nook Color via Wi-Fi, whereas the Raspberry Pi visibly struggles to update anything larger than 800x600².

This should work much better than any alternative, and yet infuriatingly doesn’t, so I’ll revisit it later on as soon as better 2D graphics support becomes available.

The good news is that I’ve been able to get a few Python scripts running to display still images via framebuffer (via pygame) and OpenGL ES (using a modified version of pi3d and mapping the image onto a quad), but it’s a pain to lay out content that way - not to mention being unable to do anything sane involving text.

I’d love to use pyglet (with which I’m mostly comfortable with) since it does pretty decent text rendering as well as basic HTML layout, but, alas, it will require a fair amount of hacking to use it atop OpenGL ES.

Video works fine with the stock omxplayer binary, so playing a set of URLs from a web server is entirely feasible and will probably work for many use cases. Sadly, omxplayer doesn’t support multicast at all and the current VLC builds don’t leverage the GPU, so simultaneous/efficient and “true” streaming is right out for now.

But, if you’re planning to do anything involving multiple boards and screens, make sure you test across all your displays. HDMI detection seems to be flakey, with a DVI monitor and a pair of Samsung TVs working fine but an LG one causing it to lower resolution down into the 480p range…

The fix for that seems to be to force a specific resolution/mode in config.txt, but the bottom line is that you’ll need to be conversant with the peculiarities of the framebuffer device - so, again, test against the displays you’ll be using.

On the Qt side, things are a bit harder, at least for now - which is sad, since signage is the kind of thing QML is nearly perfect for, but also to be expected, given the general status of affairs.

There aren’t any armhf Qt binaries yet, and even though there is a working standalone image and a few packages from last May, I don’t see much point in using anything but Raspbian from here on out, so we’re a bit stuck waiting for updated packages.

In the meantime, Delfim and myself are trying to get Qt5 built for armhf.

I decided to try cross-compiling it on Ubuntu 12.04 (which is where I build my Android stuff) but am still stuck sorting out toolchains, build options and dependencies - it’s a right pain to build it natively, let alone cross-compile - whereas last I heard, Delfim was starting to get V8 built on the Raspberry Pi itself.

We started four days ago, and I expect the whole thing to last until next Tuesday or something at his end.

It’s inevitable that I should compare the Raspberry Pi to the MK802 Android PC for a number of reasons, not the least of which is that I happen to have bought one in the meantime.

I got the MK802 as a way to get hold of what I expect to be a relatively popular class of hobbyist Android devices, and also because it is far easier to get anything web-related working on Android than on the Raspberry Pi - not to mention that there are plenty of apps for regular folk to enjoy.

The MK802, being a finished product sporting four times the RAM and a faster CPU clearly trounces the Raspberry Pi in general terms, even as it inevitably falls somewhat short of the ease of use and performance shown in those Kickstarter demos largely because it has a pretty slow internal flash.

Disregarding differences (and a slight handicap) in overall connectivity (Wi-Fi is great, a single usable USB isn’t when you’re trying to develop stuff), the OS alone makes it a lot more appealing than the Raspberry Pi for most purposes, and it makes for a halfway decent little “all in one” desktop if you plug it in to a monitor with a USB hub.

But I’ll happily concede that the Raspberry Pi is a lot more appealing for most people.

Android Pie

In the meantime, and no matter what eventually transpires regarding my little signage project, I’ve decided to investigate porting Android to the Raspberry Pi - this is not guaranteed to go anywhere (and likely won’t given the upcoming Summer break), but I’ve started putting together a kernel over at github.

It builds on my cross-compiler setup, but there’s a lot more to do beyond that.

Have the appropriate amount of fun.