try to install it (it is in testing) xf86-video-fbdev-0.5.0-aarch64-2.txz

I did install it - that was the whole point of updating for me. Reported are the results of my testing. It's crapping out for the lack of the fbdevHWSave symbol. Read my last post.

A bit further down the road here.

I mirrored your current from slackware.uk (bandwidth is better) and went over the image with 'updatepkg --install-new' to make sure I got whatever was going. Sorted out many, many teething issues. I'm living with the overscan for the moment and promising myself a rebuilt kernel without the framebuffer driver, and I'm back on standard cpu/gpu frequencies for the moment. [1.5Ghz/500Mhz]

I have the fledgeling fbdev driver installed [/usr/lib64/xorg/modules/drivers/fbdev_drv.so], and with no X video configuration it load, but is immediately dropped for the lack of the fbdevHWSave symbol. I found that in /usr/lib64/xorg/modules/libfbdevhw.so. I even symlinked it from /usr/lib64 & re-ran ldconfig, but still nothing.

Searching online suggests I have to preload libfbdevhw.so, although that driver is for a bunch of sbcs, and that was on another Arm sbc & distro. Others were hitting permission problems and changing the permissions on /dev/fb0, but there's no pattern really. How would I preload libfbdevhw.so? I can't find anything on that. I did cobble up this config from "man fbdev" & "man fbdevhw" but the fbdev driver is still thrown out for the lack of fbdevHWSave function in libfbdevhw.so. After I spotted a reference to 'xf68' in one man page, I also tried ' Option "UseFBDevhw" ' in that config. Out of ideas here for the moment, but shift that config file, and X works the old way.

Are you getting that thing working?

works for me

Yeah, that works. But the fbdev driver isn't loading, the GPU h264 block isn't even enabled on h264 videos(!) and rendering on mkv movies suck. In this command I just get the core, v3d & pixel clocking. Debian has core, h264, isp, v3d & pixel. The image I'm using has a file date in 2020!

I had an sdcard here which was gone; the symptom was that it was causing dd to go into zombie mode at 10-11G. But the 64bit Debian/Raspbian beta [dated 2020-05-27] is only 4G, so that ran on that dodgy sdcard. The story is the same. 60-70% cpu & perfect rendering on Debian. 250-OTT% on my test mkv, along with this message from mpv Debian's 64bit omits the kernel config (also 5.15.x). I googled that phrase "forcing the x11 VO" and was led To this post on the Pine64 forum The panfrost driver is out of kernel, because the code sucks, but is in Mesa and works some of the sbcs you spin versions for, just not the RazPi. Panfrost Blurb

Debian loads the 2020 vintage fbdev driver, but unloads it again. Your setup won't load it. If I make it a necessity by tweaking configs, X pukes. I did load the fbdevhw module first, but the driver still won't load. I have your latest mesa [22.3.1]. Debian also has loads of bells, whistles, & plugins for vlc if that makes any odds. It's the one optional piece of kit they provide on 64 bits. But vlc isn't a rendering engine.

So I can eliminate a major difference in X by comparing log files. I can't eliminate either kernel, vlc or Mesa because Debian is stripped so bare. I might try swapping a kernel someday, to see what chnge that makes.

But the bottom line is that I (or slarm64) can't drive one 1920x1080 monitor, when the RazPi is supposed to handle 2 x 4k monitors. There seems to me little point in churning out fresh versions of something that works so poorly, when your time might be better spent getting the RazPi graphics to suck less. It certainly can be done, because Debian were doing it two years ago.

Patches to code are unlikely as I'm no coder. I have assembler, VHDL, PLC languages, that's about all. I could probably bone up on cobol, but that was 50 years back!

But I hope to narrow the field considerably Here's the problem. Below are the options for measuring gpu clocks The pixel is output runs faster than the GPU clock. You only get the v3d block on, and I'm not even sure that's getting used. Debian has the h264 & isp blocks on as well, and it rocks. Slarm64 has them off, and it sucks.

I'm not letting go of this. I have Manjaro & Ubuntu on a disk & usb key and I'll try them later. I'll also try Slackware Arm. I can mirror that and "upgrade" my ssd. They have made it such a PITA to install with their slavish conformity to the X86 distro. An Arm64 is not an X86_64! RazPi boot madness is not the X86_64 BIOS mess. And DrMozes & Exaga are both prickly.

My current hunch is that your problem is something in Mesa, but I'll try to get more specific. Because at the end of the day, I don't want Manjaro or Ubuntu, I'd prefer Slackware. And of the available Slackware choices, I'd prefer yours.

I tried The Ubuntu & Manjaro images .

They both fell over badly, so I have queries in the respective forums. One good thing was that somebody linked me to This Thread which appears to be GPU devs back in 2020. It's a bit over my head, but I did pick up that the H264 block (which you need) is only accessible through the VPU firmware. My Debian image is from 2020-05-27, so they obviously sorted themselves out, as the thread date is March/April 2020.

That might change the complexion of how driving the VPU is approached.

I've put some time and research into this graphics issue. I'm going to sound like a conspiracy theorist, but here's what I came out with.

It appears RPi OS/Debian have a march on other distros in the graphics dept for their RazPi OS. The rpi 0-3 paid licenses for video decoding, but the rpi 4 VPU decodes with “no external codecs.” I wonder. If a manufacturer changes a chip significantly, they always, always change the part number, just like adding features to software bumps the version. The rpi 3 needed a licensed codec. The rpi 4 doesn't, so Broadcom say. So Broadcom added a gpu feature, but they didn't change the part number - BCM2835. So I smell a rat. My guess is, some HEVC codec is programmed into the BCM2835 on the RPi 4. That means OSS could access it if they knew how.

Broadcom were never any friend of open source. I conclude that either Broadcom are breaking somebody's copyright, or are being unnecessarily restrictive. Either way, my hunch is that Debian/RPi OS have something video-wise under a strict NDA, and can't share it. The Raspberry lot must have heaped pressure on Broadcom. Broadcom sells by doing deals where Broadcom supplies all your parts for a project at a discount. Broadcom chips are rarely the highest spec, So there's big money at play. I came across old threads between Broadcom devs & Debian devs, where Broadcom were giving Debian as little info as they could get away with. The Debian devs were demanding solutions. There's also a lot of chat about a HEVC (High Efficiency Video Codec) which is mentioned but never detailed. Broadcom apparently "developed" it. I wonder.

The Software heads on RPi OS forums were of the opinion (last year in certain locked threads) that a 1080p video won't play at 60Hz, and recommend dropping to 50Hz refresh. That, I presume, is without RPi OS's extra edge, which is probably under NDA. I may try 50Hz. The RPi OS plays videos nicely with only 60-70% CPU @60Hz. That's a massive difference.

Another thing I read was that something in vlc is negatively affected by the 'fkms' (presumably vc4-fkms-v3d-pi4.dtbo) line in config.txt. I don't know if that's sorted. But it's worth noting if vlc sucks, because the 'fkms' overlay interfered with vlc.

But the take away for me is that Debian had something in 2020 that let them decode video in the GPU. Probably Broadcom used this HEVC (or somebody else's) codec to achieve low cpu load. Other Arm distros have to do it the hard way with software rendering. I'm pretty sure Debian are 100% above board. I'm not sure about Broadcom. If they had this great VPU that decoded that well, (and using so little cpu) you would think they'd be jumping up and down about it and pushing it. They are keeping it very quiet indeed. And it's the same part they were paying codec licenses for in the RPi 3. You can't stock two different parts with the same part number. But you can stock the same part, and program it differently in two different production lines.

I compared the RPi OS software laboriously to yours. No extra codecs/modules are in the kernel; They're not in VLC; They are not in the /boot firmware; I don't think they are in Mesa either. So that leaves the GPU/VPU. You can hide a few Megs in an SoC these days. And a simple patch like clocking the h264 & isp blocks (which Debian do) is a few bytes that could be patched in somewhere and I'd never notice. The rest of us have the GPU but can't use it. I told you I'd sound like a conspiracy theorist.

The RazPi OS github has a kernel on github with build instructions here. It builds version 5.15.84+. It also has a ‘make bcm2711_defconfig' target, which is handy. I built it as instructed on my RazPi. Sure enough, video was better than the vanilla kernel, but not by the margin that Debian is better than the vanilla kernel. Cpu usage in mpv (250%-OTT) dropped about 50%(out of 400%), but the spread was more uneven so the video dragged slightly and sound went out of synch. VLC might well be OK. By comparison Majaro with mpv only did slow motion, and Ubuntu errored on installing vlc (error 139 on libc-bin) and vlc froze.

Remember my overscanning problem? it's gone on (Debian's) 5.15.84+. So overscanning is a kernel issue. Your kernel 6.1.3 doesn’t overscan either, and responds to settings in config.txt. But your 5.15.85 & 6.0.9 did overscan regardless of settings. The 5.15.84+ & 6.1.3 kernels are about equal video wise. There’s recent activity on that raspberrypi github, so I presume upstream patches are being applied.

I've been at this as far as I can go, and stopped. Here's what I came up with.

Other distributions I have tried are worse than slarm64 playing multimedia, if anything. The notable exception is Debian/RPi OS, which has some inside track. When The Raspberry Pi was released, they boasted these specs

Open source isn't getting near that. Exaga did an OpenGL test on 2 4k monitors and got 30fps. My nasty suspicious mind suspects Broadcom of providing a fix under a strict Non Disclosure Agreement. Debian wouldn't keep it so quiet unless they signed a NDA. And This High Efficiency Video Codec(HEVC) is everywhere mentioned but never detailed. It makes me wonder whose copyright are Broadcom breaking. That's my nasty suspicious mind again. Debian do have some stuff on github.

1.http://github.com/raspberrypi/linux builds a 5.15.84-v8+ kernel which offers a slight reduction in cpu load playing videos.

2. Debian acknowledged This patched ffmpeg as being the best effort at the time by some distance. It builds version 4.3.1, I think.

3. the same guy has some work done on vlc. It offers a few build options for the rpi and one to merge ffmpeg libs. I don't know if they are standard.

I built these but the versions are too old. In each case it seems the wise thing to do is extract the commits and patch a newer version. But that's not in my skill set, so I've left things there.

Reverse engineering is a skill I posess, and you're able to read quite a bit into some exchanges in the various locked threads on the raspberry pi forum.

I think I have solved this, without particularly trying.

I left this and tried building Kodi from git, and ran aground. They have merged the Kodi rpi tree with the main linux branch, because there was no commits since 2019, which augurs badly for any compile. But LibrElec works. Then I noticed the only way offered to install Kodi was using apt, or compile the git. That set me sniffing.

It turns out Broadcom wrote their own driver for the bcm2835 video, but only shared it with raspberrypi/Debian. So comparing with Nvidia for a second - it's like Debian (and LibreElec) have the closed source driver, the rest are stuck on nouveau, without the option of grabbing the closed source driver! There's even Broadcom header files lying about in /opt/vc/include.
There's a whole pile of headers in /opt/vc/include, which their scripts go to some bother to exclude from a block copy to /usr/include. There's even a OMX_Broadcom.h file up there, for heaven's sakes

As the driver is closed source, It strikes me that a polite request for a binary download link from yourself, Slackware Arm, Red Hat, Ubuntu, etc. all together might be the best way to approach it. They certainly won't listen to me. There's no reason why they should have a working driver and not share it.
Because all that will do is send people away bad-mouthing Broadcom in the community which can hinder sales, but cannot help them. Their Licence is free enough. So there's no reason not to share it.