The importance of KDE hardware


Those days I’m giving the final touches to what will be the image of the operating system that will be preinstalled on the Improv board.
Does it work? Yes:

Plasma Active on Improv

Blurry exibit #1: Plasma Active running on the Improv

KWin compositing

KWin is one of the few X11 window managers (and the only desktop-grade one) that can do composite on GLES devices (withut GLX)

Now, a little backstory: A while ago the Plasma team received a bug report about the popups in the Plasma panel. apparently they couldn’t receive any mouse event, and this happened on ARM and only on ARM.
This type of bugs are quite weird and difficult to catch, especially when they happen only on an architecture none of the developers is using as development machine.
And while it was possible already to test KDE on ARM devices (we got the bug report in the first place after all), it has never been easy (also helped by the fact most ARM deviecs are as close as you can get, especially the reasonably high end ones).
Not being easy means that it takes a long time to do… not many KDE developers have the time to go trough all the hassle to get a build environment working on an ARM device, and this means bug stays.
When working on the Mer image for the Improv of course i stumbled upon this bug as well.
But wait.. there we have OBS: testing patches on a single package it’s a matter of minutes, thanks to how much easy is to branch a package in an home project (Heads up to OBS developers for this).
In a couple of hours the problem was identified and fixed. In this case is an ARM specific ugly workaround, but luckily won’t be needed with Plasma2 (basically mapping from a QMouseEvent on a QGraphicsView to the QGraphicsSceneMouseEvents on the QGraphicsScene breaks on ARM when the item is at positions farther that (-QWIDGETSIZE_MAX*2, -QWIDGETSIZE_MAX*2), due to different sizes of data types compared to ia32/x8664).

Hardware like the Improv, that comes with KDE preinstalled with an easy way to test out development and patches may really contribute to increase the quality of KDE software on that devie class.


You need to test your software on another kind of device? Just pop the CPU card out of one and pop in into another, without having to setup the same stuff multiple times.

I dream in the future more and more “KDE first” devices, from mobile devices to laptops, to workstations, to set top boxes, both ARM and x86, from many different manifacturers.
They are good not only for who is making them. They are good for KDE software, for KDE developers and in the end for all of our users.

7 thoughts on “The importance of KDE hardware

  1. Ernesto Manríquez

    Marco, I’m echoing that question and adding: I’d really know how does the Semantic Desktop perform. I’ve found troublesome to run the whole Semantic Desktop with 1 GB of RAM, but then, I’m using the full Nepomuk+Akonadi stack, with Google, Facebook, Telepathy, kpeople, etc. How does that run on the Improv? Will something be done to shrink the Semantic Desktop to be usable for someone who has 1 GB of RAM? Or, alternatively, will you sell a 2 GB version of Improv?

    1. redsteakraw

      Well given this is a EOMA68 card board the improv is upgradeable you would just need a different CPU card. Currently the A20 board you see is the only EOMA68 card on the market but there may be more. I have some devices with 1 gig and they can still hold up. but more is usually better. At the very least this could make a killer micro server or media center / server. The ability to run KDE is a rather cool bonus. At the very least this will be a whole lot more capable than the Raspberry Pi and that was used to do all sorts of things. You don’t have to use this as your primary work station machine, you could just use this a a jukebox for your TV or a video player or a dedicated Mumble client box . Or maybe a box to mess around with home automation. And maybe when they have more enclosures and cards you can re-purpose the card for a different use and upgrade the Improv.

  2. Kevin Kofler

    You also probably saved the Fedora 20 release that way. 🙂 This issue had been declared a blocker, ARM being a primary architecture in Fedora nowadays. Thank you!

Comments are closed.