Raspberry Pi 4 Model B Rev 1.1
Linux 5.10.0-rc7-1-MANJARO-ARM and
Linux 5.10.0-1-MANJARO-ARM
Plasma 5.20.4
Are working fine 
Pinebook Pro
5.7.19-1-MANJARO-ARM
Plasma 5.20.4
kwin 5.20.4-1
mesa 20.3.1-0.1
Still o.k. with 5.7 kernel on plasma x11 and wayland.
Does not seem to work with RPi 3B. After upgrading from kernel 5.9.xx to 5.10 the Raspi does not boot anymore. Nothing shown via HDMI. 
I switched to arm-testing from arm-stable with XFCE4 and while doing the first big update I had these errors:
( 73/134) upgrading gnome-keyring
Failed to set capabilities on file `usr/bin/gnome-keyring-daemon' (Operation not supported)
usage: setcap [-q] [-v] [-n <rootid>] (-r|-|<caps>) <filename> [ ... (-r|-|<capsN>) <filenameN> ]
Note <filename> must be a regular (non-symlink) file.
error: command failed to execute correctly
...
( 76/134) upgrading gstreamer
Failed to set capabilities on file `usr/lib/gstreamer-1.0/gst-ptp-helper' (Operation not supported)
usage: setcap [-q] [-v] [-n <rootid>] (-r|-|<caps>) <filename> [ ... (-r|-|<capsN>) <filenameN> ]
Note <filename> must be a regular (non-symlink) file.
error: command failed to execute correctly
Edit: I should add that I use nfsroot.
Edit 2: Both files are regular files, not symlinks.
kwin with X11 has been crashing on startup due to the compositor for me on RPi4. With Wayland, no issue. With X11, I switch to Xrender and that works OK.
Note: The kwin issue is not with my XFCE4 testing image but rather my KDE unstable image.
Problem introduced with the new kernel 5.9.13 on 09-Dec is still present.
When charging the PBP using the USB-C connector, I see the kernel logging the following message repeatedly:
kernel: cdn-dp fec00000.dp: [drm:cdn_dp_pd_event_work [rockchipdrm]] Not connected. Disabling cdn
It also causes lots of ‘chirping’ from the speakers! My only solution for now is to not charge by USB-C.
I looked into this and found 2 issues:
First the raspberrypi-bootloader raspberrypi-bootloader-x version 20201207-1 boots just fine with the latest linux-rpi4 5.4.83-1 kernel with my pi3 model B.
The latest raspberrypi-bootloader raspberrypi-bootloader-x version 20201214-1 gives a black screen and nothing happens at boot with my pi3 model B with the linux-rpi4 5.4.83-1 and the linux-rpi4-mainline 5.10.0 kernels.
The raspberrypi-bootloader raspberrypi-bootloader-x version 20201207-1 boots with the linux-rpi4-mainline 5.10.0 kernel but there are several kernel stack traces mostly involving the network and you are restricted what you can do in the DE because of it using the pi3 model B.
Bottom line is STAY AWAY from the linux-rpi4-mainline 5.10.0 kernel and the raspberrypi-bootloader raspberrypi-bootloader-x version 20201214-1 packages until they get things fixed if you are using the pi3 model B.
After this update caidao doesn’t open:
/usr/lib/caidao/caidao: error while loading shared libraries: libre2.so.8: cannot open shared object file: No such file or directory
but they are working on it: Activity · ohfp / caidao · GitLab
pushed to branch master/bc5735e8cddfae053f114a7e98be551d86d6ddc1) · v87.0.4280.88-2 – libre2 rebuild
EDIT: removed punctuation from gitlab link that was breaking it. UPDATE: When I first posted, the caidao release to fix the issue was in the pipeline, presumably building and testing. As of now, (19 December, 17:15 New York time) the status is “pipeline failed”.
I’m failing in the “checking for file conflicts” step for the dolphin package:
(199/199) checking for file conflicts [###################################################] 100%
error: failed to commit transaction (conflicting files)
dolphin: /usr/bin/dolphin exists in filesystem
dolphin: /usr/bin/servicemenuinstaller exists in filesystem
dolphin: /usr/include/Dolphin/KVersionControlPlugin exists in filesystem
dolphin: /usr/include/Dolphin/dolphinvcs_version.h exists in filesystem
dolphin: /usr/include/Dolphin/kversioncontrolplugin.h exists in filesystem
dolphin: /usr/include/dolphin_export.h exists in filesystem
dolphin: /usr/include/dolphinvcs_export.h exists in filesystem
dolphin: /usr/lib/cmake/DolphinVcs/DolphinVcsConfig.cmake exists in filesystem
dolphin: /usr/lib/cmake/DolphinVcs/DolphinVcsConfigVersion.cmake exists in filesystem
dolphin: /usr/lib/cmake/DolphinVcs/DolphinVcsTargets-noconfig.cmake exists in filesystem
dolphin: /usr/lib/cmake/DolphinVcs/DolphinVcsTargets.cmake exists in filesystem
dolphin: /usr/lib/libdolphinprivate.so.5 exists in filesystem
.
.
.
a bunch more in here
.
.
dolphin: /usr/share/metainfo/org.kde.dolphin.appdata.xml exists in filesystem
dolphin: /usr/share/qlogging-categories5/dolphin.categories exists in filesystem
Errors occurred, no packages were upgraded.
@BBreeziN
Think, it helps to deinstall dolphin first
pacman -R dolphin
and reinstall it after the package update.
Had the same issue yesterday with a very big latex font package witch were broken till upload.
P.S.: You wouldn’t loose configuration until you do a
pacman -Rns
@turux, this allowed me to complete the update, but now I can’t re-install dolphin, it fails with the same file conflict errors…
Yet dolphin still runs…which seems to probably be the issue. Dolphin is somehow installed without the dolphin package. Thoughts?
@BBreeziN
Yes. Think your pacman database is damaged.
First try to synchronize with
pacman -Syy
If this does not help there is a Arch Wiki page for that problem.
I have made a manjaro-arm kernel table for all this testing here.
If you find it usefull I will update this with the Information from here.
Did anyone get the following warning when updating?
warning: could not get file information for var/log/audit/
Aside from that, it took a couple of reboots for everything to iron itself out. After the first reboot I received an error message about a seg fault in kwin_x11:
Seems to have sorted itself out now.
Only other first impressions are that Firefox seems to be sluggish to start up, and the bouncy loading animations are gone when launching programmes on KDE.
I’m using Manjaro ARM KDE.
Yes, It seems to be an issue with our DP Altmode patches, since it does not happen on another rk3399 device (Rock Pi 4).
Yes. This seems to be caused by a regression in Panfrost.
Again, I have not seen this issue on other devices. So could also be because of the DP Altmode patches.
Hmm… seems that the login kwin_x11 segfault can be re-triggered by re-enabling OpenGL detection, as per the dialogue in the picture below:
Definitely some sort of graphical regression going on the PBP.
Wayland is still improving. It’s getting more and more usable. I haven’t spent much time with it since the update, but Firefox seems to be triggering less graphical glitches. Not sure whether it’s new, but I’ve noticed that the cursor seems to have less fluid motion when moving in front of certain windows, such as Firefox or Spyder. Still has the annoying bug where re-arranging taskbar icons crashes the session, sending you back to the login screen. However, small steps and whatnot.
Sounds like it’s when it transfers from a wayland app to a Xwayland app.
Yeah… I was pondering that.
On my PinebookPro, everything is fine. kwin_X11 doesn’t crash, no matter which rendering backend is used. However, scale method is set to ‘Crisp’, due to warning on scale method ‘Accurate’.
I have the same issue with lima drivers on tv-box(S905X). I think the problem is in mesa 20.3 (the same with mesa-git)
Previously, when the glmark2 was launched, there were no such messages:
I switched to mesa-20.2.3 with the command:
sudo pacman -U /var/cache/pacman/pkg/mesa-20.2.3-1-aarch64.pkg.tar.xz
Now I have a performance boost (~ +50% more frames with glmark/glmark2-es2) with mesa-20.2.3 and kernel 5.10.
How to switch to the wayland? I installed plasma-wayland-session but have black screen after login …
