There is a newer bootloader version I have been holding back until new kernels are released but it produces the same result as the last one.
Wonder how this would effect our v3d testing. Iām going to watch football today and will not do any testing until tomorrow if new RPi kernels do not hit.
I am pretty confident v3d will not work. It donāt think it can, not until the v3d kernel driver adds the bcm2711 as a compatible device.
From reading the last few days I believe that these are onboard cpu/gpu chips putting different reads together and not devices that are capable of different V3D versions. One file in the linux kernel refers to them as bridges.
Broadcom 7268 (V3D 3.3)
Broadcom 7278 (V3D 4.1)
So are you telling me that I should have hope that v3d can work?
What package provides vcgencmd?
[ray@pi4 ~]$ pacman -Qo vcgencmd
/opt/vc/bin/vcgencmd is owned by raspberrypi-userland-aarch64-git r827.14b90ff-1
@0n0w1c This should make you smile. Fixing to upload new bootloader files to upstream:
Thank you all so very, very much!!
[ray@pi4 ~]$ vcgencmd version
Jan 24 2022 18:00:30
Copyright (c) 2012 Broadcom
version 94562b1518ca82ece28042cca1e5cdbbb43c8bda (clean) (release) (start)
[ray@pi4 ~]$ dmesg | grep vc4
[ 4.621040] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[ 4.631183] rc rc0: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0
[ 4.631956] input: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input0
[ 4.793147] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[ 4.826005] rc rc0: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0
[ 4.826487] input: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input1
[ 5.033683] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[ 5.051430] rc rc0: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0
[ 5.051619] input: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input2
[ 5.301109] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[ 5.305379] rc rc0: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0
[ 5.305458] input: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input3
[ 5.416155] vc4-drm gpu: bound fe400000.hvs (ops vc4_hvs_ops [vc4])
[ 5.416701] rc rc0: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0
[ 5.416780] input: vc4 as /devices/platform/soc/fef00700.hdmi/rc/rc0/input4
[ 5.418303] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops [vc4])
[ 5.425642] rc rc1: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1
[ 5.425714] input: vc4 as /devices/platform/soc/fef05700.hdmi/rc/rc1/input5
[ 5.428138] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops [vc4])
[ 5.428315] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops [vc4])
[ 5.428402] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 5.428466] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 5.428532] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 5.428583] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops [vc4])
[ 5.428749] fb0: switching to vc4 from simple
[ 5.459248] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
[ 5.512903] vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device
[ray@pi4 ~]$ glxgears -info
GL_RENDERER = llvmpipe (LLVM 13.0.0, 128 bits)
GL_VERSION = 4.5 (Compatibility Profile) Mesa 21.3.4
GL_VENDOR = Mesa/X.org
...
...
911 frames in 5.0 seconds = 182.029 FPS
914 frames in 5.0 seconds = 182.790 FPS
1 Like
Looks like the answer will be a no; for now. We got off in a side discussion when I created an issue for vc4 not working on upstream kernel where popcornmix asked about llvmpipe in glxgears I posted after the fix (mainly I wanted to be noted the Frames jumped up) and some one else came in and gave an explanation. The last 5 posts in this thread:
https://github.com/raspberrypi/firmware/issues/1688#issuecomment-1022254361
It is a shame about v3d and upstream support, but I have accepted it. Now just betting that v3d support lands before X11 is dropped from the repos. Gave up on the thoughts of wayland and sway, and have decided instead to move from Plasma to either i3wm or qtile.
Today while reading Phoronix, I noticed the DirectFB2 project, maybe it will be helpful, in the future.
5.17.0-rc1-1 does not boot via uefi. It behaves like the rpi kernels.
It seems to work fine if booted via firmware.
As the screw turnsā¦ 
5.18 boot from vc4.
- The VC4 DRM driver code notably used by the Raspberry Pi 4 will now handover display from firmware to the VC4 driver code more gracefully.
I did get a response to my post in the pi forum concerning v3d and upstream:
Re: 5.16 upstream kernel and v3d support
Quote
Sun Jan 23, 2022 5:35 pm
Correct, the last attempt by Nicolas is available here, but he's busy with other stuff, so don't expect any further version:
https://github.com/vianpl/linux/tree/v3d-enable-v3
Disappointing news but not surprising. Last touched 8 months agoā¦ so a functional v3d in the upstream kernel is likely to be years away at this point.
After much hemming and hawing, building, fiddling, and testing, I have finally found a setup that I am pleased with, for use with the upstream kernel. The lack of v3d limits the options, namely no wayland. Rather unexpectedly, I have decided on Mate with i3-gaps for the window manager. Desktop performance is excellent, even with picom, such that I do not miss the v3d, at least for my simple non-gaming needs.
1 Like
One of the reasons I use a distro is theming, especially with the older window managersā¦ not an activity that I enjoy. It drives me crazy and I usually hate what I end up with, but I got lucky this time.
Mate with Gruvbox_Dark theme (smaller menu icons) and a nice steampunk wallpaper, and Radioactive-nord (white) cursor theme. Also using i3-gaps. I have no theme answer yet for qt apps, but I do not currently have any installed, that I can think of anyway. I really like it.
2 Likes
Did.you see this small and strange release 5.16.7 ?
It only includes one vc4 patch, which reverts one old commit against vc4: https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.7
Interesting. I have experienced several random lock-ups that seem video related. I have switched to an rpi kernel to see if the lock-ups continue. Or maybe it is related to my new Mate setup? Time will tell.
Edit: I have not experienced any further lock-ups since switching to an rpi kernel.