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~64
- Have working ssh access, the following steps all happen via ssh
- Switch the package feed to testing (this is because the QT library version are inconsistent otherwise)
/opt/victronenergy/swupdate-scripts/set-feed.sh testing
opkg update - Update packages (this might not be neccesary, report back if it works for you without doing it)
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 guiwill 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+)