Important: Please read the Qt Code of Conduct -

Qt on embedded platforms and "QT for embedded linux"

  • As I read on docs, forum, blogs etc, I understood that is possible to configure QT-Creator suite with a modified retail version to compile on embedded linux platforms, and I imagine this is the case where the platform itself include a linux version with X11.

    There is also a QT for embedded linux that is an alternative to the X11. Does someone know why this is a commercial version only ( ? Ore there is something I don't understood / missed?

  • You can configure the usual qt-everywhere package such that it cross-compiles for your target platform (as long as your cross-compiling toolchain is working of course).

    When working with embedded projects I have (at least) 3 builds of Qt on the go:

    Normal X11 build of desktop Qt (well my entire KDE desktop uses this as does qt-creator)

    Host platform build of Qt embedded. This can be run locally but uses the virtual frame buffer for display rather than X11.

    Target platform build of Qt embedded. This is what I build against and copy onto the target device.

    To build the host embedded version I use something like this to configure Qt:

    ./configure -prefix /usr/local/qt-embedded
    -embedded -qt-gfx-linuxfb -qt-gfx-qvfb
    -qt-gfx-vnc -no-largefile -exceptions -no-accessibility
    -no-qt3support -qt-zlib -no-gif -no-libtiff
    -qt-libpng -no-libmng -qt-libjpeg
    -openssl -no-nis -no-cups -no-pch -depths 8,16,18,32
    -qt-kbd-tty -qt-kbd-qvfb -qt-kbd-linuxinput
    -qt-mouse-linuxinput -qt-mouse-qvfb -qt-mouse-pc
    -commercial -confirm-license -silent

    followed by the usual make && make install.

    And for the target built I use:

    ./configure -xplatform qws/linux-i486-g++ -embedded x86 -prefix /usr/i486-pc-linux-gnu/usr/local/qt-embedded
    -qt-gfx-linuxfb -qt-gfx-vnc
    -no-largefile -exceptions -no-accessibility -no-qt3support -no-sse2 -qt-zlib -no-gif -no-libtiff
    -qt-libpng -no-libmng -qt-libjpeg -openssl -no-nis -no-cups -depths 16
    -qt-kbd-linuxinput -nomake demos -nomake examples
    -qt-mouse-linuxinput -qt-mouse-tslib
    -commercial -confirm-license -silent

    You can then build your app against the version that is most useful at the time. Usually the host embedded build until you are ready to try it on your device.

    When running apps built against the host embedded build I launch the qvfb application and then my app and pass in the -qws argument on the command line. The app then gets displayed inside of the qvfb app as if that was my device.

    Feel free to come back with more questions if you need any more info.

  • Thank you, you are great!!!

    If you like I can tell you more about what I am doing by mail, else asap next days I startup a public project about these developments.

    At the actual date, I am planning the best (and right) way to develop with a new platform based on NXP Arm processor LPC3250. The clear explanation you wrote - very very useful!!! - clarify and well describe what I had in mind and what I was supposing.

    As a matter of fact there is another way, I saw and I am undecided what "top" way I can follow.

    What you have wrote implies that there is a linux embedded on the board (I am using ltib toolchain that is working fine) that include an X11 environment so the environment can host the Qt embedded aplications.

    The other way - I have no informations, I only know that it is a possibility - is to create a Qt-graphic environment as an alternative to the X11 delivered with ltib toolchain (that is twi based on framebuffer display and touch screen device ad main input device). What do you know about this alternate choice?

    Or, reading your post, this is a complete alternate way to X11 that became and excluded package remaining on my embedded linux only the fb drivers?

    Many thanks.

  • Yes I am keen to hear what embedded project you are working on.

    Since your embedded system has a working X11 you can choose to go either way:

    • cross compile Qt-X11 (ie desktop build) for your target device. To do this you will need to either have a cross-compiling toolchain and all needed headers and libs on your build machine or you will need a compiler on your target device.

    • Use the approach I described above and run Qt-embedded using the Linux Frame Buffer and the QWS window system (supplied by Qt).

    The decision is up to you. Some things to consider:

    • Does your device have enough memory to run a full X11 session lus your app?
    • What sort of boot time do you need. Using Qt-embedded will mean you can get your app up and running faster than if you use X11. We use a Linux kernel plus an initramfs containing a simple startup script and our application. This allows startup times of only a few seconds (depending on what your app needs of course).
    • Is you app the only one running on the system or does it need to interact with other X11 apps?
    • Do you need OpenGL acceleration? Does yoru board provide OpenGL ES drivers or do you only have X11 OpenGL drivers?

    Good luck!

    ps I'll write up the embedded building guidelines on the wiki at some point.

    pps I found that the Gentoo tool crossdev is really awesome for setting up a cross-toolchain.

  • For info, I have started writing up a series on Qt for Embedded Linux on the "wiki": Still lots more to do yet but it's a start...

  • Thank you again ZapB!

    I have thought about your suggestions and I have also found what you means: Qt for linux, that is the right alternative to other graphic interfaces like twm. The toolchain I use is ltib, while the embedded platform is based on LPC 3250.

    At the actual date, I have not yet posted nothing on the forum nokia, but I have the development board that works withXephyr installed on it. I think that in effect the approach you suggest to use Qt as the graphic environment should be the best choice saving memory. And probably saving time too.

    Do you think that a group on embedded development can be useful on developer forum here?

    Later I read the wiki pages, then I tell you about.

  • Yes an embedded group could be potentially useful.

  • Yep! It's a very good opening that wiki. Can I participate? It maybe useful beside your guide some pages that report examples of a real work while it is done ?

  • Of course. It is an open wiki so feel free.

  • Sure, I know that it is an open wiki, but a minimum of coordination can help so the wiki is readable also for the community

Log in to reply