Qt5 on ARM platforms
Qt5 on ARM platforms
Introduction:
This short post covers the background of Qt5, architectural details, configuring for eglfs with Graphics drivers, building, and known issues. This is to be used for porting Qt5 on ARM based platforms.
Qt5.2 (standalone) and QtWebEngine(preview) build steps available now at
(Nov 2013 update) It is now possible to build Qt5 directly from Yocto with meta-ti recipes for AMSDK, as most of the standalone patches are pulled into meta-arago.
5.1.0 final version (Aug 2013) information and build based on TI Sitara AMSDK/OMAP5 GLSDK is available at,
5.1.0 final version - build without SGX
Qt5 and C++, migrating widget applications / porting from Qt4 to Qt5:
5.1 version (Alpha, Beta1) information is available at,
For Qt5 (Dec 2012) release update, refer to
For Qt5 Webkit2 build, refer to
For Xcb builds, refer to the next post -
Qt5 Architecture:
Qt5 differences with Qt4:
Qt4 (Qt-embedded) exposed the capabilities of HW in 2 ways - HW that can accelerate rendering of widget surfaces (QPainter operations), and HW that can accelerate screen updates (of QScreen). So if for example an OpenGLES engine was used to accelerate screen display operations (using for example -display powervr), the same engine could not be used for accelerating rendering operations. So essentially, 3D and 2D acceleration mechanisms could not co-exist.
Qt5 tries to eliminate this gap. With the platform plugin approach - the HW "platform" is expected to provide OpenGL ES2, and any other additional HW acceleration on top of that as part of the platform. In essence - with GLES2 - every screen update in Qt5 happens via an OpenGL ES texturing operation, rather than any other means. In addition to this fundamental change, Qt5 brings in another major programming model update - that of QML, Qt3D etc.
A key note specific to our (SGX based) platforms - With the elimination of the display plugin, Qt5 no longer uses or supports blits via pvr2d or wsegl, and instead directly uses the egl (or window) capabilities exposed by the GL driver. This eliminates immediately a large portion of pvr2d/wsegl version related issues that cropped up in earlier Qt versions.
(ex patch for Qt4 in below link is not needed anymore)
The below platform plugins are available in the Qt5 Alpha package. Only "eglfs" and "minimal" are built by default in qtbase.
openvglite
platforms.pro
Qt5 Alpha source package overview:
Qt5 contains the absolute minimum required functionality - in "qtbase" folder. All other additional components (including Qt3D) are split into separate folders. Below is the folder structure of Qt5 (Alpha package)
qtdeclarative
build.dependencies
qtgraphicaleffects
qtwebkit-examples-and-demos
configure.bat
qtimageformats
qtwebkit.pri
qtjsbackend
qtxmlpatterns
qtlocation
qtmultimedia
Pre-requisites for Qt5 build:
- Qt5 alpha source package
- TI Graphics SDK (4.05 or later)- Recent filesystem (GCC 4.5 or later)- ARM cross Toolchain (GCC 4.5 or later), example from below:
Configuring Qt5:
Configuring Qt5 is fairly easy - and can be done without messing with creating new mkspecs, if the below are met:
- a linaro toolchain (linux-arm-gnueabi-)- sgxconfiguro is used (package config for TI Graphics SDK - egl and x11)- force-pkg-config is used
If this does not seem clear, the older tried-and-tested-method of specifying all possible (and needed) paths in the qmake.conf as below will also work :
The below method adopts the first approach and uses the standard Qt5 supplied linux-arm-gnueabi-g++ mkspec without change
$cd qtbase
$export PATH=/opt/linaro/gcc-linaro-arm-linux-gnueabi-20326_linux/bin:/home/prabindh/work1/arm-qt5-tar/qt-everywhere-opensource-src-5.0.0/qtbase/bin:
$export PKG_CONFIG=./x86-cross-ubuntu-pkg-config
$./configure -prefix /home1/prabu/qt5_install -release -make libs -xplatform linux-arm-gnueabi-g++ -opengl es2 -confirm-license -opensource -no-xcb -no-wayland -force-pkg-config -make examples -make demos -verbose
From the logs, configure should have detected the functionality - key are NEON, OpenGL, and EGLFS support
After configure, make && make install are to be done. This is important, as qmake needs to be in the install path.
Note: QtWebkit requires ICU support to be present. Refer QtWebkit build page mentioned earlier in the post.
Steps to build Qt3D :
To build Qt3D, in addition to qtbase also need to build the below:
qtjsbackend (has v8)qtdeclarativeqt3d
To build the above, enter the directory, then perform (assuming qmake is in the path as specified earlier)
$ qmake && make && make install
Checking the build output:
As a result of the build, the QtCore libraries, QtGui etc are all built. Also, the "eglfs" and "minimal" platform plugins are built by default. Note that "eglfs" draws onscreen using egl, while "minimal" draws to an offscreen pixmap image.
Example precompiled binary of Qt5:
A set of binaries built from above approach is provided below. To use this in the target filesystem, copy the below archive into /home1/prabu/ (Qt expects the same path while executing). Any filesystem with a recent enough libc (from &= gcc4.5) should be sufficient.
Screen captures of live demos on 3730:
Pictures and videos are posted at,
Executing demos on target:
1) Running QML demos:
QMLScene can be used to run QML demos, with a command similar to below:
/bin/qmlscene examples/qtdeclarative/qtquick/animation/pathanimation/pathanimation.qml -platform eglfs
2) Running standalone demos:
Standalone qt5 demos (including qt3d demos, as well as classic qtbase demos like animatedtiles) can be invoked as below for eglfs platform plugin
-platform eglfs
Note that applications using eglfs platform will not have any window decorations and will show full screen only.
Tslib support:
Apply this patch -
- refer to
for correct usage.
tslib (or other input plugins) is NOT built by default, need to do below steps (ensure tslib.h is present in standard /usr/include folders)
cd qtbase/src/plugins/generic/tslib
make && make install
The above step will generate and install "libqlinuxinputplugin.so" into plugins folder which will be detected by Qt5. The tslib plugin is invoked as below:
-platform eglfs -plugin Tslib
For other input devices (udev based), evdev* projects need to be built, and are present in the qtbase/src/plugins/generic/ folder.
Cursor support:
With above configuration with eglfs, cursor will not be shown on screen.
Hiding mouse pointer in Qt5:
Even if cursor is configured, it can be hidden disabled at run time by exporting the below variable.
export QT_QPA_EGLFS_HIDECURSOR=1
Screen Rotation support:
CPU Loading:
With pageflick qt3d demo, CPU loading is & 10% on 3730 for VGA LCD screen, with eglfs
With flickr3d qt3d demo, CPU loading is upto 50% on 3730 for VGA LCD screen, with eglfs
- Qt5 documentation for the APIs still need to be updated. All Qt5 docs ex, below are misleading (they point to Qtembedded docs)
Prabindh Sundareson, 2014
(Archived Discus comments on the Qt5 work are here - )
发表评论：
TA的最新馆藏[转]&帐号:密码:下次自动登录{url:/nForum/slist.json?uid=guest&root=list-section}{url:/nForum/nlist.json?uid=guest&root=list-section}
主题数:3106&分页:...状态主题发帖时间|&作者评分Like回复最新回复|&作者|&3|&[]|&48|&|&4|&|&4|&|&1|&|&1|&|&1|&|&4|&|&4|&|&3|&|&1|&|&2|&|&1|&|&0|&|&4|&[]|&10|&|&8|&|&2|&|&7|&|&4|&[]|&10|&|&1|&|&0|&|&9|&|&1|&|&2|&|&0|&[]|&13|&|&3|&|&7|&主题数:3106&分页:...
抽奖到手软！将狂欢进行到底！Qt的WebEngine简单例子
Qt 5.2、5.3、5.4、5.5 官方都没有对安卓上的WebEngine提供支持。
首先WebEngine需要使用vs2013的一些头文件，所以不能在mingw上编译。
其次，暂时未发现有人去编译安卓上的WebEngine。或许只要有头文件（vs无关），以及编译好得so文件，或许就能用了。
这里做了一个很简单的小示例：
1、pro文件添加如下内容：
运行效果：
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。From Qt Wiki
QtWebEngine integrates chromium's fast moving web capabilities into Qt.
Our goal is to bring the latest and best implementation of the web platform into the universe of Qt. It is not just a port of the core HTML/CSS rendering engine, it is the entire Chromium platform. The integration with Qt focuses on an API that is easy to use, yet extensible. We also make no compromise on the graphics integration, integrating the layer rendering of Chromium directly into the OpenGL scene graph of QtQuick.
freenode: #qtwebengineQtWebKit/QtWebEngine移栽差异(网摘) - Web前端当前位置:& &&&QtWebKit/QtWebEngine移栽差异(网摘)QtWebKit/QtWebEngine移栽差异(网摘)&&网友分享于：&&浏览：0次QtWebKit/QtWebEngine移植差异(网摘)
**Original link：https://wiki.qt.io/QtWebEnginePortingFromQtWebKit
(Redirected from&)
This guide gives an overview of the differences between the Qt WebKit and Qt WebEngine APIs in applications.
This intends to provide rough steps to follow when porting an application using Qt WebKit's QWebView API to use Qt WebEngine's QWebEngineView.
The Qt WebEngine equivalent of Qt WebKit C++ classes are prefixed by&QWebEngine&instead of&QWeb.
#include &QWebHistory&
#include &QWebHistoryItem&
#include &QWebPage&
#include &QWebView&
QWebHistory
QWebHistoryItem
Qt WebEngine
#include &QWebEngineHistory&
#include &QWebEngineHistoryItem&
#include &QWebEnginePage&
#include &QWebEngineView&
QWebEngineHistory
QWebEngineHistoryItem
QWebEnginePage
QWebEngineView
QT += webkitwidgets
Qt WebEngine
QT += webenginewidgets
#include &QtWebKit&
#include &QtWebKitWidgets& // With Qt &= 4.8
Qt WebEngine
#include &QtWebEngineWidgets&
It is not possible to access sub-frames. Methods of the main QWebFrame are now available directly through the QWebEnginePage itself.
QWebPage page;
connect(page-&mainFrame(), SIGNAL (urlChanged(const QUrl&)), SLOT (mySlotName()));
page.mainFrame()-&load(url);
Qt WebEngine
QWebEnginePage page;
connect(&page, SIGNAL (urlChanged(const QUrl&)), SLOT (mySlotName()));
page.load(url);
Since Qt WebEngine uses a multi-process architecture, the application needs to return to the event loop where the result will be received asynchronously from Qt WebEngine's render process. A function pointer, a functor or a lambda expression must be provided to handle the result when it is available.
QWebPage *page = new QWebPage;
QTextEdit *textEdit = new QTextEdit;
// *textEdit is modified immediately.
textEdit-&setPlainText(page-&toHtml());
textEdit-&setPlainText(page-&toPlainText());
Qt WebEngine (with a lambda function in C++11)
QWebEnginePage *page = new QWebEnginePage;
QTextEdit *textEdit = new QTextEdit;
// *textEdit must remain valid until the lambda function is called.
page-&toHtml([textEdit](const QString &result){ textEdit-&setPlainText(result); });
page-&toPlainText([textEdit](const QString &result){ textEdit-&setPlainText(result); });
Qt WebEngine (with a functor template wrapping a member function)
template&typename Arg, typename R, typename C&
struct InvokeWrapper {
R *receiver;
void (C::*memberFun)(Arg);
void operator()(Arg result) {
(receiver-&*memberFun)(result);
template&typename Arg, typename R, typename C&
InvokeWrapper&Arg, R, C& invoke(R *receiver, void (C::*memberFun)(Arg))
InvokeWrapper&Arg, R, C& wrapper = {receiver, memberFun};
return wrapper;
QWebEnginePage *page = new QWebEnginePage;
QTextEdit *textEdit = new QTextEdit;
// *textEdit must remain valid until the functor is called.
page-&toHtml(invoke(textEdit, &QTextEdit::setPlainText));
page-&toPlainText(invoke(textEdit, &QTextEdit::setPlainText));
Qt WebEngine (with a regular functor)
struct SetPlainTextFunctor {
QTextEdit *textEdit;
SetPlainTextFunctor(QTextEdit *textEdit) : textEdit(textEdit) { }
void operator()(const QString &result) {
textEdit-&setPlainText(result);
QWebEnginePage *page = new QWebEnginePage;
QTextEdit *textEdit = new QTextEdit;
// *textEdit must remain valid until the functor is called.
page-&toHtml(SetPlainTextFunctor(textEdit));
page-&toPlainText(SetPlainTextFunctor(textEdit));
Some classes of Qt Network like QAuthenticator were reused for their interface but, unlike Qt WebKit, Qt WebEngine has its own HTTP implementation and can't go through a QNetworkAccessManager.
Signals and methods of QNetworkAccessManager that are still supported were moved to QWebEnginePage directly.
QNetworkAccessManager qnam;
QWebPage page;
page.setNetworkAccessManager(&qnam);
connect(&qnam, SIGNAL (authenticationRequired(QNetworkReply*,QAuthenticator*)), this, SLOT (authenticate(QNetworkReply*,QAuthenticator*)));
Qt WebEngine
QWebEnginePage page;
connect(&page, SIGNAL (authenticationRequired(QNetworkReply*,QAuthenticator*)), this, SLOT (authenticate(QNetworkReply*,QAuthenticator*)));
QWebFrame::evaluateJavaScript was renamed and moved to the QWebEnginePage. It is currently only possible to run JavaScript on the main frame of a page and the result is returned asynchronously to the provided functor.
QWebPage *page = new QWebPage;
qDebug() && page-&mainFrame()-&evaluateJavaScript("'Java' + 'Script'");
Qt WebEngine (with lambda expressions in C++11)
QWebEnginePage *page = new QWebEnginePage;
page-&runJavaScript("'Java''' 'Script'", [](const QVariant &result){ qDebug() && result; });
Those methods now perform asynchronously the same way as a normal HTTP load would.
Qt WebKit classes or methods in this list will not be available in Qt WebEngine.
Qt WebEngine requires hardware acceleration. Since we couldn't support a web view class in a QGraphicsView unless it is attached to a QGLWidget viewport, this feature is out of scope.
Qt WebEngine uses a multi-process architecture and this means that any access to the internal structure of the page has to be done asynchronously, any query result must be returned through callbacks. The QWebElement API was designed for synchronous access and this would require a complete redesign.
There is no way to connect a signal to run C++ code when a link is clicked.
The Web SQL Database feature that this API was wrapping in QtWebKit was dropped from the HTML5 standard.
Qt WebEngine renders web pages using Skia and isn't using QPainter or Qt for this purpose. The HTML5 standard also now offers much better alternatives that were not available when native controls plugins were introduced in QtWebKit.
Visited links are persisted automatically by Qt WebEngine.
In the latest HTML standard, any document element can be made editable through the contentEditable attribute. So runJavaScript is all that is needed.
page-&runJavascript("document.documentElement.contentEditable = true")
12345678910
12345678910
12345678910 上一篇：下一篇：文章评论相关解决方案 1234567891011 Copyright & &&版权所有}