Apologies for the crappy lighting - this was late at night in my bus, and lights are well… bright.
This is a 2GB Raspberry Pi 4 with a BTT TFT 70 display (effectively a clone of the official screen, connects via the ribbon cable, not hdmi)
I gave up trying to make this work on a Pi 3B+
Firstly, this comes with a warning - I’ve had some issues along the way, so be prepared to re-install if something goes sideways. Have a backup.
Secondly, some general thoughts on what this means:
You can’t toggle between old + new gui on the fly. That makes Package Manager harder to access. Plan accordingly.
I found the most success with a clean setup, that means I removed GUI Mods. Not sure if that is neccesary.
Get the RpiDisplaySetup side of things sorted first - make sure screen dimming, rotation, etc is all setup before proceeding.
Did I say backup your data?
Steps:
Upgrade to 3.70~83
Have working ssh access, the following steps all happen via ssh
Switch to the beta channel /opt/victronenergy/swupdate-scripts/set-feed.sh candidate
Update packages (this might not be neccesary, report back if it works for you without doing it) opkg update opkg install $(opkg list-upgradable | cut -d' ' -f1)
Install the new gui opkg install gui-v2
Switch the startup script from gui-v1 to gui-v2 opkg install start-gui-v2
At this point the old gui (/service/gui) will be stopped, and uninstalled. And the new gui (/service/gui-v2) will start up.
You can check the logs of the new gui with this command (if you have issues, check here and share these logs) tail -n 100 -F /var/log/gui-v2/current
To go back to the old gui:
opkg install gui will remove the start-gui-v2 package, and restart the old gui. I had to reboot sometimes afterwards.
Now, for the more technical folks - some additional commentary:
I don’t know why I’m not running into graphics acceleration issues, I tried separately to enable the GPU and get it working, but couldn’t get past some conflicts with the LCD controller.
As far as I know, it’s being rendered in software. I’m not seeing the same thing as previous reports from the testing where I recall someone saying that 2 cores stuck at 100% with this running. For me the gui-v2 process uses ~10% cpu when the display is recently active with higher spikes when it’s rendering things, and then it goes down close to 0 after a bit - so it looks ok to me.
It’s possible that with the recent upgrade to Qt 6.8 (from 6.6?) brought some other improvements with it, the last time I tried this was a while back and it definitely didn’t work like this (but that was also on a Pi3B+)
Thanks for the tip. I tried it on my Pi3B and it installed but hung on ‘switching gui’ or something similar. The install error log said this.
opkg install start-gui-v2
Solver encountered 1 problem(s):
Problem 1/1:
package packagegroup-ve-addons-1.0-r0.raspberrypi2 requires start-gui-v1, but none of the providers can be installed
package start-gui-v2-1.2.25-r0.cortexa7hf-neon-vfpv4 conflicts with start-gui-v1 provided by start-gui-v1-6.8.9-r0.raspberrypi2
package packagegroup-ve-console-apps-1.0-r0.raspberrypi2 requires packagegroup-ve-addons, but none of the providers can be installed
conflicting requests
problem with installed package packagegroup-ve-console-apps-1.0-r0.raspberrypi2
Solution 1:
allow deinstallation of packagegroup-ve-console-apps-1.0-r0.raspberrypi2
Solution 2:
do not ask to install a package providing start-gui-v2
FIX:
Running opkg install --force-depends start-gui-v2 removed V1 and allowed V2 to install and load. Seems to be working fine but try this at your own peril.
I spent some time today getting both GUI v2 working using this recipe, and the GX Touch 50+70 working natively using the edt-ft5x06 driver without using some of the scripts that were kicking around.
It’s reasonably easy. I started to document the process at this gist here; I might write a script to do this.
It’s so outstanding, I’ve been waiting for that for an eternity.
I can confirm that this works pretty well out of the box. It made no difference whether PackageManager was installed or not. However, for me, RpiDisplaySetup is essential to adjust the brightness of the display and more important to be able to turn it off (Power consumption and no illuminated display at night in the camper) . I have a 4GB Raspberry Pi 4 with 7" Waveshare DSI display. Dimming works. Switching off also works. But you can’t wake up the display by touch again. Wake up only via ssh console, restart raspberry or set display to turn off never is the only way it works at the moment.
There was often talk about performance problems. Everything runs smoothly for me. Only when starting the first start animation jerks a little. Since I usually don’t start so often, this is not really a hindrance. The load of the system is also not really more than with gui v1 according to top. I’m trying a new installation these days with only RpiDisplaySetup as an addon.
Thanks for sharing and thank you Victron for not giving up on the Raspberrys!
What dit you use as blanking and dimming device in RpiDisplaySetup? I used those settings that dit work under gui-v1:
Enter custom blanking and dimming devices (y/n)?: y
enter blanking device (/sys/class/…): /sys/class/graphics/fb1/blank
enter dimming device (/sys/class/…): /sys/class/backlight/rpi_backlight
Dimming works but when display is turned off by the moon or after the set time it stays black.
That is the right thing to do in v3.70~81! Thanks a lot to your replay and hint.
I think the QT library version is not a problem anymore so with the latest beta it’s working great and no victron testing feed is needed anymore. I will have to bring my Raspberry back to my Camper the next days to see if all devices will still work. But it looks great and I am very happy to have the new UI on my screen and not only over vrm portal.
With the Camper Demo Mode it looks all great.
Dimming an blanking works as in gui-v1 now. And the start animation is also faster.
I just realized that on the first “run“ of the blanking the display gets black but the backlight stays on - no matter if I do it or wait for it to switch off. After that it does not happen again till next reboot.
I gave this a try on my Zero 2W, since I can just reimage it if things really mess up. Just have it for testing. Seems to work acceptably well. Though, I only have a GPS and a ruuvitag that it can pick up for input.
I checked the logs, and I see the following loop output:
@40000000698fc7712e4701fc *** starting gui-v2 ***
@40000000698fc7713a1aac04 Victron gui version: v1.1.30
@40000000698fc772032bc28c Connecting to system bus...
@40000000698fc77203b2ad9c Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
@40000000698fc77208ea6ad4 BackendConnection state: Victron::VenusOS::BackendConnection::Ready
@40000000698fc772096c73e4 venus.gui: Successfully loaded translations for locale "en_US"
@40000000698fc7720973941c venus.gui: Unable to load translations for locale "C"
@40000000698fc7720974a974 venus.gui: Falling back to English as locale catalogue failed to load.
@40000000698fc773226ae3e4 Get Items failed "com.victronenergy.packageManager"
@40000000698fc773399a7f84 qml: Cannot load temperature unit, dbus/com.victronenergy.settings/Settings/System/Units/Temperature has unsupported value: default to celsius
@40000000698fc77339a3d624 qml: Cannot load altitude unit, dbus/com.victronenergy.settings/Settings/System/Units/Altitude has unsupported value: default to meter
@40000000698fc77401de2834 qml: DataManager: all devices model ready
@40000000698fc774062e0224 qml: DataManager: data objects ready
@40000000698fc7740631328c qml: DataManager: loading D-Bus data backend...
@40000000698fc77407922dd4 qml: DBusDataManager: services table model ready
@40000000698fc7740a70a544 qml: DataManager: backend finished loading!
@40000000698fc7740a74db64 qml: Main: data manager finished loading; now loading application content
@40000000698fc7741b51e38c qml: SplashView: welcome view loaded, starting splash animation
@40000000698fc77421f7bf54 Cannot mix incompatible Qt library (6.6.3) with this library (6.8.3)
you need to run beta, or change this line /opt/victronenergy/swupdate-scripts/set-feed.sh candidateto /opt/victronenergy/swupdate-scripts/set-feed.sh release
I only have one problem with my setup.
I’m using a DSI touch screen, and my touch area seems to be rotated 180°.
The image itself is correct.
Someone know how to correct this?
Thanks once again.
Yesterday I said that I’m using raspberry pi 2, but in reality is a Raspberry pi 3.
