Introducing Boot to Qt – A Technology Preview

Published Tuesday May 21st, 2013 | by

For a few months now, we have been working on a new project under the codename Boot to Qt, and today we launch it as a technology preview.

Boot to Qt is a commercial offering that provides a fully integrated solution for the creation of slick user interfaces on embedded devices. The offering includes:

  • A light-weight UI stack for embedded linux, based on the Qt Framework – Boot to Qt is built on an Android kernel/baselayer and offers an elegant means of developing beautiful and performant embedded devices.
  • Ready-made images – We have images for several different devices which include the Boot to Qt software stack, making it possible to get up and running with minimal effort from day one.
  • Full Qt Creator Integration – One-click deploy and run on hardware and a fully featured development environment.
  • Simulator – A VirtualBox based simulator which allows device development without hardware and opens up for simulating hardware input, such as GPS and  connectivity.

This technology preview focuses on the stack built on an Android baselayer. We also want to provide a similar software stack and the same convenience with ready-made images and IDE integration also for traditional embedded Linux, hopefully with a preview coming some time this summer.

We are expecting to have an official release towards the end of this year.

The following video shows Boot to Qt in action on our reference hardware:

And the following video show the Boot to Qt SDK works:

Scope of Boot to Qt

The software stack includes most of the Qt Framework:

  • Qt Core, Qt Gui, Qt Network, Qt Widgets, Qt Xml
  • Qt QML and Qt Quick
  • Qt Quick Controls
  • Qt Graphical Effects
  • Boot to Qt specific additions, including virtual keyboard, brightness control and power off/reboot functionality

The hardware devices supported in the Technology Preview are:

This is not a fixed set, but a place for us to start. If you have suggestions for other devices, let us know. The stack can also run on x86 hardware.

Right now, the stack is single-process. The launcher is a QML application which launches other QML applications in-process. We have looked briefly into using Android Gralloc APIs to do multiprocess sharing of hardware buffers, and we know it can be done, but we consider this out of the 1.0 scope.

We have also had similar discussions around Multimedia and Webkit, we want to have them in place, but maybe not in the initial release. The current software stack is already quite powerful and serves a number of different use cases.

Performance

Qt 5 introduced a new OpenGL ES 2.0 based scene graph to power Qt Quick 2. This makes Qt Quick very suitable for running on embedded hardware, even those with moderate specs. The demo launcher we ship with the images for instance, runs velvet at 60 FPS on all our hardware devices.

We were looking at CPU usage while playing around in the application launcher on the Nexus 7. When idle, it uses a shader to add a glow on the currently selected item and has a small particle system on the Qt logo in the corner. We found that when the launcher was just animating the glow on the active item and running the small particle system on the Qt logo, the CPU load was running at about 50%. When we flicked it, it dropped to 30% and when the finger was down and we were moving the list via touch, it dropped to below 20%. So it seemed that the more we did, the less the CPU load became. What we were observing was CPU frequency scaling. The CPU is a Quad-core clocked at 1.2GHz (with a special 1.3Ghz single-core operating mode), but when idle, it had disabled 3 cores and had scaled the one remaining core to 102Mhz. So we were able to animate a large part of a 1280×800 screen at 60FPS on a CPU clocked at 102Mhz, and were still only using half of that. 

For reference, the same animation runs at 2% CPU on the i.MX6 and 15% on the Beagle, none of which does do frequency scaling.

We also have pretty decent startup times. Below is a diagram comparing Boot to Qt to native Android. Now of course, full Android brings in a lot of additional stuff, but that is also the point. Most embedded devices do not need that.

Startup times, in seconds, from power-on until device reaches the B2Qt launcher or the Android Homescreen.
Lower is better

This is not too shabby, but we believe we can cut this down a bit more, at least when we start exploring various embedded Linux configurations. As an example,  Qt 5 on Raspberry Pi can start rendering after as little as 3 seconds.

Getting Access

For more information, see the product page.

Boot to Qt is available for evaluation upon request. If you want to try it out or if you are just interested in the software, please use the contact form on the product page and we will be happy to get you started. Of course, feel free to leave comments and questions on this blog too.

Enjoy!

Did you like this? Share it:

Posted in Embedded, Qt

78 comments to Introducing Boot to Qt – A Technology Preview

Dean says:

I imagined a “lightweight” UI stack would be liberated from the burden of Java/Dalvik…

Samuel says:

It is lightweight, Android baselayer here means bionic and graphics drivers / other hardware abstraction layers etc, not Dalvik. The Qt application runs fully natively.

Dean says:

This is good news then. IMO the post should mention Java and Dalvik have been “uprooted”.

Tuukka Turunen says:

@Dean: See the product page with some more info, including an image to explain this: http://qt.digia.com/boot-to-qt

Alfred Tilo says:

Aren’t you tired of being *used*, while they just *pretend* to *care*??????

Lilian says:

If it uses the Android kernel it doesn’t mean that it also uses the Dalvik.
I think they chose to use the Android stack because of the hardware support and I doubt there is Dalvik running on it.

Gunnar Sletta says:

@Lilian: This is correct. We’re providing a solution based on an Android baselayer as the driver support is excellent, but there is nothing running from the traditional Android stack, except for parts of the bootup. There is no Dalvik, Zygote, SurfaceFlinger or any of the other parts that make up the bulk of the Android software stack.

Alejandro Exojo says:

For those of us who don’t like Android much, or simply don’t know it well, what other parts of Android are you using? If is just a branch of the Linux kernel, plus a custom C library (bionic), then is not much different from other embedded Linux environments, which is good.

Does Android have some special framework/service/whatever for the drivers that make it special, or is just that those drivers use features in the Android-patched kernel (wakelocks, etc.) that are not portable with the mainline Linux?

Thank you.

Gunnar Sletta says:

We are using very little of the Android software stack, though I don’t have a complete list of what we’ve stripped out in my head. In this release, most of the android binaries are files are still there, but we are in the process of removing the unused ones (all apps, frameworks, etc). It is very much like embedded linux, which is why I mention us wanting to have an embedded linux based release of this later.

There is nothing special with Android drivers, other than that they are there and standardized.

Jason says:

This looks awesome, I’d love to see a community release of this. Maybe for the Nexus 7? I can’t imagine anybody would use that for production use, with the big ugly Google bootloader

7 says:

30-day technology preview evaluation? Does this mean digia will now be selling trimmed down android?

Tuukka Turunen says:

@7: As part of the complete stack, yes. Naturally Android base is still open-source and it’s licensing remains unchanged.

7 says:

I am a little unclear on how does one actually take something that is free, removes even more stuff from it, and asks money for it… It just doesn’t sound very ethical, even relative to corporate standards of ethics, which are about as low as it gets.

Gunnar Sletta says:

@7: Though it is true that we incorporate a number of different open source projects in Boot to Qt, we also spend the effort in preparing ready-made images for hardware, integration with Qt Creator and a simulator. In addition to a lot of work on the implementation side. All in all, lessening the pain that embedded linux development can be.

Pavel says:

So it was nothing but an integration exercise. Except it didn’t even integrated properly; downgraded to single process model, lacks fundamental stuff like multimedia acceleration and devs will need to get hands dirty with bare C++ most of the time because of narrow QML APIs and capabilities.

qtnext says:

what is the plan regarding multimedia : I mean access to gstreamer with full accelerated video decoding to opengl qml texture ? and access to a way to customise video rendering : for example for now it’s unpossible to have a seamless loop with video on Qt ?

Gunnar Sletta says:

@qtnext: Qt Multimedia on normal linux uses gstreamer, but encapsulates most its use behind the scenes, but as you can see with http://www.youtube.com/watch?v=P4kv-AoAJ-Q, we already get the OpenGL texture and can do whatever we want with it (since Qt 5, that is). Creating a seamless loop should be possible in QML already, but you would need two MediaPlayer’s and two VideoOutput elements and then opacity-fade between them.

Hardware vendors typically provide OpenMAX drivers for multimedia on Android though, so it is not all that likely that we will be using gstreamer in Boot to Qt for embedded Android.

Pavel says:

Which means you’ll need to use stagefright, which means your thin android stack will have to get a bit thicker for hw accelaration in multimedia.

DavidB says:

Is this a single app framework or a complete embedded desktop framework much like what Qtopia was? I hope it is the latter,as Qtopia 2 was a pretty nice embedded GUI desktop that provided IPC and memory management.

Prior to Android, chances were very good that if you stepped into any hardware booth at a Linux embedded conference, they were demoing with Qtopia. It would great to have such a embedded window manager again with Qt5. If this indeed what B2Qt is, it would be nice to see board support platforms support it as a third ecosystem(joining Android and Windows CE), but to do so would probable mean releasing a free version. There are a lot of ups to this, so please consider this.

Gunnar Sletta says:

As the blog states, it is a single process solution, but we want to expand it to a multiprocess solution with wayland as the protocol for the windowmanager long term. We don’t currently have a plan to reimplement a full embedded desktop with apps and all though.

Donald says:

w00t! So ducking cool to see you people land this turkey. I discussed this over several pipes with Johannes and Girish from CES 2011 to last year, and it is glorious to see you people actually get it nailed down and immediately bringup-able on various shipping hardware. The inclusion of the Beagle board makes me want to pee blood. (again). I hope every customer I visited who was strong armed into Android by the chipset vendors picks up on this development, and that it gets due adoption. Shaving down the startup time is one hell of a likely point of flattering comparative advantage, so you people should definitely hammer on that. Instance on Qt on standard Android hardware would be kinda hard to compete with. (I have no clue how crud their software stack is, not what kind of evil you are forced to endure)

I am glad Digia is financing this and that they have a revenue model. Quite humorous to see some someone in the comments entirely miss the bus (yet again) and try to impose harsher requirements than those actually mandated by the license agreements. What you are doing is legal, but against some moral code which apparently mandates insolvency. Zealots make me want to brush my tongue.

7 says:

There is a lot of really despicable stuff you can legally do. Legal is not a synonym of good. Digia already got Qt on a silver platter, almost for free, just to milk. I myself feel further attempts to make money on the free work of others just keep pushing it towards “patheticness”. Surely, people will stick to Digia while there is no other alternative, but once such pops up, I can totally see people fleeing Digia and their greedy business model. What is next, Digia selling air?

Thankfully, there are plenty of lightweight distros out there.

Jason says:

Huh? Digia and commercial Qt were around and making money long before Digia took the reins

Hesekiel says:

Yes, eventually you will also realize humans are printing money long before you were born. You are all just being used in that company..

Slartibart says:

Dunno what world you live in, but in the real world developers also needs to earn money somehow, and one of the ways this can be done is through integration and support. Feel free to be despiced by developers trying to earn money for their work, but don’t be surprised if you’re being ignored.

7 says:

I am such a real world developer that makes his living on this. And it has nothing to do with this. Digia is exploiting the trolls just like their costumers, the trolls will be much better on their own than to be milked by Digia. I am all for efforts being rewarded, which means 100% of the income goes to the developers, not to some greedy company that makes money on everything it can get its greedy hands on, including the free and open work of many people who will not get anything from Digia.

Slartibart says:

Anyone making money is by definition greedy, meaning Digia is no different than RedHat, Google, Microsoft, Apple, Linux Foundation (shokingly they also occasionally make money!) etc.

So the “interesting” question is (when we are in the subjective mode of nurturing fallacies): Is Digia in any significant form more “greedy” than everyone else?

7 says:

@Slartibart – if you work for what you get – you are not greedy but hardworking. If someone can’t help but look for more and more ridiculous ways to make money on others – that is greed. And YES, MS and Apple are pretty bad too, as for google and various linux oriented organizations – at least they are committed to the open source community and don’t employ double standards.

power says:

How about comparison of battery power consuming and heating? Have you measured ?

Pavel says:

Utilize gralloc APIs all you want, shared HW buffers has little to do with multi__processing__, which you lack, which dalvik doesn’t.

7 says:

Yeah, but dalvik sucks complete ass when it comes to performance…

Pavel says:

Because QML+javascript won’t suck even more unless you bother with C++.

Slartibart says:

Abuse C++ and it easily sucks more than both Dalvik and Javascipt combined.

terry says:

But when you need better control(in the world of embedded, we always need), c++ give you more power.

Samuel says:

Noone is claiming you need to do the heavy lifting in JavaScript. For UIs however QML has been shown capable of providing excellent performance.

7 says:

I disagree, it is quite easy to bring QML to its knees with the way property binding is implemented. The feature is implemented in a way that promotes misuse.

Samuel says:

7: Have you reported these use cases that bring QML to its knees and the implementation issues of which you speak in the bug tracker?

Slartibart says:

C++ is even easier to bring to it’s knees if that’s what you’re trying to do. Hovewer, what’s relevant is whether JS is a good alternative to XML (which was used previosly for declarative UI). If you have any other alternatives for dynamic UI setup, feel free to share.

By comaring C++ to JS in terms of excecution speed (and blatantly ignoring what it is supposed to be used for) just shows how little you know (or care) for using the right tools for the right job.

7 says:

Even more so in terms of memory efficiency.

Diego says:

Hi,

This is impressive! I look forward to obtaining an evaluation copy. I have a question…is there an android version requirement for Boot to Qt? meaning do I have to have a device running above a certain android version? is Android 2.1 OK or do I need a higher android version?

Thanks

Gunnar Sletta says:

@Diego: Boot to Qt requires a 4.0+ Android baselayer to run as we focus primarily on newer embedded hardware, but Qt for Android (which lives side-by-side with Dalvik and the rest of the Android stack), can run on Android devices from 2.3.3 and later (http://blog.qt.digia.com/blog/2013/03/13/preview-of-qt-5-for-android/)

Julien says:

I assume this is related to the work you did to pave the way for Canonical and Ubuntu Touch. Good stuff.

d3fault says:

Isn’t this one of those cases where… sure they can sell it… but anyone who buys it can then turn around and distribute it for free?

See: RHEL/CentOS

Looking forward to CentB2Q <3

Tuukka Turunen says:

@d3fault: There is quite much more in Boot to Qt than just the Android base, for example Qt libraries, optimizations for Qt, additional components, tooling, emulator, support, services, etc. When you are a business developing embedded devices things like time to market are typically really important. We want to make it a bit easier and faster to succeed with Boot to Qt.

7 says:

I assume that like with everything else, you will target the enterprise with ridiculous prices and ignore small time independent developers as well as the open source community (which BTW made this most recent Digia exploit possible)…

Jason says:

Lighten up, Francis

Eduard Yegor says:

Feels like the revolution is just kicking. It’s awesome to know that things change with time..

d3fault says:

so…. Digia embracing the dual licensing business model was just marketting speak after all?

Where’s my Charts also!? Not that I care about charts (lol ez)… but it’s a demonstration of Digia’s [lack of] committment to the open source community.

Kind of glad Nokia LGPL’d Qt right about now… because Digia never would have… given everything they’ve done since purchasing it…

Getting back to the technicals: can’t this theoretically run on every Android device released :-D? Would love to see this give life to my Droid 1… thing runs slow as molasis with Dalvik…

Joker says:

Awesome! Boot to Qt is just what I imagined. Nowadays, we don’t need more kernels, since they are actually duplicated(90%). So use their kernel and do what we want. I suggest Digia to release a ‘Qphone’ based on B2Qt:)

[…] has recently announced Boot to Qt Technology Preview, a commercial offering that provides a solution for the creation of user interfaces on embedded […]

[…] Qt Blog introduces “Boot to Qt”, which is “a light-weight UI stack for embedded linux, based on the Qt Framework – Boot […]

[…] zum Erstellen von Benutzeroberflächen für Embedded Devices entwickelt. Die jetzt vorgestellte Technologievorschau kombiniert das Basissystem der quelloffenen Android-Plattform mit einer Bedienoberfläche auf […]

Nicolas says:

Nexus 10 please!

[…] Qt Blog introduces “Boot to Qt”, which is “a light-weight UI stack for embedded linux, based on the Qt Framework – Boot […]

Anonymous says:

Aw, come on.

The RPi teasing in the video for that commercial-licensed version just breaks my heart. I can’t wait for your Summer.

Shann says:

Seem great solution and alternative to Dalvik JVM.
The design of Qt for mobile device is good for users (also KDE ;) ).
I try this when i have a time.
I have a question, Boot to Qt will opensource or commercial licence ?

Tuukka Turunen says:

@Shann: Boot to Qt package, including new tooling, components, and the integrated delivery is only available for paying customers. Qt is dual licensed, and thus also available as open-source, as well as naturally the Android base layer. The idea is that in order to get the benefits the integrated Boot to Qt package brings for embedded development, including support and services to enable Qt on your HW, there is a commercial relationship established with Digia.

John Smith says:

If this isn’t open source, I hope the project dies a quick but painful death.

John Ankcorn says:

Very, very, very glad to see that you are pushing this forward!
It is so clean/stable to build on top of this Android adaptation layer, it seems perfect for Qt.
(and their bootloader/core stuff is so tight, much better than all the alternatives)

Thanks very much for getting this to product!

Bruno says:

That is amazing !
I pretty sure that those who are complaining about the the non-free nature, are ignorant selfish who think that profit is wrong.

Guys, getting Digia, Kdab, Intel, Rim, Woboq profit is our best interest. Without it Qt would become abondonware as I see as impossible to push the quality Qt without a profitable company behind.
Continuous integration, Quality assurance, Infrastructure maintenance, Testbed, boring bugs to fix ( Windows XP maintenance)…

Cuba is very near, please go there ! Or use other options who are doing WAY better the Qt , such as Gtk+ and wxWidgets !

Barak Ataullah says:

Hey guys, Diggiiaa is just exxpploitingg cheap labor. Elop makes more money in one month than all of you in one year. Ow wait, that’s another company..

udemzy says:

What of the n9 can’t it be used here. The specs is similar to the Beagle Board xM

[…] acuerdo con el blog de Qt, Digia lleva unos meses trabajando en este proyecto que ahora presentan como “technology […]

Drahoslav Oldrich says:

See how this company will handle you in the near future.
http://www.digia.com/Global/DigiaWeb/Images/career_images/1/careers_new_550x301.jpg

7 says:

That image shows the activities of the Qt management. Fly paper planes and wait for hardworking people to do their thing and leach on it.

Stefan says:

Hi,

This sounds interesting but can you explain me what is the actual benefit from using Boot to Qt instead of using e.g. a yocto based Linux with QT?

And how easy would it be to integrate new hardware BSPs for Boot to Qt, will it be possible to compile the whole file system + kernel from within qt creator?

Thanks

John Ankcorn says:

With the use of Apache2 licensing, vendors supporting Android are allowed to leverage binary libraries for OpenGLES, video codecs and cellular modem interfaces. It has allowed the refreshing experience of using linux and other open source frameworks, while getting the benefits of good hardware acceleration. (hw vendors typically are unwilling to publish the interfaces directly to the hardware for fear of letting themselves open to a wide variety of patent-troll lawsuits)
Of course, everyone would like to receive source code, but getting these well-supported binary libraries is much better than not being able to use the hardware at all!

It was quite nice to get high-quality, low-bit rate, SD video running on a Galaxy Nexus with only 10% CPU usage.

ashwin says:

i love you digia. for qt

rattus says:

Very interesting… would love to see this on embedded Linux, perhaps with a Beaglebone target!

Ada says:

Superb site you have here but I was wanting to know if you knew of any user discussion forums that cover the same topics discussed here? I’d really love to be a part of community where I can get advice from other knowledgeable people that share the same interest. If you have any recommendations, please let me know. Thanks!

Tuukka Turunen says:

@Ada: For example: http://qt-project.org/forums/ contains many discussions on Qt. Boot to Qt as such may not yet contain much discussion there, but other topics do.

Swen says:

Do you mind if I quote a couple of your articles as long as I provide credit and sources back to your site? My blog site is in the exact same area of interest as yours and my users would certainly benefit from some of the information you present here. Please let me know if this ok with you. Thank you!

Geneva says:

Good day! Do you know if they make any plugins to assist with Search Engine Optimization? I’m trying to get my blog to rank for some targeted keywords but I’m not seeing very good results. If you know of any please share. Many thanks!

Ethel says:

Your web site seems to be having some compatibilty issues in my firefox browser. The wording appears to be running off the page pretty bad. If you want you can contact me at: ethel-saddler@gmx.de and I’ll shoot you over a screen shot of the problem.

[…] we found out about some work that the folks at Digia are doing for embedded developers. Known as Boot To Qt, this upcoming offering does precisely what many of our customers need: boots quickly into a […]

[…] we found out about some work that the folks at Digia are doing for embedded developers. Known as Boot To Qt, this upcoming offering does precisely what many of you need: it boots quickly into a Qt-based […]

Commenting closed.