The new kernel + kms + xorg + kwin compositor enabled seems to be good. It now boots and plays youtube videos in Firefox without issue.
There is more coming as soon as I get it them compiled and tested. They all seem to be kms/vc4 related upgrades.
Kernel upgrade to 5.10.76 also with vc4/kms improvements
New raspberry pi-bootloader packages that seems to be related
https://github.com/raspberrypi/firmware/commit/c8c985aed7b849deefc77236d9fc550ee7bec15d
https://github.com/raspberrypi/linux/commit/ef073f6a5205cd98aea2474bc4a59e7fb0f3476c
Interesting. Did you notice the cause of this shake-up? If I understood correctly, they switched to using the upstream kms helpers. I wonder if that means vanilla is expected to have (or will have) full video support?
Edit: But it does all seem to be strictly vc4 related, no mention of v3d.
They had vc4/kms in “staging” and broke it about 2 years ago so RPi went in another direction to get it going again. Lately it appears the RPi and upstream are starting to flow the same direction. So it is not out of the realm of possibility.
Here is the latest linux-rpi4 upgrade and the latest 2 raspberrypi-bootloader packages. These packages go hand in hand with each other (and most likely with the latest 5.15 kernel posted above) with the latest vc4/kms changes.
All pushed to the unstable branch when the mirrors sync.
linux-rpi4 5.10.77-1
linux-rpi4-headers 5.10.77-1
raspberrypi-bootloader 20211105-1
raspberrypi-bootloader-x 20211105-1
I hope they settle down soon. Compiling multiple kernels each day is getting old.
I decided to give plasma + wayland + kms another try. I added this to /etc/environment
MOZ_ENABLE_WAYLAND=1
MOZ_DBUS_REMOTE=1
and then rebooted and started a plasma-wayland session. And so far, no lock up, ran glxgears and watched a youtube video in firefox. There are flashes of static when the mouse hovers over a compositor effect, but it no longer hangs. I would say it is functional, but still needs some work.
update to 5.15-4, plasma/wayland/kms, so far so good, thanks.
With the help of @Jtyle6 and his pi zero 2 we have bluetooth working on this device. It is a BCM43430B0 and the kernel was looking for BCM.hcd firmware to load. So I made a temporary link “ln -s BCM43430B0.hcd BCM.hcd
” in the firmware-raspberrypi package for now in /usr/lib/firmware/updates/brcm/.
The new firmware package has been pushed to all branches when the mirrors sync.
firmware-raspberrypi 7.1-1
To have bluetooth on the pi zero 2:
sudo systemctl disable attach-bluetooth.service
# Add this to config.txt:
dtparam=krnbt=on
Then reboot
Bluetooth dmesg Loading Summary
[ 9.317710] Bluetooth: Core ver 2.22
[ 9.317921] Bluetooth: HCI device and connection manager initialized
[ 9.317948] Bluetooth: HCI socket layer initialized
[ 9.317966] Bluetooth: L2CAP socket layer initialized
[ 9.317999] Bluetooth: SCO socket layer initialized
[ 9.413331] Bluetooth: HCI UART driver ver 2.3
[ 9.413354] Bluetooth: HCI UART protocol H4 registered
[ 9.413469] Bluetooth: HCI UART protocol Three-wire (H5) registered
[ 9.442578] Bluetooth: HCI UART protocol Broadcom registered
[ 9.777708] Bluetooth: hci0: BCM: chip id 115
[ 9.779152] Bluetooth: hci0: BCM: features 0x0e
[ 9.781390] Bluetooth: hci0: BCM43430B0
[ 9.781417] Bluetooth: hci0: BCM (002.001.012) build 0000
[ 9.785933] Bluetooth: hci0: BCM ‘brcm/BCM.hcd’ Patch
[ 10.455083] Bluetooth: hci0: BCM4343B0 37.4MHz wlbga_iLNA_iTR [Baseline: 0092]
[ 10.455112] Bluetooth: hci0: BCM (002.001.012) build 0092
[ 11.245674] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 11.245701] Bluetooth: BNEP filters: protocol multicast
[ 11.245741] Bluetooth: BNEP socket layer initialized
[ 40.889898] Bluetooth: RFCOMM TTY layer initialized
[ 40.889950] Bluetooth: RFCOMM socket layer initialized
[ 40.889998] Bluetooth: RFCOMM ver 1.11
@Jtyle6 Desktop showing connected using LXQT DE.
I would blured the Mac address for the bluetooth oh well.
I should done my self. But I forgot about it.
Sorry about that. Was not thinking. Fixed.
PiOS released Bullseye kernel-5.10 with KMS by default.
does kernel-5.10 same between manjaroarm.
Their kernel used as a base with some more modules enabled so things work people have requested here in the forums.
The latest linux-rpi, linux-rpi-mainline and raspberrypi-bootloader packages has been pushed to the unstable branch when the mirrors sync.
linux-rpi4 5.10.78-1
linux-rpi4-headers 5.10.78-1
linux-rpi4-mainline 5.15.1-1
linux-rpi4-mainline-headers 5.15.1-1
raspberrypi-bootloader 20211108-1
raspberrypi-bootloader-x 20211108-1
Seems with 5.15.1-1 + xorg + kms + compositor enabled issue is back. At least for me, it would not boot.
Could do a git bisect to see where it breaks. Takes a while with a kernel though.
I always disable the Compositor on arm.
I usually disable it too, but I was testing it. I did not try wayland, maybe @Rip2 will try it.
I have never tried to bisect code before, I imagine there would be a learning curve.
can not confirm work or not, plasma/kwinft-git/mesa-git/wayland/kms, etc.
Interesting, does this configuration run well?
looks good, switch to chromium & vulkan-1.1, no firefox freeze anymore.
Graphics Feature Status
- Canvas: Hardware accelerated
- Canvas out-of-process rasterization: Enabled
- Compositing: Hardware accelerated
- Multiple Raster Threads: Enabled
- Out-of-process Rasterization: Hardware accelerated
- OpenGL: Enabled
- Rasterization: Hardware accelerated on all pages
- Skia Renderer: Enabled
- Video Decode: Hardware accelerated
- Vulkan: Enabled
- WebGL: Hardware accelerated
- WebGL2: Hardware accelerated
PiOS has a new arm_boost=1 option in config.txt, overclock to 1800.
does it related to last bootloader update?