robertoj

Share your DTS, maybe you missed something Run: dmesg | grep -E 'spi|panel' and post the result I already saw the online store... it is the same LCD that I use (I have both 3.5" and 4.0" and they work with the same DTS and bin file)

Make sure to power the VCC and LED with 3.3v, not 5v

Hmmm ok Now I am out of ideas. Are you using a downloaded armbian image? I have been using only self-compiled armbian images... (I need features of the latest linux-edge) It also prevents some problems if you uninstall or disable plymouth (interferes with loading the firmware file).

Uninstall the debian v4l2loopback package Did you add the build parameter to build for your specific kernel version? Did you do the final "make install" step? https://github.com/v4l2loopback/v4l2loopback?tab=readme-ov-file#build-for-a-different-kernel Search in the raspberry pi forum also

The online store link doesnt work Did you try lowering the SPI frequency? Are you using the panel-mipi-dbi-spi driver? I have no idea about the timing parameters in the firmware bin file. Are you familiar with notro's python script that turns a txt into a firmware bin file? There's a chance that your LCD is bad. Try buying an extra LCD. Future note for when you succeed with the driver: X11 will not work. There's a driver issue. If you can compile MESA3D you might get the needed updated driver. I have been using wayland+labwc... and I am currently in the effort to add a wayland greeter for the display manager (lightdm or greetd). (search my threads)

post the link of the online store where you bought your LCD. Why do you describe your problem as "offset", if your problem is a big rectangle that covers 25% of your screen?

Try a lower SPI frequency and use direct wires from the orange pi zero 2w to the LCD There might be something in the panel-mipi-dbi-spi.bin firmware to improve the display of the received bytes, but first do these two improvements (first try the direct wires) Opiz2w cases: https://forum.armbian.com/topic/52880-orangepi-zero-2w-wrong-color-display-on-mpi3501/ https://forum.armbian.com/topic/44191-orangepi-zero-lts-ili9341-tft-lcd-and-later-orangepi-zero-3/page/2/ https://forum.armbian.com/topic/46824-orange-pi-zero-3-ili9486-tft-lcd/

Does this package exist? (sorry I am away from my armbian device) https://packages.debian.org/bookworm/v4l2loopback-dkms

My DTS is for the Orange Pi Zero 3. There's another thread that shows the correct GPIO wiring and DTS GPIO definitions for Orange Pi Zero 2w.

It probably means that you are close to having it work. 75% of the effort (or good luck) results in the LCD displaying noise or bad image. What model LCD? Photos? Confirm the wiring matches the default SPI terminals and the custom GPIO I included in the DTS. Are you connecting the touch chip terminals? LInux and armbian version? Downloaded or self compiled? Run the tests I have shown in several of my LCD threads: ili9341, ili9488.

Thank you... I will try with trixie again some time

Thank you but my use case is orange pi zero 3 and orange pi zero 2w… they are 64 bit H618

I got hardware acceleration working in wayland+labwc, in Bookworm, Linux 6.15.4, self built armbian With a self-compiled labwc (instructions: https://forum.armbian.com/topic/53797-labwc-wayland-crashes-on-exit/#findComment-223267 ) And the ffmpeg instructions in the original post were used with no changes... plus the extraargs=cma=256M in armbianEnv.txt Side question: can anybody make hardware acceleration work in Trixie?

Yes. Correct. Start with an armbian minimal or xcfe image that you build, with linux edge. Then install all the compilation dependencies mentioned in https://github.com/labwc/labwc/wiki and https://github.com/swaywm/sway/wiki/Debian-10-(Buster)-Installation#install-wlroots Some are mentioned as indicated for raspberry, but I installed them as well Do not install the debian bookworm libwlroots10 !! (this old wlroots interferes with the wlroots that will be installed now) Do not install libelogind-dev (it tried to modify my initramfs, it messed up the boot process, I didnt actually need it) You need a meson compiler more recent than bookworm provides. Install the backports repo: https://backports.debian.org/Instructions/ $ sudo apt install meson/bookworm-backports $ meson -v 1.7.0 Getting the labwc source code, and building: $ sudo apt install foot seatd (a minimal xterm for wayland, and a "seat manager" (may not be needed)) $ git clone https://github.com/labwc/labwc $ cd labwc $ meson setup build <-check that you have at least the GLES2 or EGL renderer If not, check that you have these dependencies: libegl-dev, libegl1-mesa-dev, libgles2-mesa-dev, libgles-dev If xwayland is desired, install xwayland from the bookworm repo After installing extra dependencies, run reconfiguration: $ meson setup --reconfigure build You will notice that the labwc build process auto-downloads and compiles a recent wlroots Finally compile (it took less than 5 minutes in my orange pi zero 3) $ meson compile -C build If it finishes compiling, check that the produced labwc works with: $ ./build/labwc -s foot If there's an error about memory allocation, add to armbianEnv.txt "extraargs=cma=256M", then reboot To install globally: $ sudo meson install -C build Test by exiting the labwc folder: cd ~ $ labwc -s foot Tomorrow, I will continue installing a display manager and greeter that works with wayland... since I am trying to avoid X11, due to my SPI LCD driver But all of you who try getting labwc in bookworm, hopefully the meson install command does something that lets lightdm see it is available as an option (I started with a minimal image)

I didn't try to replicate the problem in x86... but I compiled the latest labwc 0.9.0, in Orange Pi Zero 3 with Bookworm, and this problem does not show up

Thank you for the information I have completed the build dependencies step, for mesa 25.2, in Debian Trixie. However, when I build it, my orange pi zero 3 with 1 GB or RAM, it runs out of memory... even when I make a swap file of 2GB. I keep rebooting the opiz3, and continue the compilation job. Is this normal? In the raspberry forum, they told me that my LCD driver panel-mipi-dbi.ko doesn't work with X11... so I give up on this, and continue my development with labwc/wayland (easily installed in Trixie)

Thank you. I found that libllvmspirvlb 19 is only available in trixie... can you confirm? In bookworm, I needed to replace llvm-18-dev libclang-18-dev libllvmspirvlib-18-dev with llvm-19-dev libclang-19-dev libllvmspirvlib-15-dev But tomorrow I will try again with trixie

Thank you for your suggestions. I am trying to build Mesa in my Orange Pi Zero 3. When I tried installing the build dependencies, apt could not find libxatracker-dev, libllvm-18-dev, libspirv-tools-dev i added changed "deb-src" in the /etc/apt/debian.list, so I could download *-dev packages. How did you install all the dependencies? Are you in Bookworm, or Trixie? Actually I am looking for a double benefit with a new Mesa (bookworm provides mesa 22.3.6, trixie provides 25.0.7): *H264 hardware acceleration *I know that Raspberry has a newer Mesa (don't have it at hand), and X11 can handle the same LCD, with the same kernel module panel-mipi-dbi.ko

I have seen other threads where they recompile mesa to get an updated so module for X11, related to LCD panels and DRM. I haven't had time for that yet.

Sensor integration: buy a OBD2 to USB adapter and study the OBD2 codes to read the fuel liters/hour, km and km/h. It is very possible there is a python OBD2 library. The SBC should be running continuously in the vehicle, since the car electronic control unit does not have the memory to store the information for you. Python+tkinter/pyqt6+matplotlib is very effective for this kind of apps.

Has anybody had success with Armbian Trixie? I repeated the steps I did for Bookworm, to have HW accelerated H264 1080p in XFCE, X11, with Linux 6.15.4... and I get "Unsupported hwdec: drm" in Trixie: ffmpeg 7.1.1, mpv 0.4.0 mpv log in trixie (with double verbose): For reference, mpv log in Bookworm: I inspected ffmpeg build configuration, and I see that ffmpeg 7.1.1 doesn't have "--enable-libv4l2", while ffmpeg 5.1.6 has that option. I checked with "ffmpeg -codecs|grep h264" In bookworm: In trixie Although, here the ffmpeg manual reads that this is option is only for webcams and videocapture https://www.ffmpeg.org/ffmpeg-devices.html#video4linux2_002c-v4l2

Do you see all the needed files in the initramfs? Use lsinitramfs -l /boot/initrd... What guide did you use?

I would try the cma=256M argument anyway... this kernel argument eliminated my video glitches and dma errors. I don't know how a dtsi or dtbo parameter (loaded after linux is started) would override a kernel argument (given before the linux kernel is started).

Successful playing of H264 1080p mp4 Orange pi zero 3, 1GB Self-built Bookworm, with XFCE desktop Linux edge 6.15.4 No changed linux configurations Using ffmpeg+libraries provided in the first post of https://forum.armbian.com/topic/32449-repository-for-v4l2request-hardware-video-decoding-rockchip-allwinner/ (you can even install all the bookworm ffmpeg, mpv, then when you add the new repository, update and upgrade, apt will replace the packages with their ffmpeg-v4l2request equivalents) Testing 1080P H264 (warning, some mp4's will actually be AV1 codec), checked with VLC Compositor on or off, doesn't make a difference. Video plays at full 30 fps To avoid video glitches during window resizing: add "extraargs=cma=256M" in /boot/armbianEnv.txt With hwdec=drm-prime, CPU is 50% in all 4 cores With hwdec=drm, CPU is 10% or less in all 4 cores Without HW acceleration, CPU is 100% in all 4 cores with many skipped frames mpv.conf and mpv log: Reveal hidden contents THANK YOU to all who gave me updated information! Edited just now by robertoj

You are right. I just downloaded something from youtube and assumed it was H264. When I checked it in VLC in my PC, the codec is: AOMedia's AV1 video (av01) I picked another mp4, which I verified in VLC as H264-MPEG4, 720p, and it played with 10% CPU This test below is with Bookworm XFCE, compositor ON, Linux 6.15.4 with default configuration Then I repeat the test with a 1080p H264 mp4. mpv tries to use hardware acceleration, but the mpv is black and there's continuous DRM_IOCTL errors: Then I tried this inside /etc/mpv/mpv.conf hwdec=drm-prime drm-drmprime-video-plane=primary drm-draw-plane=overlay and the 1080p H264 starts playing fluidly with just 40% CPU (compositor off) With compositor on, I get same 40% CPU Same video glitches, with or without compositor, but I am getting hardware acceleration (although there's the hwdec unsupported message) Update: Thank you to all who helped me. I have hardware acceleration again with my opiz3 hwdec=drm is more efficient extraargs=cma=256 is needed to avoid memory allocation problems and video glitches. https://forum.armbian.com/topic/29202-orange-pi-zero-3/page/26/#findComment-222596