robertoj

Thank you for the comment Jock Yes, I know that Trixie's mpv made some changes that made it incompatible with your ffmpeg+v4lrequest package. I tried to compile mpv, and I wasn't sure of how to do it. I asked for help in the mpv github, and someone told me to wait for ffmpeg to merge this function. https://github.com/mpv-player/mpv/pull/14690#issuecomment-3369553163 Recently, I got more suggestions to build ffmpeg for Trixie https://github.com/mpv-player/mpv/pull/14690#issuecomment-3828170966 Boringname... can you specify which Debian version, Linux kernel and graphical desktop (kde, xfce, gnome, plasma, labwc, sway)?

There was a successful test with Debian Forky in RK3566 I saw some progress and success in the last 2 days. Someone made compiled ffmpeg 8.0+v4l2request and made it work in Debian Forky... which also carries ffmpeg 8.0 https://github.com/mpv-player/mpv/pull/14690#issuecomment-3500141427 Does this mean that I need to use Debian Forky too? (I was staying with Debian Bookworm because H264 hwaccel only worked there) References: https://code.ffmpeg.org/Kwiboo/FFmpeg/src/branch/v4l2request-v3 https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20847 https://tracker.debian.org/pkg/ffmpeg

Yes. Please wait. I was busy with other personal projects, so I haven't been doing armbian stuff for a few weeks.

I don't know what you could improve right now... But I know that LCD only receives data. My LCD works the same, with its MISO pin connected or disconnected.

Yes, that's a typo. The dc (data/command) should be PC7, and the MOSI (LCD's SDI) is PH7

Yes. Probably this week.

Is your LCD at least turning white on powerup? Did you connect the "LED" pin in the LCD, to 3.3V? Send a drawing of how you are connecting the LCD to the orange pi zero 3.

Thank you Pearo, What does "S/N" mean? I just ended up using my orange pi zero 3 gpio without the additional DTS, which made connector numbering available in the gpioinfo command... There were comments that made it sound not really necessary, and it was more work than I wanted to take on. The solution for me was: https://forum.armbian.com/topic/33800-orange-pi-zero-3-gpio/#findComment-181191 This was 2 years ago, and I haven't even thought about it, all this time.

I really hope that Orange Pi engineers learn to make Armbian patches, enter the community and give funding accordingly

Great I thought RiscV was still much slower than ARMs of similar prices.

I got surprised by "GPU: Mesa llvmpipe" ... but then I searched, and it means CPU rendering. But still very nice!

While it didn't give an solution, 👆 this is a good answer. It matches my concept of what armbian-build does, as I learned it 3 years ago (from reading the documentation and experimentation)

I just thought that a inserting a cpio file would be accepted, just like inserting a c file into the linux source code. I have never done a source file insertion myself, with neither C or cpio file... but I assumed it would work, since it is a common need for linux patches. In this page, they talk about the "--new-file" feature of the diff command https://unix.stackexchange.com/questions/37287/how-to-include-a-new-file-into-a-patch

Thank you guys for the work toward this RiscV SBC The website http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-RV2.html claims 130% faster than ARM A55 (which is 25% slower than my H618)... have you tested that? Are the USB, GPIO, SPI and MIPI DSI working? Are there any NPU examples provided by Orange Pi?

I missed the fact that you have an orange pi zero 2w... I think there's a success experience with that orange pi in this thread or in this Allwinner section. Please share if you have success