fraz0815

New tool, fully automatic on x11 and wayland, beta: https://github.com/fraz0815/gptouch-python

JFYI, collabora started building mesa packages - see https://gitlab.collabora.com/hardware-enablement/rockchip-3588/pkg/mesa That should be very convenient and easy to install in the near future.

Basic tool to change screen orientation and its touch input on gnome wayland desktops. Built for Gnome Wayland and displays without automatic touch input rotation after orientation change. Sadly xrandr and xinput are things of the past in times of wayland. And since I mounted a FHD touchscreen to my rock-5b which can be rotated, this caused some trouble for me. Mabye useful fur other people mounting displays with touch support on their SBC's in crazy spots 😛 Basically it's just a combination of gnome-randr.py and creating a udev rule with calibration matrix. Fun project to test out chatGPT 😀 https://github.com/fraz0815/gptouch

Just stumbled over another chromium fork: https://github.com/Alex313031/Thorium Forum search did not show any entries, so I thought I might share. The arm64 builds (for raspberry though) works great, it even has googly sync, widevine etc, check describtion for more info. It works out-of-the-box on legacy rock-5b jammy gnome images with liujianfeng1994 ppa enabled. For installation/updates one could also use: wget https://dl.thorium.rocks/debian/dists/stable/thorium.list sudo mv thorium.list /etc/apt/sources.list.d/ sudo apt update sudo apt install thorium-browser I usually like to test https://paveldogreat.github.io/WebGL-Fluid-Simulation/ which also runs smooth with webgl on the rock-5b. This might be a good choice, till upstream support makes it easier to find a up2date browser with gpu support.

Are AI generated (stable-diff) pictures allowed? Copyright is quite unclear afaik. This post can be deleted and the answer maybe put in first post for better overview.

imho android gpu drivers are often more mature for gaming/emulation.

Rock Pi-4B - Armbian_23.05.1_Rockpi-4b_jammy_current_6.1.30_gnome_desktop.img installed to emmc: logs wlan, hdmi, nvme working Rock-5B - Armbian_23.05.1_Rock-5b_jammy_legacy_5.10.160_gnome_desktop.img Took me a while to boot from SD, was using an older 23.05-trunk version. Even 'sudo dd if=zero.img of=/dev/mtdblock0' with radxa zero.img would continue to boot happily from nvme instead of sd, changed armbianEnv.txt to sd root, updated bootloaderon mtd -> worked. besides mtd being a mystical thing for me, almost anything worked: installed to mtd+nvme: logs using btrfs on nvme + mtd did not work (don't know if supported, but installer lets you pick it). performance with panfrost ppa's enabled is absolutely stunning. Btw, this time for testing I used my 45W PD PSU (+ PD C<->C Cable 60W) instead of fixed 5V@4A w/o errors and activated the max 12V PD option in armbian-config just for fun. Sensors report ed in0: 12.00 V (min = +12.00 V, max = +12.00 V) curr1: 1.50 A (max = +1.50 A) and had no reboots or whatsoever.

Okay, somehow i got lost between the repos, next-gen and 150balbes (. Thanks, let's find out out where I went wrong and what else I might pulled 🙂

Currently we get 'sduuid' in form of [[ -z $sdblkid ]] && sdblkid=$(blkid -o full /dev/mmcblk*p1) # 3 - Extract the UUID from $sdblkid via regex: sduuid=$(echo "$sdblkid" | sed -nE 's/^.*[[:space:]]UUID="([0-9a-zA-Z-]*)".*/\1/p') which outputs only UUID 78cdc7b8-0f2e-4444-ba7c-38aa26198de1 This is fine, as long as we use it correctly afterwards, but everytime we modifify fstab, echo "${sduuid} /media/mmcboot ext4 ${mountopts[ext4]}" >> "${TempDir}"/rootfs/etc/fstab echo "/media/mmcboot/boot /boot none bind 0 0" >> "${TempDir}"/rootfs/etc/fstab which results in # <file system> <mount point> <type> <options> <dump> <pass> tmpfs /tmp tmpfs defaults,nosuid 0 0 78cdc7b8-0f2e-4444-ba7c-38aa26198de1 /media/mmcboot ext4 defaults,noatime,commit=600,errors=remount-ro,x-gvfs-hide 0 1 /media/mmcboot/boot /boot none bind 0 0 UUID=52f9b8a6-b6ab-4e81-a362-5c4ca041d539 / ext4 defaults,noatime,commit=600,errors=remount-ro,x-gvfs-hide 0 1 Missing "UUID=" and prevents booting correctly. But we cannot simply change sduuid, because on other steps it is used correctly. Maybe make clear which variable has the form of "UUID=XXXXX-XXX-XXXX" in their name, for better understanding, like sduuid for only UUID ("blabla-bla") and sdwuuid für "UUID=blabla-bla". Or use the lazy mode with a check before we modify fstab and add "UUID" as simple string. Example log

Well, this isn't quite the recommendation (afaik, did something change from the 5V / 4A Type C?). Power Supply is absolutely critical during boot times, and even 5V/3A was not enough when running a desktop, mentioned many many times. I also had to learn this the hard lesson 😉 Try to get 5V/4A Type C to be sure. What happened to me one time after installation was a faulty line in /etc/fstab was XXXX_EXAMPLE_UUID / ext4 defaults,noatime,commit=600,errors=remount-ro,x-gvfs-hide 0 1 instead of UUID=XXXX_EXAMPLE_UUID / ext4 defaults,noatime,commit=600,errors=remount-ro,x-gvfs-hide 0 1 which you could check. @balbes150 Did you compile mesa from here for kernel 6.2 builds: https://gitlab.freedesktop.org/panfrost/mesa/-/tree/panfrost/v10-wip , I guess this was https://gitlab.com/panfork/mesa (branch csf) used for legacy kernel?

pipi, I think you should get a correct PSU without PD with 5V and 4A, like in the picture. Then start from scratch with erasing mtd/nvme with dd. Without this sort of PSU you will always run in possible conflicts which are hard to debug.

Some news about the rock5b + usb2 + uboot. https://www.collabora.com/news-and-blog/blog/2023/04/27/radxa-rock-5b-usb20-host-in-u-boot/ One of the patches seems nice: