Framebuffer (/dev/fb0) composited in front of an EGL surface

[benosteen]

I've spent some time getting to know OpenGL ES 2.0 by working with the Pi, and have had some success. I've been working using a terminal mainly and this has been okay, but the rendered surface is overlaid on top of the terminal.

I wonder if the tty framebuffer (/dev/fb0) can be composited on top of a surface, and with an alpha mask set to black for example? The end effect would be very comparable to @mrdoob's GLSL shader sandbox: (example shader: http://glsl.heroku.com/e#2468.0 )

[dom]

I imagine you are adding your opengl surface with:

dispman_element = vc_dispmanx_element_add ( dispman_update, dispman_display, 0/*layer*/, &dst_rect, 0/*src*/, &src_rect, DISPMANX_PROTECTION_NONE, 0/*alpha*/, 0/*clamp*/, 0/*transform*/);

The framebuffer is a dispmanx layer with value -127 (i.e. behind the opengl layer).

Change the layer in your vc_dispmanx_element_add call to, say, -128 and the framebuffer will be in front.

You"ll need a 32bpp framebuffer to support alpha. E.g.

fbset -depth 32

(note: you may need recent start.elf from firmware guthub for this to be supported)

And it should work in theory…

[benosteen]

Thank you - I'd tried a few layer numbers but hadn't thought to go as low as -128!

I'll have a go with this today!

[benosteen]

Tried this, but was unable to get the fb to mask out it's background.

I adjusted the alpha of the new display and set the PREMULT flag - it's not great, but at least you can see what you are editing underneath the rendered output

[71M]

This worked for me.

Code: Select all

VC_DISPMANX_ALPHA_T			dispman_alpha;

dispman_alpha.flags = DISPMANX_FLAGS_ALPHA_FIXED_ALL_PIXELS; 
dispman_alpha.opacity = 0xFF; 
dispman_alpha.mask = NULL; 

dispman_element = vc_dispmanx_element_add( dispman_update, dispman_display, 0/*layer*/, &dst_rect, 0/*src*/, &src_rect, DISPMANX_PROTECTION_NONE, &dispman_alpha, (DISPMANX_CLAMP_T *)NULL, (DISPMANX_TRANSFORM_T)0 );

[peutipoix]

Hi,

Sorry for posting on this old topic, but I followed the fix described by dom, and enabling the 32bpp framebuffer, I end with wrong colors for pictures in DirectFB.
I tried to update the config in a coherent way (see below), but certainly missed something...
My problem is clear in the color config returned by fbset (rgba 8/0,8/8,8/16,8/24), which is not ARGB as written in /etc/directfbrc, but I don't know how to fix that....
Can someone give me a hint?

(using Raspbian Jesssy and the firmware is up-to-date)

Code: Select all

# /boot/config.txt
framebuffer_width=1920
framebuffer_height=1080
framebuffer_depth=32

Code: Select all

# /etc/directfbrc
mode=1920x1080
depth=32
pixelformat=ARGB

Code: Select all

# /etc/fb.modes
mode "1920x1080-24p"
    geometry 1920 1080 1920 1080 32
    timings 13468 148 638 36 4 44 5
    hsync high
    vsync high
endmode

Code: Select all

# fbset -i
mode "1920x1080"
    geometry 1920 1080 1920 1080 32
    timings 0 0 0 0 0 0 0
    rgba 8/0,8/8,8/16,8/24
endmode

Frame buffer device information:
    Name        : BCM2708 FB
    Address     : 0x4c7e1000
    Size        : 8294400
    Type        : PACKED PIXELS
    Visual      : TRUECOLOR
    XPanStep    : 0
    YPanStep    : 0
    YWrapStep   : 0
    LineLength  : 7680
    Accelerator : No

Code: Select all

# surface creI guess that this is a ation for picture
desc.flags  = DSDESC_WIDTH | DSDESC_HEIGHT | DSDESC_CAPS | DSDESC_PIXELFORMAT;
desc.width  = pDisplay->layer_config.width;
desc.height = pDisplay->layer_config.height;
desc.caps  = DSCAPS_FLIPPING;
desc.pixelformat = DSPF_ARGB;
DFBCHECK(pDisplay->dfb->CreateSurface(pDisplay->dfb, &desc, &pElem->surface));

[peutipoix]

This is a known bug => http://elinux.org/RPiconfig

"framebuffer_depth console framebuffer depth in bits per pixel. Default is 16. 8bit is valid, but default RGB palette makes an unreadable screen. 24bit looks better but has corruption issues as of 20120615. 32bit has no corruption issues but needs framebuffer_ignore_alpha=1 and shows the wrong colors as of 20120615. "

[dom]

This is a known bug => http://elinux.org/RPiconfig

"framebuffer_depth console framebuffer depth in bits per pixel. Default is 16. 8bit is valid, but default RGB palette makes an unreadable screen. 24bit looks better but has corruption issues as of 20120615. 32bit has no corruption issues but needs framebuffer_ignore_alpha=1 and shows the wrong colors as of 20120615. "

I'm not sure I agree.

I've just started x with 16, 24 and 32 bpp, and each time the colours were correct.

I have a suspicion that directfb doesn't query the kernel fb driver for the RGB order. E.g.
https://github.com/raspberrypi/linux/bl ... _fb.c#L124

Code: Select all

$ fbset

mode "1872x1056"
    geometry 1872 1056 1872 1056 32
    timings 0 0 0 0 0 0 0
    rgba 8/0,8/8,8/16,8/24
endmode

and just assumes the wrong order.