[BUG] DRM preview can't find DRM cards

[Tsid8]

# For use from the login console, when not running X Windows.

import time

from picamera2 import Picamera2, Preview

picam2 = Picamera2()
picam2.start_preview(Preview.DRM, x=100, y=100, width=480, height=320)

preview_config = picam2.create_preview_configuration({"size": (480, 320)})
picam2.configure(preview_config)

picam2.start()
time.sleep(5) 

running the above script (preview_DRM.py from examples) or any snippet that tries to open up a DRM preview I get the following error message:

  File "/home/tsid/picamera2/examples/preview_drm.py", line 10, in <module>
    picam2.start_preview(Preview.DRM, x=100, y=100, width=480, height=320)
  File "/usr/lib/python3/dist-packages/picamera2/picamera2.py", line 569, in start_preview
    preview = preview_table[preview](**kwargs)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/picamera2/previews/drm_preview.py", line 56, in __init__
    self.init_drm(x, y, width, height, transform)
  File "/usr/lib/python3/dist-packages/picamera2/previews/drm_preview.py", line 78, in init_drm
    DrmPreview._manager.add(self)
  File "/usr/lib/python3/dist-packages/picamera2/previews/drm_preview.py", line 19, in add
    self.card = pykms.Card()
                ^^^^^^^^^^^^
RuntimeError: failed to find DRM cards

I'm running a raspberry pi 4B 8gb on 64bit lite OS via SSH from windows camera used: HQ Camera module also hooked up on the pi is a Waveshare RPi LCD C 3.5 SPI screen

[davidplowman]

Hi, I'm guessing the problem will be related to the Waveshare LCD panel. Unfortunately I don't really know too much about these things, perhaps I could ask @6by9 to comment? Thanks!

[6by9]

Most SPI screens don't have a DRM driver enabled by default, and certainly 3rd party wikis tend to describe how to enable the older fbdev drivers. Use of fbcp is very much dead as it relies on DispmanX. I do have a near identical panel to this in the office. You're welcome to borrow it if you wish. I don't recall the dtoverlay runes off the top of my head for this one - I've resorted to writing it on the back of the panel with a Sharpie!

SPI displays also normally only support RGB565 or RGB888 buffers with no scaling. It's also a single primary plane. Certainly libcamera-apps normally expects to use YUV420 as the preview frame, so that would need to be amended.

[Tsid8]

# For more options and information see
# http://www.raspberrypi.org/documentation/configuration/config-txt.md
# Some settings may impact device functionality. See link above for details

# uncomment if you get no picture on HDMI for a default "safe" mode
#hdmi_safe=1

# uncomment this if your display has a black border of unused pixels visible
# and your display can output without overscan
#disable_overscan=1

# uncomment the following to adjust overscan. Use positive numbers if console
# goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16

# uncomment to force a console size. By default it will be display's size minus
# overscan.
#framebuffer_width=1280
#framebuffer_height=720

# uncomment if hdmi display is not detected and composite is being output
hdmi_force_hotplug=1

# uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1

# uncomment to force a HDMI mode rather than DVI. This can make audio work in
# DMT (computer monitor) modes
#hdmi_drive=2

# uncomment to increase signal to HDMI, if you have interference, blanking, or
# no display
#config_hdmi_boost=4

# uncomment for composite PAL
#sdtv_mode=2

#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800

# Uncomment some or all of these to enable the optional hardware interfaces
dtparam=i2c_arm=on
#dtparam=i2s=on
dtparam=spi=on
enable_uart=1
# Uncomment this to enable the lirc-rpi module
#dtoverlay=lirc-rpi

# Additional overlays and parameters are documented /boot/overlays/README

# Enable audio (loads snd_bcm2835)
dtparam=audio=on
dtoverlay=waveshare35c
#dtoverlay=ads7846,cs=1,penirq=17,penirq_pull=2,speed=1000000,keep_vref_on=1,swapxy=1,pmax=255,xohms=60,xmin=200,xmax=3900,ymin=200,ymax=3900
hdmi_force_hotplug=1
#max_usb_current=1
hdmi_group=2
hdmi_mode=1
hdmi_mode=87
hdmi_cvt 480 320 60 6 0 0 0
hdmi_drive=2

#Camera 
camera_auto_detect=1

#HQ camera module overlay
dtoverlay=imx477

is my whole boot config file I tried commenting out the waveshare3c part but I didn't see any changes through, although I didn't check to change to a hdmi out and go and use a screen and try the script again.

[6by9]

waveshare35c is not an overlay that forms part of our kernel tree, therefore I'm afraid we can offer no support for it.

You're also using

hdmi_group=2
hdmi_mode=1
hdmi_mode=87
hdmi_cvt 480 320 60 6 0 0 0
hdmi_drive=2

which are all related to the legacy display stack, having apparently removed dtoverlay=vc4-kms-v3d. Again that is a path for which you'll get no support.

I have a suspicion it is dtoverlay=piscreen,drm you want, but I will check my display tomorrow.

[6by9]

I have a suspicion it is dtoverlay=piscreen,drm you want, but I will check my display tomorrow.

My memory was right - dtoverlay=piscreen,drm.

Checking the rpicam-apps source, it is explicitly looking for the "vc4" DRM card, which an SPI display won't match. That ideally wants to be fixed.

Picamera2 doesn't appear to specify the card name and looks to pick up the right device, but it throws an assert now

>>> picam2.start_preview(Preview.DRM, x=100, y=100, width=480, height=320)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3/dist-packages/picamera2/picamera2.py", line 569, in start_preview
    preview = preview_table[preview](**kwargs)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3/dist-packages/picamera2/previews/drm_preview.py", line 58, in __init__
    self.fb = pykms.DumbFramebuffer(self.card, width, height, "AB24")
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

These SPI displays support RG16 (RGB565) and XR24 (RGB888) only. AB24 seems a slightly odd choice anyway as we don't have any alpha (AB24 is an RGBA8888 format), and I don't immediately see what this buffer is used for. I'll leave @davidplowman to answer that one. I'm not sure there is a need to use an overlay plane (which won't exist on these displays) for the preview, so picking the primary plane seems reasonable.