RPi 5 - HDMI audio output not working with separate HDMI

[davideparpinello]

Hi,
I'm trying to configure HDMI audio output with two separate HDMI video outputs, but with the option dtoverlay=vc4-kms-v3d disabled (so to allow separate framebuffers) the audio devices are not showing. If I enable it the audio device is showing, but the HDMI video outputs are cloned. I'm trying to achieve two separate framebuffers, as I want to show on HDMI1 the terminal and HDMI2 a stream coming from FFmpeg. I would prefer not to use a desktop environment or similar to have a very lightweight system.

aplay -l
aplay: device_list:274: no soundcards found...

This is my config.txt

# For more options and information see
# http://rptl.io/configtxt
# Some settings may impact device functionality. See link above for details

# Uncomment some or all of these to enable the optional hardware interfaces
#dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on

# Enable audio (loads snd_bcm2835)
#dtparam=audio=on

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

# Automatically load overlays for detected cameras
camera_auto_detect=1

# Automatically load overlays for detected DSI displays
#display_auto_detect=1

# Automatically load initramfs files, if found
auto_initramfs=1

# Enable DRM VC4 V3D driver
#dtoverlay=vc4-kms-v3d
max_framebuffers=2

# Don't have the firmware create an initial video= setting in cmdline.txt.
# Use the kernel's default instead.
#disable_fw_kms_setup=1

# Run in 64-bit mode
arm_64bit=1

# Disable compensation for displays with overscan
#disable_overscan=1

# Run as fast as firmware / board allows
arm_boost=1

[cm4]
# Enable host mode on the 2711 built-in XHCI USB controller.
# This line should be removed if the legacy DWC2 controller is required
# (e.g. for USB device mode) or if USB support is not required.
otg_mode=1

[all]
disable_fw_kms_setup=1
# HDMI output configuration

# console 1366x768 60Hz
[HDMI:0]
hdmi_force_hotplug:0=1
hdmi_group=2
hdmi_mode=81

# output 1280x720 50Hz
[HDMI:1]
hdmi_force_hotplug:1=1
hdmi_group=1
hdmi_mode=19
dtparam=audio=on
#hdmi_drive:1=2

Thanks in advance

[popcornmix]

The recommended way forward would be to use the kms driver, lite image (or boot to console) and the use DRM to drive each display.

kmstest, modetest and drmu may be suitable examples you can look at to guide you.

[6by9]

On Pi5 there is no firmware audio support, therefore you will get no audio devices if you disable vc4-kms-v3d.

Do you actually mean terminal (ie console) for HDMI1, or just /dev/fb0?
As DRM only supports a single master, as soon as FFmpeg tries using DRM for rendering the stream it will blank other outputs, so still rendering /dev/fb0 is tricky.

You've also got fun either:

• trying to co-ordinate FFmpeg directly opening DRM with your app also needing the handle
• opening DRM yourself, and passing in the DRM fd and plane handle to FFmpeg
• getting dmabuf handles back from FFmpeg to be rendered by your app.

[davideparpinello]

Do you actually mean terminal (ie console) for HDMI1, or just /dev/fb0?

Exactly, basically I would need console on HDMI1, and an FFmpeg output on HDMI2. So I don't know if it's possible to have a single framebuffer only for HDMI2, while console will be shown somehow on HDMI1. I don't need any v3d accerelation or any

[6by9]

Exactly, basically I would need console on HDMI1, and an FFmpeg output on HDMI2. So I don't know if it's possible to have a single framebuffer only for HDMI2, while console will be shown somehow on HDMI1. I don't need any v3d accerelation or any

I think that one is going to be tricky.
DRM's framebuffer emulation is one FB per DRM card, and it is totally internal when there is no other DRM master active on the card.
Any efficient rendering for graphics is going to be through DRM, so that limits options.

About the only approach I can think of is to add a mechanism to be able to retrieve the handle for the framebuffer so that the DRM master can add it back onto the displays it wishes. That's highly unlikely to be acceptable to upstream, but is possibly small enough for us to accept as it is likely to be useful.

I think it's dma_obj at https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_fbdev_dma.c#L98 that you need to export, although the comment at https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/drm_client.c#L451 may imply that there are other issues.