New Custom Debian ARM64 Build 4.4.154.c83 is finally here!


I don’t think so. You may want to start over with a fresh image so you’re not chasing unnecessary problems.


The password you setup when you first run “vncserver” for each user is the password for the VNC session only. It’s not for local login.


I’m using TigerVNC and VNC Viewer on Windows 10 without any issues (now) I did, however, see some of these issues when my XFCE4 configurations had errors. I had to log on locally and manually correct some of the configuration errors which were reported in the VNC logs in the vnc folder. After cleaning my errors (yep, I made them) the desktop and VNC server came up fine. it works perfectly now. I suspect it was your VNC xserver desktop configuration that caused your problems.


Amazing build, but when I run glmark2-es2

It throws these errors
libGL error: MESA-LOADER: failed to retrieve device information
libGL error: unable to load driver:
libGL error: driver pointer missing
libGL error: failed to load driver: rockchip
libGL error: MESA-LOADER: failed to retrieve device information
libGL error: unable to load driver:
libGL error: driver pointer missing
libGL error: failed to load driver: rockchip

What package should I install in order to correct this error?


And also, I’m getting screen tearing when watching Youtube videos and moving windows around, what are some ways I can correct this issue?


There has been issues with Youtube video, mostly some residue after exit from playing full screen video for relatively long, not sure if there will be a fix. I blamed Chromium, Openbox etc, but I’m now inclined it’s the CPU/GPU related since it’s not happening on my x86 running the same software combination, could be the driver or simply overheating, will see after installing the bigger heatsink.

I’m not sure about tearing, maybe that’s normal for SBC? This is my first Pi device, anyone has Raspberry Pi 3B+ or other alternatives I’d like to know.


Anyone tried this script to improve video playback?

Please provide feedback in that thread too so they can improve it further.

Maybe it only works with Armbian images from here

Also try Vivaldi browser instead of Chrome for better video playback.



I believe, that the libGL error is due to Mali is not supporting OpenGL, but only OpenGL ES.
So you need to use the OpenGL-ES API instead of OpenGL. You can try to set the environment variable LIBGL_ALWAYS_SOFTWARE=1

Have fun!


Any results on your HDMI audio test, using another monitor?
(surrendering to defeat is difficult, :exploding_head: )


You need to use the ip address instead of the hostname then.

5900 is the port


I didn’t have any problem, after I switched the “Playback” to HDMI the monitor’s crappy speaker immediately started playing


Thanks for the reply and monitor test.

Yes, that works for me, too. But, the problem is that the HDMI playback disappears if the video is paused for ~a minute or if Chromium is closed & reopened. Only ‘System Sounds’ appears in the ‘Playback’ tab. When another video is played, the setting goes back to rockchip…codec. It simply won’t retain the 'HDMI-CODEC…" setting.

It occurred to me that I have been using the default linaro account, which may not have rights to change the config/startup files for Pulse Audio. That would explain why I’m the only one having this issue. So, I changed linaro’s password and tried adding it to the adm and sudo group. Still no joy with the audio.

The GUI for ‘User & Permissions’ only allowed me to change linaro’s password and group membership. (this was also the case with armhf, until I changed linaro’s password) Today, I learned how to do it from the terminal, but the behavior is the same, even though I added the new users to the ‘adm’ and ‘sudo’ groups.
Finally, I tried playing a .mp4 file, but of course there’s no media player.
Meanwhile, my USB-C connector is about to break off, I need to swap my SSD board for the shorter one, and customize a generic aluminum case for this beast. That, I can handle.

Have a great day! :slight_smile:


Unfortunately I can’t run this package on my build, the Chromium in the package is armhf only. Besides Vivaldi doesn’t have ARM64 version either.

I couldn’t find widevinecdm for ARM64 anywhere (the one from Chromebook images no longer works guess Google doesn’t want to pay for free rides :smiley:


I don’t know what caused it but seems one (or more) of the audio daemons dead needed restart. Maybe when it happens check dmesg and try to grep audio or HDMI.
Sorry to hear the USB-C connector is loosen. If you have to replug it every time to reboot I guess that would be expected soon or later. I got the power strip from Amazon has switch button for individual outlets, I hope that will reduce the risk.


Hi. There is a arm64 Vivaldi.

I think thats the latest snapshot.


There is no magic, in vivaldi’s script:

case “arm64” in
amd64|x86_64) WIDEVINE_ARCH=x64; WIDEVINE_SUM=866f1ae68dae1133ed70768c2e7d3ff98b4a5b88a6fa0c474d5ebbe2d5548a77 ;;
i386) WIDEVINE_ARCH=ia32; WIDEVINE_SUM=6f08217b276eabf35ca0a32dec4477cd7e7af9a47edbcfd898eb75f071a09a9c ;;
arm*) echo “This script does not support ARM. See for more information” >&2; exit ;;

They depend on Google for widevine too, so the ARM64 version of Vivaldi doesn’t support widevine, unfortunately.


You’re right about over-use of the USB-C connector. Too much reimaging and too many restarts. That’s the least of my problems, now.
The tapping of the heatsink holes for mounting the SSD to it went w/o a problem. With the new set of assorted M2.5 standoffs, reassembly was a breeze. The new configuration fits perfectly inside the new aluminum case. Only need to cut some holes for the connectors. Woo-hoo!
The new shorter SSD board arrived with no instructions. I noticed that the ends of the new longer ribbon cable now has contacts on opposite sides. Thought that was odd. Examined the on board connectors and they appear to have double-sided contacts, which grip the ribbon on both sides. So, it doesn’t matter which side the ribbon contacts are on, right? Pin #1 is the same top or bottom of the cable, right? So, I connected everything in the same orientation as before. Doesn’t that make sense?

Well, apparently since the connector is now mounted on the bottom of the board, the pin-outs are wired backwards! You guessed it, dead Rock Pi 4B. :face_with_symbols_over_mouth:


Ouch, I feel for you, and we all learned this from you. I’m going to receive my M.2 board today, I’ll pay extreme attention to this.


I love it, I used it to build a SDR aka Software Defined Radio system using GQRX_SDL for RPI3 :slight_smile::heart_eyes:


Hay now hold your horses there… :wink: