# Making QtWebKit with WebKit2 in Qt 5.0 work on Raspberry Pi

After compiling Qt 5.0 for Raspberry Pi, I wanted to try all the modules. I compiled and tested the simplest modules first, like:

1. qtbase
2. qtdeclarative
3. qtjsbackend
4. qtquick1
5. qtscript
6. qtxmlpatterns

Everything worked quite smoothly, without any change, except the patch to the v8 engine in qtjsbackend module for ARM hardfp (read here).

I then turned my attention to the QtWebKit module: I know that many changes have been applied to this module for Qt 5.0, so it is very interesting to try it. Therefore, I started to build it the usual way:

cd your_qt_sources/qtwebkit
your_qt_prefix/bin/qmake
make -jn
make install 

Unfortunately, at the moment of writing, it didn’t work for me: the module compiled and linked successfully, but crashed almost as soon as the page load procedure started. I therefore had to start searching around and asking Qt guys about this issue, and during this, I was frequently directed here. Turned out this is exactly the issue I encountered: I applied the latest patch (consider reading the entire report and check that a more stable fix is available):

cd your_qt_sources/qtwebkit
patch -p1 < ~/webkit_patch

where webkit_patch is the linked diff. So, now you can compile the module to include the differences and try again. Consider that the patch seems to be near land, so it might not be necessary for you in the future. As a first test, this is the code I tried:

#include <QApplication>
#include <QWebView>
#include <QUrl>

int main(int argc, char* argv[])
{
QApplication app(argc, argv);
QWebView webView;
webView.setUrl(QUrl("https://stackoverflow.com/"));
webView.show();
return app.exec();
}

At this point, it should work. As you can see, performance is unacceptable. This is not the way an embedded browser is supposed to work indeed, this is more like classes that can be used for a desktop browser.
Next step was testing WebKit2 with tiling and all that nice stuff. So I tried to create a simple application loading a WebView QML element, like this:

main.cpp:
#include <QGuiApplication>
#include <QQuickView>
#include <QUrl>

int main(int argc, char *argv[])
{
QGuiApplication app(argc, argv);
QQuickView viewer;
viewer.setSource(QUrl("/home/pi/main.qml"));
viewer.show();
return app.exec();
}

main.qml:
import QtQuick 2.0
import QtWebKit 3.0

WebView {
url: "http://www.cnn.com"
x: 100
y: 100
width:  1500
height: 900
}

When I tried this the first time, it closed with an anonymous error on QtWebProcess:

Failed to start " QtWebProcess 14"

After looking into the sources, I found this is simply a failure to find the QtWebProcess binary. It is needed because WebKit2 uses a separate process to draw the content. Placing it in /usr/bin is sufficient:

cd /usr/bin
sudo ln -s your_qt_prefix/bin/QtWebProcess QtWebProcess

Or better use a relative path. Now what you might get is… nothing at all… At least this is what I got. After some seconds a crash occurred and often nothing was drawn.
It took me some time to guess what was happening: it seems that QtWebKit is trying to draw with 32 bit color depth, while instead the rest of Qt is rendering using 16 bit color depth (especially if you’re using the eglfs platform plugin) on a RGB565 EGL configuration.
According to the Qt WebKit code, it seems that the entire code is assuming 32 bit color depth is being used, and this is hardcoded instead of negotiated with the main process. As a quick fix, I made the entire EGL configuration to be 32 bit (read this).
By setting this, it is possible to make QtWebKit work in 1080p with 32 bit color depth. If I’ll find the time I’ll do the needed modifications to have the same configuration with the correct color depth.

Consider that, at the moment of writing, the configuration of the wheezy image does not assign sufficient memory to the GPU.You’ll see therefore pages where many tiles are black: that is the result of insufficient GPU memory when trying to allocate for the texture. Just assign some more memory to the GPU editing the /boot/config.txt file of your Pi.

## Sample Video

NOTE: For updated information read here.

## 8 thoughts on “Making QtWebKit with WebKit2 in Qt 5.0 work on Raspberry Pi”

1. Anonymous says:

same problem here
./wtf/unicode/icu/UnicodeIcu.h:29:27: fatal error: unicode/uchar.h: No such file or directory

2. Anonymous says:

Hi Luca,
I tried to compile the qtwebkit but it failed with the following error:
————————————————–
In file included from ./wtf/unicode/Unicode.h:32:0,
from wtf/dtoa.h:26,
from wtf/dtoa.cpp:36:
./wtf/unicode/icu/UnicodeIcu.h:29:27: fatal error: unicode/uchar.h: No such file or directory
compilation terminated.
————————————————–
In usr/include/unicode/ there are all the unicode files.
Why has the compiler problems finding them?
Could there be a problem with the include path or the configuration?

Regards Joola.

3. /usr/bin/ld: skipping incompatible /home/macbookpro/Scaricati/qt-everywhere-opensource-src-5.0.1/qtbase/lib/libQt5Core.so when searching for -lQt5Core
/usr/bin/ld: cannot find -lQt5Core
collect2: ld returned 1 exit status

It seems that for some reason the gnu linker states that the Qt5Core library is not compatible with what you are trying to build. Try to check libQt5Core.so (maybe with 'file' or similar) or how you're building QtWebKit.

4. Hi Luca, thanks for your blog. Actually it's easier doing this using qtwayland, as it's working out of the box (of course you need to allocate enough video memory during boot) 🙂 If you need special configuration: modifying one of the provided compositor (qtwayland/examples) is an easy task. Cheers.

5. http://tmp.jung.ms/test.svg

when you use the arrow keys it should zoom in and out…

are you able to see this?

Sozi is based on CSS an JS, and it would be nice if it could be accelerated on the PI

Regards

6. On the Pi I can only see a "slideshow". No animation. I tested it on the same version of Qt 5.0 WebKit2 compiled for a mac and I also see a simple "slideshow", no animation. I don't know that technology so I'm not able to tell you why, sorry.