[BUG] Does not run on fkms driver on Bullseye RasPi Lite

[makermelissa]

Please only report one bug per issue!

Describe the bug
With a fresh install of Raspberry Pi OS Lite (Bullseye 64-bit), when attempting to run with the fkms driver it results in an error (see below).

To Reproduce
Fresh install of Raspberry Pi OS Lite (Bullseye 64-bit)
Run update and upgrade
Install python and git
git clone picamera2
Make sure vc4-fkms-v3d is enabled in /boot/config.txt (reboot if changing)
libcamera-hello should work fine
Attempt to run the preview_drm.py example results in error.

Expected behaviour
A preview window should appear

Console Output, Screenshots

[0:01:53.670866595] [2022]  INFO Camera camera_manager.cpp:293 libcamera v0.0.0+3866-0c55e522
[0:01:53.697089203] [2034]  WARN RPI raspberrypi.cpp:1258 Mismatch between Unicam and CamHelper for embedded data usage!
[0:01:53.698339062] [2034]  INFO RPI raspberrypi.cpp:1374 Registered camera /base/soc/i2c0mux/i2c@1/imx219@10 to Unicam device /dev/media3 and ISP device /dev/media1
[0:01:53.754169076] [2022]  INFO Camera camera.cpp:1035 configuring streams: (0) 640x360-XBGR8888
[0:01:53.754749302] [2034]  INFO RPI raspberrypi.cpp:761 Sensor: /base/soc/i2c0mux/i2c@1/imx219@10 - Selected sensor format: 1920x1080-SBGGR10_1X10 - Selected unicam format: 1920x1080-pBAA
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python3.9/threading.py", line 954, in _bootstrap_inner
    self.run()
  File "/usr/lib/python3.9/threading.py", line 892, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/lib/python3/dist-packages/picamera2/previews/null_preview.py", line 25, in thread_func
    callback(picam2)
  File "/usr/lib/python3/dist-packages/picamera2/previews/drm_preview.py", line 35, in handle_request
    self.render_drm(picam2, completed_request)
  File "/usr/lib/python3/dist-packages/picamera2/previews/drm_preview.py", line 110, in render_drm
    raise RuntimeError("Failed to reserve DRM plane")
RuntimeError: Failed to reserve DRM plane

Hardware :
Pi 4 8GB

Additional context

[davidplowman]

Hi, thanks for the question. Perhaps the documentation isn't very clear here, or is assuming too much prior knowledge. The DRM preview can only work when X windows is not running. (You can use Ctrl+Alt+F1 to suspend X windows to try this; use Ctrl+Alt+F7 to return again.) Does that answer the question?

[makermelissa]

Hi, I was under the impression X windows was not running on Raspberry Pi OS Lite. Is that not the case? Either way, pressing this key combination changed nothing, so unfortunately this doesn't fix the bug.

[makermelissa]

Ok, I did a little more digging into this and it looks like the initial format is XBGR8888 which is unavailable according to some debug printing I added in. I changed it to BGR888 which was an available mode and then it got stuck at Failed to reserve DRM overlay plane and this is because it tried to create a plane of type ABGR8888, which is also unavailable.

I ran the fbset command to show available video modes and here's what it has available.

pi@raspberrypilite:~ $ fbset -i -v
Linux Frame Buffer Device Configuration Version 2.1 (23/06/1999)
(C) Copyright 1995-1999 by Geert Uytterhoeven

Opening frame buffer device `/dev/fb0'
Using current video mode from `/dev/fb0'

mode "3840x2160"
    geometry 3840 2160 3840 2160 16
    timings 0 0 0 0 0 0 0
    accel true
    rgba 5/11,6/5,5/0,0/0
endmode

Getting further frame buffer information
Frame buffer device information:
    Name        : vc4drmfb
    Address     : 0
    Size        : 16588800
    Type        : PACKED PIXELS
    Visual      : TRUECOLOR
    XPanStep    : 1
    YPanStep    : 1
    YWrapStep   : 0
    LineLength  : 7680
    Accelerator : No

Perhaps the correct video modes were removed from the fkms driver or something. Maybe you have some more ideas. It might be as simple as adding some kind of parameter to the fkms driver to enable more video modes.

[davidplowman]

Hi, sorry that I misunderstood your question initially. I've run through all the different cases and here's what I've discovered.

1. If you use the kms (not fkms) driver, everything works - both libcamera-hello and Picamera2. Was this the same for you? We recommend using the kms driver wherever possible as the fkms one exists for legacy OS/application support.

2. When using fkms, libcamera-hello works but Picamera2 does not (as you reported).

The reason for this is that the fkms driver has incomplete support for RGB-with-alpha formats. I believe it supports ARGB but not ABGR which (by unlucky coincidence) is the format the Picamera2 often defaults to, and also uses all the time for overlays. The former can be overridden (as you've done), but not the latter which is hard-coded.

So in the first instance, obviously I would recommend using kms if you can, and if there's a problem with that we would of course investigate it. Alternatively, you could run your own version of Picamera2. You simply need to clone the repository and list it in your PYTHONPATH environment variable. Then you could edit the overlay format here. I'd be open to PR to make this configurable, though I'd be keen to ensure that all the preview implementations retain identical functionality.

[makermelissa]

Ah, ok. No worries. I'm trying to do something with picamera2 that I was able to with the first picamera, which is to show the output on a TFT display that is only connected through SPI. To do that, it is using FBCP, which I'm not sure how long that will work for, but it's the only thing working at this point. When I tried through the KMS driver, I get the same Failed to Reserve Plane error when no HDMI cable is plugged in and it outputs to HDMI only when it is plugged in.

So, making this a setting that could be overridden would be super helpful. I'm trying to put the instructions on how to do this into a guide for other folks, so having while having it available only in a custom fork would certainly be an option, it's not ideal because I would like to make this setup as easy for other folks as possible. I would be happy to help with testing out changes for this.

By the way, you've done an awesome job with rewriting picamera2 and while it loses some backwards compatibility, it does things in a much better way and I found the code well written that I could follow along for the most part.

[makermelissa]

Also, I did try and edit it, but stopped after an error occurred a few lines down for the line self.overlay_plane.set_prop("pixel blend mode", 1). I don't recall the exact error message though.

[davidplowman]

I'll put this on my list to have a look at, though I have a few other things to do first. In the interim, I'd have thought it would be enough just to replace ABGR8888 on that line by ARGB8888 and leave everything else the same...

[makermelissa]

Yes, thank you. I think I tried BGR888 and that's why I got the error.

[davidplowman]

I've decided to patch our kernel so that the missing ABGR format is support, it turns out to be a small change. It will take several days for this to filter through to being available via sudo rpi-update. A small patch also looks to be required to Picamera2 but I was planning to make a minor update release this week anyway so I'll push the change in time for that.

[makermelissa]

Oh awesome.

[davidplowman]

So I think all the changes for this should be in place now. You'll need the latest version of Picamera2 (sudo apt install -y python3-picamera2 which should get you version 0.3.5). You'll also need to do sudo rpi-update and then reboot. The usual warnings apply with rpi-update - it will fetch the most bleeding edge firmware so don't do it with an SD card that has anything on it that you can't afford to lose!

[makermelissa]

Awesome. I'll try it out when I'm feeling a bit better and am back at my desk.

[makermelissa]

Ok I tested this without doing rpi-update and verified picamera2 was at 0.3.5 with pip show picamera2 and it seems to be working. Thank you so much.