The Tall Man

My brief experience in trying out a USB-C display wasn't great. I was never able to get any video at all until / unless I was fully booted into an OS, and even then it was shotty. Both USB-C connectors on the Orange PI 5 Plus (on mine anyway) are poorly made and intermittently lose connection if moved around at all. I recently read that's a real problem with SBCs in general that get their power over USB-C... clearly a very poor design. I also read somewhere that a similar board required proprietary drivers for USB-C display output to function. My experience indicates at least something like that likely applies here as well. Dysfunctional hardware design.

I don't see anything above about your boot-loader being updated. i.e. u-boot or grub. If you're using u-boot, was your uInitrd in your /boot directory updated? The initrd-image needs to be converted to its u-boot format of uinitrd. Instructions for how to do that are located at the bottom of your boot.cmd file (using the mkimage command from the u-boot-tools package). Though that may be a generic example that you'll have to update for your system. Also if you have an armbianEnv.txt (or an equivalent) in your /boot directory, be sure it's up to date for your current kernel's devicetree file location and name. If that doesn't solve it read on.... I keep seeing everywhere that kernel 6.12 is broken. Not sure if that applies to all systems. I use the edge kernel (6.16) in my OrangePI-5-Plus. I've found that to work much better than Vendor (6.1). To chroot in from an another identical system. This works on Debian Trixie. I'm not sure about other OS's. Note: I don't know much about this, I recently found this from searching and used it myself. I found it works great to install new packages and also to run update-initramfs. mount -t proc proc /mnt/proc mount -t sysfs sysfs /mnt/sys mount -t devtmpfs devtmpfs /mnt/dev mount --bind /dev/pts /mnt/dev/pts # If you need for the chrooted system to be able to access the internet, the link at its: (/etc/resolv.conf) must be valid, so add this as well: mount --bind /run/systemd /mnt/run/systemd Then chroot in (I'm not sure if the /bin/bash) is necessary - or if you're using something else than bash, put that there instead?) chroot /mnt /bin/bash [Do what you need to do in there] i.e. install a different kernel, and be sure update-initramfs has been run or run it yourself, and the u-boot (or grub) is updated. Whenever you're installing a new kernel, it's a good idea to leave the old one there. Once you get it working, it might then be a good idea to remove any non-functioning kernels (like that 6.12), and leave any functioning kernels in. Then to back get out of chroot and return undo the above mounts: # Exit chroot exit # This line is only necessary if you mounted it to use the internet while chrooted: umount /mnt/run/systemd # Unmount the rest umount /mnt/dev/pts umount /mnt/dev umount /mnt/sys umount /mnt/proc umount /mnt

I recently had to modify a device tree file for a different reason. I showed what I did (and how I did it) here: https://forum.armbian.com/topic/52118-hdmi-audio-and-analog-audio-do-not-work-on-opi5plus/?do=findComment&comment=224923 To summarize, I used the device-tree-compiler package (command line: dtc) to convert the device tree binary (.dtb) file to a device tree source (.dts) file. Then I edited the .dts file, then converted it back. The process won't show you all the variable names, but the resulting .dts is readable enough to likely see what and where you need to change... and even moreso if you have the original (pre-compiled) .dts file to compare it with. If you need to match variable names with specific numbers, they will likely be #defined in the #includes at the top of the original .dts file.

This will cause update-grub to add the following a devicetree line to all menu entries. This example is based on Debian Trixie's grub-efi. This example will expect dtb directories (or links) to be in the /boot directory, using the convention that I've seen Armbian use. Here is an example of a /boot directory listing for (pure) Debian Trixie with two kernels: -rw-r--r-- 1 root root 336036 Aug 27 04:10 config-6.12.43+deb13-arm64 -rw-r--r-- 1 root root 343394 Sep 6 12:48 config-6.16.3+deb13-arm64 lrwxrwxrwx 1 root root 42 Sep 20 16:17 dtb -> ../usr/lib/linux-image-6.16.3+deb13-arm64/ lrwxrwxrwx 1 root root 43 Sep 20 16:17 dtb-6.12.43+deb13-arm64 -> ../usr/lib/linux-image-6.12.43+deb13-arm64/ lrwxrwxrwx 1 root root 42 Sep 20 16:18 dtb-6.16.3+deb13-arm64 -> ../usr/lib/linux-image-6.16.3+deb13-arm64/ drwxr-xr-x 3 root root 4096 Sep 20 15:13 efi drwxr-xr-x 5 root root 4096 Sep 20 16:26 grub lrwxrwxrwx 1 root root 29 Sep 15 21:30 initrd.img -> initrd.img-6.16.3+deb13-arm64 -rw------- 1 root root 42521317 Sep 20 16:26 initrd.img-6.12.43+deb13-arm64 -rw------- 1 root root 43760872 Sep 20 16:25 initrd.img-6.16.3+deb13-arm64 lrwxrwxrwx 1 root root 30 Sep 15 20:38 initrd.img.old -> initrd.img-6.12.43+deb13-arm64 -rw-r--r-- 1 root root 83 Aug 27 04:10 System.map-6.12.43+deb13-arm64 -rw-r--r-- 1 root root 92 Sep 6 12:48 System.map-6.16.3+deb13-arm64 lrwxrwxrwx 1 root root 26 Sep 15 21:30 vmlinuz -> vmlinuz-6.16.3+deb13-arm64 -rw-r--r-- 1 root root 37449664 Aug 27 04:10 vmlinuz-6.12.43+deb13-arm64 -rw-r--r-- 1 root root 41507328 Sep 6 12:48 vmlinuz-6.16.3+deb13-arm64 lrwxrwxrwx 1 root root 27 Sep 15 20:38 vmlinuz.old -> vmlinuz-6.12.43+deb13-arm64 Note: The relative pathways of the dtb links above assume that the /boot directory is part of the main OS partition, not on its own boot partition. Otherwise you'd need to copy those directories to /boot/ as Armbian does. For The Current Partition's OS Entries (each devicetree will be specific to the respective kernel) 1. Open the file with a text/source editor (using sudo): /etc/grub.d/10_linux 2. Find every line that looks something like this (currently on my system, there is only one, and it's line 189) linux ${rel_dirname}/${basename} root=${linux_root_device_thisversion} ro ${args} 3. Just above it, add your own system's version of this line: devicetree ${rel_dirname}/dtb-${version}/[VENDOR SUB-DIRECTORY]/[SBC PRODUCT].dtb Specific Example: OrangePI-5-Plus devicetree ${rel_dirname}/dtb-${version}/rockchip/rk3588-orangepi-5-plus.dtb Specific Example from the resulting grub.cfg, of the current trixie-backport kernel, again on the OrangePI-5-Plus: devicetree /boot/dtb-6.16.3+deb13-arm64/rockchip/rk3588-orangepi-5-plus.dtb For Other Partitions' OS Entries, via os-prober (I'm unfamiliar with the variables in this so each devicetree will be the same generic path, regardless of kernel) 1. Open the file with a text/source editor (using sudo): /etc/grub.d/30_os-prober 2. Find every line that looks something like this (currently on my system, there are two, lines 277 and 297) linux ${LKERNEL} ${LPARAMS} 3. Just above it, add your own system's version of this line: devicetree /boot/dtb/[VENDOR SUB-DIRECTORY]/[SBC PRODUCT].dtb Specific Example: OrangePI-5-Plus devicetree /boot/dtb/rockchip/rk3588-orangepi-5-plus.dtb Then run update-grub, and take a look at the resulting /boot/grub/grub.cfg

I have an OrangePI 5 Plus, which is based on the rk3588 (arm64) SoC. I've installed Debian Trixie directly from their .iso installer (using an EFI booter) and it works - although I had to upgrade the kernel to the latest backported version to get GPU and audio. But the Armbian edge kernel (Rockchip64 in my case) works even better when install that package onto the pure Debian. I looked up that Chromebook and see it's based on the rk3288C, which is apparently a 32-bit arm (armhf)? If that's the case, you can download the Debian .iso installer here: https://cdimage.debian.org/debian-cd/current/armhf/iso-dvd/ Then if Armbian has an edge kernel for the rk3288, try it out to improve upon what Debian provides. I did find this page on Debian's site, but it doesn't look like it would be much help.: https://wiki.debian.org/InstallingDebianOn/Asus/C100P There is a Debian page for a similar computer that may be more helpful if you can adapt it to yours? https://wiki.debian.org/InstallingDebianOn/Asus/C101PA Note that the above two links were probably created long before Trixie. P.S. Even better is a full linux tutorial for your specific computer. In a search engine, I looked up: installing linux on ASUS ChromeBook C100P ...and this was a result: https://archlinuxarm.org/platforms/armv7/rockchip/asus-chromebook-flip-c100p

Same. But once you're in, you can run armbian-config and switch to the edge kernel. It'll work better. Just don't switch to the "current" kernel. 6.1 = Vendor Kernel 6.12 = Current Kernel 6.16 = Edge Kernel

Summary Update: A Look At Pure Ubuntu (no Armbian) --> The bug was there, then it was not! Initial Observation: Debian 13 (Trixie) The Bug Is Present Operating System: Debian GNU/Linux 13 KDE Plasma Version: 6.3.6 KDE Frameworks Version: 6.13.0 Qt Version: 6.8.2 Kernel Version: 6.16.4-edge-rockchip64 (64-bit) Graphics Platform: Wayland Ubuntu 25.04 The Bug Is Present Distributor ID: Ubuntu Description: Ubuntu 25.04 Release: 25.04 Codename: plucky Operating System: Ubuntu 12 KDE Plasma Version: 6.3.4 KDE Frameworks Version: 6.12.0 Qt Version: 6.8.3 Kernel Version: 6.16.0-17-generic (64-bit) Graphics Platform: Wayland Ubuntu 25.10 The Bug Is Gone! Distributor ID: Ubuntu Description: Ubuntu Questing Quokka (development branch) Release: 25.10 Codename: questing Operating System: Ubuntu 13 KDE Plasma Version: 6.4.5 KDE Frameworks Version: 6.17.0 Qt Version: 6.8.3 Kernel Version: 6.16.0-17-generic (64-bit) Graphics Platform: Wayland Conclusion The bug was in Ubuntu. Then it wasn't. So the answers to how to fix it are likely in the changes made in or by Ubuntu.

Update: I just ran Ubuntu 13 (25.10 (development branch)), downloaded from their site (not Armbian), running their kernel. There I installed KDE Plasma 6.. Wayland performance was excellent. The bug I described here didn't show up at all. This version of Ubuntu seems more similar to Trixie than Bookworm. And some of their related package names, like Trixie's, did seem to mention porting from QT5 to QT6. So whatever bug is existing in Trixie was either not created, skipped, or solved by Ubuntu. Operating System: Ubuntu 13 KDE Plasma Version: 6.4.5 KDE Frameworks Version: 6.17.0 Qt Version: 6.8.3 Kernel Version: 6.16.0-13-generic (64-bit) Graphics Platform: Wayland

The board I have has a different Rockchip SoC (rk3588-orangepi-5-plus), but it's been my experience that the edge kernel (6.16) is the only one that's of any real use to me. I get no video with the "current" (6.12) kernel, and no GPU acceleration with the vendor (6.1) kernel. So I would suggest just switching to the edge kernel.

On the OrangePI-5-Plus, using an edge kernel, I've found that the desktop environment's GPU rendering works very smoothly on Wayland, in KDE 6 on Debian Trixie. It renders much more smoothly than gnome with Wayland (it's been my experience that the edge kernel is the only one that works). But I've encountered a major rendering bug. It only appears in Trixie KDE Plasma 6 with Wayland rendering. It does not appear when using x11 or when using either rendering in gnome. Nor does it appear at all in Bookworm. I have tried all kinds of things to "fix" these to no avail, including installing more wayland and mesa packages, then upgrading them to stable backports and then even to unstable testing (forky) versions. I've also tried the Debian unstable edge kernel from testing (6.16.3) as well as the Armbian stable edge kernel (6.16.4) with the same results. I installed Debian Trixie using the Debian .iso installer (w/ EFI boot), then upgraded to their edge/testing kernel (6.16.3) from their testing/forky repository. The bug showed up in pure Debian without a drop of Armbian. Then I installed the Armbian stable edge kernel (6.16.4) to replace the Debian edge/testing kernel in that installation. The bug remained. The rendering bug also showed up in the release version of Armbian Trixie 25.8.1 using the Armbian edge kernel. KDE 6 Wayland Render Bug Symptom: The [ALT-TAB] Task-Switcher's Text Labels (see screenshot #1) The major place this bug shows up is in the task switcher (using ALT-TAB). The window labels, instead of rendering as textual fonts, they render as blocks. I tried several things with the fonts, from changing their type and size, turning on/off anti-aliasing, to changing the desktop themes, and so on. I also tried using different "task switchers" from the list. All I got were the same blocks -they just appeared in different sizes and positions with no other changes. So I'm reasonably sure the rendering issue has nothing to do with fonts, desktop themes, Plasma settings, etc. KDE 6 Wayland Render Bug Symptom: glmark2 (x11) verses glmark2-wayland (see screenshots #2 and #3) Using the command-line utility: glmark2, there's an x11 version and a Wayland version. The each render to an 800x600 window. Normally the only visual difference between them is that the Wayland version has no window borders around it. But with this bug, the Wayland version renders significantly smaller on the screen, and also at a significant performance reduction (>50%). Conclusion I already know it isn't an Armbian issue. I don't believe it's a kernel issue either. I'm reasonably sure it has nothing to do with fonts, themes, or Plasma settings. In my internet searches, I have found no other reports of this specific rendering bug that I think are relevant to whatever is happening now. I did find some vague statements about there still being some "issues" with rendering in the upgrade from KDE 5 (using QT5 libraries) to KDE 6 (using QT6 libraries). I also read that KDE Plasma 6 has a somewhat unique interface or relationship with Wayland and uses its own protocols with it. I think this explains why the bug doesn't show up in gnome, and also helps to isolate, to a degree, where the bug actually is. From what I've read, apparently this issue shows up differently on different systems? It is my impression that these specific symptoms of this bug may be unique to this hardware (Rockchip rk3588 SoC) or GPU (MALI-G610 (built-in)), even though it is a clearly a software bug. Operating System: Debian GNU/Linux 13 KDE Plasma Version: 6.3.6 KDE Frameworks Version: 6.13.0 Qt Version: 6.8.2 Kernel Version: 6.16.4-edge-rockchip64 (64-bit) Graphics Platform: Wayland EDIT: P.S. I just ran Fedora's KDE Plasma 6 image. There were about a thousand updates to run on it. Plasma 6.3.4 (think) upgraded to version 6.4. And their mainline kernel (6.14 upgraded to 6.16.7 I think). The rendering bug I mentioned here did not show up either before or after those updates. So it appears the issue isn't with KDE Plasma itself either, that it's apparently on Debian's end. I noticed some of the (Debian) packages are specifically to bridge 5 and 6. I would guess that's where the problem is - apparently they didn't make a clean break. Screenshot #1: [ALT-TAB] task-switcher Screenshot #2: glmark2 Screenshot #3: glmark2-wayland

Terrific! You're welcome!

That module is not included in the default kernel build configuration. But you can build the kernel yourself. https://docs.armbian.com/Developer-Guide_Build-Preparation/ https://docs.armbian.com/Developer-Guide_Build-Commands/ When you run ./compile.sh, the first thing it shows you is the kernel configuration screen (image 1). Select, "Show a kernel configuration menu before compilation". When it finally arrives on the configuration menu (image 2), use the forward slash key (/) for search, enter ntsync. When the result comes up (image 3), press 1 to select it. It will take you right to it. It will be highlighted (image 4). Press the M key to select it as a module. The use the right arrow to move from Select to Exit, and keep doing that until you get to where you save it. Then keep going with the rest of the process. I could be wrong about this, but I think you can build the kernel only without the whole armbian image too, with this (from the second link above); ./compile.sh kernel-config BOARD=orangepi5 BRANCH=edge Image 1: Select Kernel Configuration Image 2: Kernel Configuration Menu Image 3: Search Result - NTSYNC Image 4: - NTSYNC Selection

One issue with Debian Trixie and encrypted root file systems is that they made some changes. There's an additional package you now need (in addition to cryptsetup-initramfs) prior to updating your initramfs so it will mount an encrypted root: systemd-cryptsetup Despite what this says, I had to install it manually. https://www.debian.org/releases/trixie/release-notes/issues.en.html#encrypted-filesystems-need-systemd-cryptsetup-package

This doesn't exactly answer your question, but it may meet your need better... I experimented around with different fans & heatsink configurations. Using an official Debian image from Orange PI 5 Plus, I found that the PWM controlled fan changed speed pretty abruptly, and only at high temperatures. Their adjustment algorithm didn't apply any decent smoothing at all. It was very noisy, and the constant changes whenever I did anything made it very distracting. I ended up purchasing a 3rd party fan with two single-pin leads that I could connect to the GPIO's 3.3v (or 5v). And I have it mounted on a Geekworm case (N508 - made for the Orange PI 5 Plus), with a short heatsink over the ICs. That case had actually come with a fan that had a single 2-pin connector, so it was only good for 5v and about 5 months before it died. From the GPIO, the 5v is on all the time the computer is receiving power, but the 3.3v is only on while the computer is on. If you "shut down" the computer, the 3.3v shuts down along with it. When I first tried the new fan on 5v, it wasn't too bad, but I could hear it. If I ran it off the 3.3v (which I do all the time now), it's virtually silent. When I run something that maxes out the CPU for a long time, with this fan on 3.3v running (and the short heatsink in place), the SoC temperatures stabilize around 50 degrees, and I've never seen them exceed the mid-50s with this setup. That is way lower than that official PWM fan did with that pseudo-heatsink it's mounted on, under the same CPU load. And I never have to worry about the fan quitting if some software PWM control malfunctions. Here's that new fan I bought (it came in a pack of 4): https://www.amazon.com/dp/B08R1CXGCJ?ref=ppx_yo2ov_dt_b_fed_asin_title If you have an N508 or similar type of case, the fan mounts to the top of the case. I checked, and Geekworm is apparently no longer selling that case? But back when I was looking into all this, I had found another very similar case sold by a different company (after I'd already purchased the N508) - I don't remember its name. But the fan it came with came with two single-pin connectors like the fan I eventually ended up staying with.

@LanMarc77, I think you meant to tag @laibsch there What you're saying sounds like it could be a good option.