drich
Posts: 50
Joined: Tue Jul 28, 2015 7:36 pm

GBM/DRM equivalent for dispmanx's layers

Sun Dec 13, 2020 3:02 pm

Hello,

I would like to know if there is a way to make an EGL transparent overlay over the screen using a Pi4, while keeping other programs visible behind it.

This was easily achievable on other Pi versions by passing a high layer value and VC_DISPMANX_ALPHA_T to vc_dispmanx_element_add().
But I don't see any equivalent for GBM, I tried passing GBM_FORMAT_ARGB8888 to gbm_surface_create but it seems uneffective.

My goal is to display a live camera preview with some GL elements over it. I could use an omx/mmal egl_render, but I need real-time rendering and this will probably decrease performances by adding memory copies

Thanks in advance

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11209
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: GBM/DRM equivalent for dispmanx's layers

Sun Dec 13, 2020 5:44 pm

GBM_FORMAT_ARGB8888 is a format with per pixel alpha, not global alpha for the plane.
Global alpha is set with the "alpha" property for the plane.

DRM always puts the primary plane as the lowest level, then overlay planes in ascending plane order, and then the cursor plane on the top.
FKMS supports the zpos property on each plane to override this, but this is viewed as not needed for vc4 seeing as all the planes have the same functionality.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

drich
Posts: 50
Joined: Tue Jul 28, 2015 7:36 pm

Re: GBM/DRM equivalent for dispmanx's layers

Sun Dec 13, 2020 9:33 pm

Thank you,
I finally got overlay mode working by using drmModeSetPlane, but it has padding all around it and I don't find anything to set it to 0.
Global alpha is set with the "alpha" property for the plane.
How can I set this property ? I don't find anything related to it in libdrm header files nor gbm.h

EDIT: I based my code on the following one : https://github.com/matusnovak/rpi-openg ... gle_rpi4.c (with glClearColor set to 0,0,0,0)
Edit2: just to be clear, I don't want a fixed alpha for my whole framebuffer, but simply a transparent background with opaque GL elements.
Also, I'm working fully in userland, using FKMS driver

drich
Posts: 50
Joined: Tue Jul 28, 2015 7:36 pm

Re: GBM/DRM equivalent for dispmanx's layers

Mon Dec 14, 2020 12:17 am

So, you've put me on the right track : I finally got a transparent buffer by using drmModeAddFB2 instead of drmModeAddFB, and forcing its pixel format to GBM_FORMAT_ARGB8888.
I removed padding simply by disabling overscan in config.txt (which seems odd, this config doesn't affect TVOUT on other Pi models).

btw, something weird just happened : I randomly have to use /dev/dri/card0 instead of card1.. (a for-loop is enough to get the right one, but I never seen this problem elsewhere while browsing about fkms)

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 11209
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: GBM/DRM equivalent for dispmanx's layers

Mon Dec 14, 2020 10:11 am

If you build and run modetest it lists out all the crtcs, encoders, and planes.
Each plane should list something like

Code: Select all

id      crtc    fb      CRTC x,y        x,y     gamma size      possible crtcs
31      87      96      0,0             0,0     0               0x00000001
  formats: XR24 AR24 RG16 RG24 BG24 YU16 YU12 YV12 NV12 NV21 P030
  props:
        8 type:
                flags: immutable enum
                enums: Overlay=0 Primary=1 Cursor=2
                value: 1
        30 IN_FORMATS:
                flags: immutable blob
                blobs:

                value:
                        01000000000000000b00000018000000
                        03000000480000005852323441523234
                        52473136524732344247323459553136
                        59553132595631324e5631324e563231
                        5030333000000000ff03000000000000
                        00000000000000000000000000000000
                        07000000000000000000000000000000
                        01000000000000070005000000000000
                        00000000000000000400000000000007
                in_formats blob decoded:
                         XR24:  LINEAR MOD_BROADCOM_VC4_T_TILED
                         AR24:  LINEAR MOD_BROADCOM_VC4_T_TILED
                         RG16:  LINEAR MOD_BROADCOM_VC4_T_TILED
                         RG24:  LINEAR
                         BG24:  LINEAR
                         YU16:  LINEAR
                         YU12:  LINEAR
                         YV12:  LINEAR
                         NV12:  LINEAR BROADCOM_SAND128
                         NV21:  LINEAR
                         P030:  BROADCOM_SAND128
        33 alpha:
                flags: range
                values: 0 65535
                value: 65535
        34 rotation:
                flags: bitmask
                values: rotate-0=0x1 rotate-180=0x4 reflect-x=0x10 reflect-y=0x20
                value: 1
        35 COLOR_ENCODING:
                flags: enum
                enums: ITU-R BT.601 YCbCr=0 ITU-R BT.709 YCbCr=1 ITU-R BT.2020 YCbCr=2
                value: 0
        36 COLOR_RANGE:
                flags: enum
                enums: YCbCr limited range=0 YCbCr full range=1
                value: 0
        37 zpos:
                flags: range
                values: 0 127
                value: 0
I haven't looked into how GBM and DRM really co-operate, but from the DRM side those properties can be set via a call to drmModeObjectSetProperty or drmModeAtomicAddProperty

Enumeration order is an annoying one. The devices probe and load when all the resources they depend on are loaded and ready. FKMS relies on the firmware, whilst v3d has very few dependencies. This means that v3d normally loads first, but it can happen the other way around. Applications really need to enumerate the devices and find the one that states it supports rendering.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

alanbork
Posts: 195
Joined: Thu Apr 23, 2020 11:18 pm

Re: GBM/DRM equivalent for dispmanx's layers

Fri May 14, 2021 5:08 pm

drich wrote:
Mon Dec 14, 2020 12:17 am
So, you've put me on the right track : I finally got a transparent buffer by using drmModeAddFB2 instead of drmModeAddFB, and forcing its pixel format to GBM_FORMAT_ARGB8888.
I removed padding simply by disabling overscan in config.txt (which seems odd, this config doesn't affect TVOUT on other Pi models).

btw, something weird just happened : I randomly have to use /dev/dri/card0 instead of card1.. (a for-loop is enough to get the right one, but I never seen this problem elsewhere while browsing about fkms)
working as expected, the order is random.
retired neuroscientist. raspberry pi hacking and monitor input lag methods: https://alantechreview.blogspot.com/

Return to “OpenGLES”