We live in a world which, nowadays, tends to be digital. A world which rarely shows gratitude, except where it is mechanically mandated by social formalities of the community. Some could say that it reminds a giant assembly machinery. But there is always room for special surprises, when somebody avoids to get dragged by the inertia and does the unexpected.

Yesterday was the first time I received thanks, by non-electronic mail.

This is the public release of zenvoid-desktop, a desktop environment for tablets and mobile devices. It provides a minimal user interface for performing basic operations such as launching applications, switching between running tasks, entering text with an on-screen input method, showing battery status or changing the screen backlight level.

zenvoid-desktop is composed of a small set of packages, everything else is provided by the GNU/Linux distribution laying under it, which is Debian in the provided filesystem images.

I’ve been using several mutations of zenvoid-desktop for several months now, running on diverse hardware. All versions were different, testing different configurations for each one; and due to requests I’ve been receiving, here it is the first attempt to unify and release it.

Applications do not need to be ported, they are the same applications made for traditional desktop computers. Combined with a root filesystem, provides a quick and convenient way to start hacking a device. It is important to notice that, while it is very convenient to run the same full desktop applications without changes, they are definitely not comfortable to use on tablets. No matter how friendly those screenshots seem to be, this is not a finished, friendly environment for daily usage. It can be seen as a bare minimum environment to resurrect otherwise “dead” hardware, when manufacturer does not develop its operating system anymore, or when the original operating system contained proprietary software (almost always sadly).

Basic instructions

Main application windows usually start in maximized state while dialogs or special windows start in a floating window. If the window title is tapped when the “secondary action” button is active, it will reveal a menu with common window operations (maximize, minimize, resize…).

Input method

The purpose of the input method applet is to allow entering text with a touchscreen, either by an on-screen keyboard or by handwriting recognition. It is based on CellWriter, modified for zenvoid-desktop. It can switch between different keyboard layouts, which are installed under /usr/share/zenvoid-input-method/keyboard/. Layout files are currently not documented, if you want to make a new one, try looking at the included layouts, they are plain text files.

After a few unsuccesful attempts to modify an old camera for infrared photography, I modified one of the two cheap cameras ($40 USD) that I’ve got some time ago. Those cameras are cheap and tiny, usually came embedded inside pens or keychains.

Due to their size it is quite common to modify or attach those cameras to a variety of places; think, for example, to attach the camera to ballons for aerial video, radio controlled planes, helicopters or other vehicules, or seal it inside an empty bottle for underwater photography, just to mention some random uses that came to mind.

It was on a RC forum thread where I first read about removing the infrared filter in those cameras, along with a lot of useful information.

The infrared filter is a thin circular element located on the rear of the lens. It was needed to carefully remove the glue around lens thread, but the overall process of removing the filter was much easier than expected, specially in comparison with any other camera I’ve tried before. Colors are distorted without its infrared filter, but in return it recieves more light, sensitivity improves, and it can be used as a “night vision” camera.

Once assembled and refocused, the first test was quite simple: let’s see the infrared light of a remote controller. The modified camera captures the light, while it is invisible to the other (as our eyes).

Next step was to block the entire visible spectrum, in order to capture infrared exclusively; that is, the inverse effect than the one performed by camera’s internal infrared block filter. I’ve used a filter designed for infrared photography, a piece of glass that looks black and completely opaque to our eyes, but not to the modified camera which can see through it.

The quality of the pictures straight from the camera is far from great. I’ve done the following:

Recorded a video (1280×720), saved several frames, selected the center area of each frame to avoid the (quite noticeable) vignetting and blurring in the corners.

Constructed a large panorama using all pieces.

Applied a heavy noise reduction algorithm. Images loose detail, but noise levels were very high and ugly in the originals. As a side effect, the image enhances its artistic painting appearance, not so bad after all.

The original has a red or pink tone because the filter allows some deep red to pass through it. A deeper infrared filter should produce black and white images and only purely invisible light would be recorded, supposing that camera’s automatic white balance won’t become crazy, this is something I want to test later.

A common effect for infrared photography is to switch red and blue channels (if the filter allows some red to pass), or just modify color channels and give a fake set of new colors to the image.

Infrared photos tend to look surrealistic. We normally can’t see the infrared light reflected by things, hence the strange appearance. Sky becomes dark (blue is easily removed by the filter), clouds are bright and prominent; green trees and grass reflect a lot of infrared light and become very bright, while dry plants remain darker.

Admitedly, I’ve always been interested in LEDs. High intensity LEDs across the entire visible spectrum are easily available nowadays, so providing a science fiction spaceship look to the house was tempting enough :)

Still trying several things, but these are a few conclusions so far:

RGB LEDs (composed of three smaller LEDs) can emit light in any colour by mixing the three primary, and theoretically one could build a wide set of lighting effects with them. The big limitation is in the controllers, though. Commercially available controllers (also known as dimmers) for RGB LEDs are cheap but usually quite boring, in the sense that they offer no more than fixed colours and very limited blink or shading effects to choose from. Not a big surprise. It would be much more fun to have programmable controllers, or at least a wider set of options built-in.

A very interesting additional possibility would be to attach sensors or timers, and fade, switch colours or adjust intensity depending of time of day, day of week, outer temperature, music played in the room, or any other event. I’m sure that many people reading this are thinking about the Arduino, and me too.

Some sort of computer interface will allow to reprogram or control illumination parameters through a network connected tablet. And what about a webcam? We could detect motion events within a room and make the LEDs react to them… So, once again, it seems unavoidable to construct something. Please feel free to drop a comment if you know a better RGB controller already available, something hackable, or have an idea for making one.

On the other side, very succesful results were achived using “warm white” (around 3500K maybe) LEDs for general illumination. The color rendering index seems to be poor, though it shouldn’t be a problem for ordinary usage.

A floor lamp was modified to hold 3 10W LEDs and heat sinks inside. Actually, each LED appear to be internally composed of 9 smaller LEDs packed under the enclosure. They are OK too, but I think I prefer large arrays of lower intensity LEDs, seems more practical and they don’t need those huge heat sinks. Those 3 LEDs alone give a perceived light that’s maybe comparable to 150W halogen lamp (imprecise measurements done with a basic lux meter). It could be better if they weren’t running under an electric current below the specified maximum, because I’m not completely confident about the heat sink capabilities. The actual consumed power depends very much on the efficiency on the power supply plus power loss in resistors or intensity limiting circuits, but very efficient overall.

This is a continuation to the post about Ubuntu 9.10 in SmartQ 5. I keep getting a constant flood of emails that remind me that I should upload my patches, so here they are :)

Before giving more details I would want to recommend against using Karmic in your SmartQ 5. Installing Ubuntu’s previous version (Jaunty) is straightforward and it performs faster than Karmic.

When I asked in #ubuntu-arm about the performance regression I got no answer. I suspect that default compilation flags are responsible, most likely related to VFP. Slowness is most noticeable and annoying in interpreted languages, like Perl. So, unless some of the new features included in Ubuntu 9.10 (Karmic) are important to you, don’t bother trying.

My quick and dirty hack to the mountall package is able to boot with older kernels. It was not meant to be published, but here it is by popular demand. Keep in mind that it is only a workaround and not a proper solution, the contents of /etc/fstab seems to be ignored during boot, other programs may fail or require patches too, and there could be more hidden issues. Fell free to share your fixes.

I ran a quick test of latest Ubuntu and Kubuntu desktops in the SmartQ5, nothing serious, just installing and launching some applications for curiosity’s sake. KDE 4 feels slower than GNOME, but admittedly, both of them are too bloated for the hardware. Nevertheless, it was fun to play with a full desktop in such a small device.

I’ve included the excellent patch made by David F. Carlson, so the CPU will run now at 666 Mhz in its maximum performance setting (was previously set to 533) and memory timing parameters are optimized. The result is greatly improved performance.

Linux kernel must be named /boot/linux-SMDK6410.bin and there should be 2 MiB of free, unpartitioned space at the end of the SD card. To install the bootloader, use the install-smartq-qi.sh script:

./install-smartq-qi.sh /dev/SD_CARD_DEVICE qi-smartq-20091126.bin

Currently I have tested on a Q5 with the provided kernel only. Feel free to test and give feedback, but please, before doing so be aware that the software is for people who are not afraid of hacking their devices and maybe taking some risks in the process. It distributed in the hope that it will be useful, but without any warranty.

This is a cross toolchain for ARM that uses Ubuntu 9.10 compilers and libraries, so it (hopefully) maintains compatibility with the native compiler for ARM. Precompiled binaries for i386 and the complete source code with its build script are here: