qt & qtquick versions

[mpvader]

This discussion flares up regularly, below list is to get the facts in a row. Welcome to comment if you have more to say about it.

Currently used versions

• Qt 4.8.something (incl built-in VNC with multiple screens: QWS)
• QtQuick 1.1

We have some patches, patching both QtQuick (item.show) and Qt (vnc password), see commit log on github.

Note that, besides the GUI, we have various other applications that use the qt libraries. Not for display, but for string handling etcetera.

Notes about new version:

QtQuick 2.*

• Adds graphics acceleration (OpenGL ES 2.0).
• Until Qt 5.8 (or something) graphics acceleration was required. After that a software fallback mode was implemented, the Qt Quick 2D Renderer. Read the link to learn its limitations.
• QtQuick 2.* is the version we use, or will use soon, in VictronConnect. Obvious advantage of using the same in Venus.

Qt 5.*

• In Qt 5.8 support for QtQuick 1 was dropped. Thereafter, OpenEmbedded still supported it for a while; but also dropped it around the end of 2018. And now only Venus/Jeroen supports it.

VNC

• QWS (which has the built-in VNC we use) was dropped in 5.0.
• In Qt 5.8 there is some new support for VNC again. http://www.jumpnowtek.com/rpi/Running-Qt5-Apps-Over-VNC.html. We expect that, unlike on 4.8.7, its not possible to output the gui to both VNC and a display (such as the CCGX) at the same time.
• Qt5 does support Wayland. And Wayland is also working on VNC: https://www.ctrl.blog/entry/wayland-gnome-remote-desktop.
• Jeroen tested with using X-Server VNC; which is promising; see below.

Why update?

Do we need to update? No we don't. These are the arguments to do so: 1) There is the advantage for Jesus, working on both VictronConnect and the CCGX 2) QtQuick 2 adds Canvas, which will be very helpful in the overviews

Last one would be the dangerous argument that newer is better.

Various notes

• Shipping two versions of the Qt libraries at the same time is possible, but increase memory usage (RAM), as well as non-volatile memory.
• Running two GUIs at the same time (on the CCGX, one for the display and one for VNC) is not advisable either, besides memory there will also be a CPU issue.

[mansr]

Yes, the canvu500 has working graphics acceleration. The ccgx screen is so small that I doubt the performance drop with the software rendering in QtQuick will be of any concern.

[mpvader]

In v2.12~6, a relevant change was made:

v2.12~6 - develop testing
- Qt 5.9 is now available in the SDK and on the CANvu500
  - Qt 5.9 can now use Qt Quick 2 on eglfs and linuxfb
  - Only the canvu500 has support for egl. A demo is included, to run use:
     svc -d /service/gui && Qt5_CinematicExperience

[mpvader]

for the record: @jhofstee has been experimenting with using vnc from X11, but then without X11.

x11vnc -noipv6 -rawfb /dev/fb0 -pipeinput UINPUT:direct_key=/dev/input/event0,nouinput -shared -forever

Possible advantages:

• multiple clients at the same time
• (probably) having lower cpu cost than the Qt build in one we use today
• this opens the route to using a newer Qt / QtQuick version, including vnc-ing a display that has been drawed using hardware accelaration

first trials work, to be continued.

[mpvader]

VNC issue: https://github.com/victronenergy/venus/issues/292

[mpvader]

An update after discussing with Thiemo and Jeroen today:

A month ago; Thiemo tested running VictronConnect on a CANvu 500; and using VictronConnect as a base for a new Venus GUI was discussed with Jesus, Thiemo and Reaktor. The conclusions where that (a) VictronConnect is slow; bug can probably be made faster. And (b) using all of VictronConnect is not a good idea (landscape layout vs portrait; and difference in architecture: D-Bus vs VE.Interface) ; but re-using or sharing its components and design for Device pages does make sense.

In general, moving from QtQuick 1.1 and Qt 4.8 to QtQuick 2 and Qt 5 is still wanted. The main issues are:

• VNC: solvable.
• CCGX doesn't have hardware acceleration. So either we use the Qt software renderer (which just skips all hardware accelerated operations), or some other software renderer such as MESA -if that supports OpenEGLS2; and live with whatever disadvantages that has. Or, CCGX keeps the old GUI, and we only maintain that for new settings, and let it be.

Steps to move forward are first to (a) study the Qt Quick 2D Renderer documentation incl. limitations, and (b) check how bad the Qt Quick 2D Renderer is, both in looks and performance. A simple way to check the looks can (probably) be done with VictronConnect: compile it for use with that rendered and see what happens.