Indeed, its difficult to find proper libssl3 for raspi. I was able to implement all needed features for libssl1.1. Next version will revert back to libssl1.1
2 Likes
It still seems to be wanting Libssl3. I removed the previous version, then installed the new one and got this
Selecting previously unselected package realdash.
(Reading database ... 101913 files and directories currently installed.)
Preparing to unpack realdash-mrd_2.3.1-1_arm64.deb ...
Unpacking realdash (2.3.1-1) ...
dpkg: dependency problems prevent configuration of realdash:
realdash depends on libssl3; however:
Package libssl3 is not installed.
dpkg: error processing package realdash (--install):
dependency problems - leaving unconfigured
Processing triggers for gnome-menus (3.36.0-1) ...
Processing triggers for desktop-file-utils (0.26-1) ...
Processing triggers for mailcap (3.69) ...
Errors were encountered while processing:
realdash
I believe the APT just remembers your previous broken install. Execute:
sudo apt --fix-broken install
I thought I had done that before installing the new one. Iāll try again and report back
1 Like
I just tried again. I did fix install and rebooted a few times. Then reinstalled the new version again and it installs and runs but itās still unhappy about libssl3 
Are there any other commands I can try to flush out the libssl3 dependency?
Out of curiosity, how much power does the Pi running Realdash use with the screen off and no other processes running?
Iām wondering about having Realdash run 24/7 instead of trying to make it boot very fast (although Iām real interested in that one fella who got boot times down to 7 seconds), and how much power draw that actually is
Not that Iām aware of, sorry. We did test the latest install package on 100% fresh OS install.
As you may have quessed, āit dependsā. We use RPI4 on DEATHFISH 2. Its always on, and launches/closes RealDash based on activity on CAN bus. In addition, our script attempts to put RPI to power save governor and shuts down HDMI completely when in idle.
We have a 100ah battery, and it will run out in about 2 weeks. Thatās fine with us, as if we donāt use the vehicle its always on battery tender.
Hi again,
I have the same setup as above. I am using a Tinker board S and have installed Tinker_Board-Debian-Buster-v3.0.11-20211026. I have installed the realdash-mrd_2.3.1-1_armhf.deb and get no errors when it is installed. I try running the software but nothing happens the little wheel spins for about 10 seconds but nothing comes up on the screen.
Can you offer any help or advice please. I am new to all of this but willing to try anything to make this work as it would awesome for my home build car.
Thanks
Brian
It has been a while since we last tested on Tinker Board. I will try fresh install on that.
1 Like
Yes, unfortunately RealDash is built on Debian Bullseye (Debian 11), and Tinker Board S only has Debian Buster (Debian 10) available. Tinker Board 2 and newer have Debian Bullseye available.
If you do not wish to use Tinker Board GPIO, I would recommend installing Asus provided Android 7 image. Last time I tried it worked very well. I would say that Tinker Board S with Android has better performance that you get from RPi4.
You have to install it from deb file.
going through initial setup on a pi 5, but it looks like things have changed a little since the 4
for one, in sudo raspi-config, the option under 4, performance options to change gpu memory is gone, AND all the options mentioned under 6 advanced options are gone
On the upside, the performance is really good, noticably smoother than the pi4, no stuttering in the UI in general either
1 Like
cant edit the above post for some reason
it looks like sudo raspi-config changed on the pi4 as well, might be an issue with newest raspbian os maybe?
Ok, will check and update the instructions.
does realdash on the pi support rendering across multiple screens?
as in, half on screen 1 plugged into hdmi port 1, and the other half on hdmi port 2
because finally got the dual round LCDs working, involved some custom EDID magic from the raspberry pi forums
it involved loading a bin file specific to my displays into /lib/firmware and putting an extra line into cmdline.txt
but honestly if i can get away with having it spread across two separate screens, thatāll be a much more robust solution than crazy edid stuff
Cool looking displays :thumbs:
By default in RPi 4 (and assume RPi 5), the dual output is used by RealDash as extended desktop. So plugging in two identical screens basically just doubles the horizontal resolution. I have no idea how your custom displays will behave, but it should be as easy as plugging them in and trying.
I tested out RealDash amd64 build on a windows 11 wsl installation of Debian Bookworm and my Archlinux laptop. Both installations worked very well. I purchased a Gmktec nucbox 5 with a Intel N5105 processor to install in my vehicle and run RealDash. I canāt for the life of me get RealDash to run as it segfaults on startup. I have tried Debian 11, 12, Archlinux, and PopOs and every installation segfaults on startup. It doesnāt create a core dump file so i am including the minimal gdb backtrace I got.
(No debugging symbols found in realdash)
(gdb) run
Starting program: /usr/bin/realdash
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
02:47:02.464 os_linux.cpp(444)(tid:0x9598a2df) : NUTS_INFO -
Program received signal SIGSEGV, Segmentation fault.
0x00005555558658f9 in ?? ()
(gdb) bt full
#0 0x00005555558658f9 in ()
#1 0x00005555555cc92f in ()
#2 0x00007ffff7229d90 in __libc_start_call_main (main=main@entry=0x5555555cc850, argc=argc@entry=1, argv=argv@entry=0x7fffffffe438)
at ../sysdeps/nptl/libc_start_call_main.h:58
self = <optimized out>
result = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -8338220075622073251, 140737488348216, 93824992725072, 93824997131224, 140737354125376, 8338220075511315549, 8338237971753466973}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x555555a2b008, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 1436725256}}}
not_first_call = <optimized out>
#3 0x00007ffff7229e40 in __libc_start_main_impl
(main=0x5555555cc850, argc=1, argv=0x7fffffffe438, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe428) at ../csu/libc-start.c:392
#4 0x00005555555ec765 in ()
(gdb)
I am willing to help debug. I have a pretty good knowledge of running linux but not programming or debugging. I really would like to use this tiny x86 box for the RealDash install if possible.
I did get it figured out. I think it had to do with the resolution I was testing at. I currently only have a 4K monitor to test and when I changed the resolution to 1920x1080 I have no problems starting RealDash.
I will try a minimal Armbian install on a TinkerBoard-S that I found laying around and will post a how to if I am successful. RealDash works very well without a desktop install using wayland, weston and xwayland. I also have some thoughts for us linux users for a less painful install. Is there a separate thread to discuss those issues?
Thanks for your excellent work on this product. I will be purchasing a subscription for now. As a linux user i would really prefer a way to purchase the software outright and donāt plan on running it with any network connections. I hope that RealDash can find a way to provide linux users with that option.
1 Like