dispmanx snapshot and dispmanx full screen layers

[AndrewFromMelbourne]

When vc_dispmanx_snapshot() is called and the data is read with a VC_RECT_T that is smaller than screen size, dispmanx layers that have been stretched full screen by using a zeroed out destination rectangle when calling vc_dispmanx_element_add() do not fill the resulting snapshot.

As an example. omxplayer has a command line option -b / --blank (set background to black). In the omxplayer code the method blank_background() is called to create a 1x1 pixel dispmanx layer in the background that is stretched full screen. The screen dimensions are not used in the destination rectangle when vc_dispmanx_element_add() is called, rather the destination rectangle is set with x, y, width and height all set to zero.

If I call vc_dispmanx_snapshot() and retrieve a snapshot using the screen dimensions. These stretched layers appear as they do on the screen. However, if I call vc_dispmanx_snapshot() with width and height that is smaller than the screens dimensions the stretched layer only takes up a fraction of the screen (in the top left hand corner).

Here is an example:

Running omxplayer

omxplayer -b --win "200 168 520 408" /opt/vc/src/hello_pi/hello_video/test.h264

Using a 720x576 display

tvservice -s
state 0x80002 [PAL 4:3], 720x576 @ 50.00Hz, interlaced

Taking a 400x300 snapshot (using raspi2png https://github.com/AndrewFromMelbourne/raspi2png)

The background layer only takes up the top right hand corner of the screen.

I can reproduce this problem on two different Raspberry Pis (a Model A and Model B). I can also reproduce the problem when the Raspberry Pi is plugged into an HDMI TV.

vcgencmd version
Jun 26 2014 21:08:07 
Copyright (c) 2012 Broadcom
version 87aee38aa98517e53651d3400bf9261beb20c3e7 (clean) (release)

vcgencmd get_config int
sdtv_mode=2
program_serial_random=1
config_hdmi_boost=2
emmc_pll_core=1
hdmi_force_cec_address=65535
temp_limit=85
force_pwm_open=1
pause_burst_frames=1
avoid_fix_ts=1

I have a small test program that demonstrates the problem (https://gist.github.com/AndrewFromMelbourne/dd193fe0d7e6ac5c5343).

Let me know if you need any more information.

[AndrewFromMelbourne]

Perhaps I should add some context to this, otherwise it may appear to be fairly esoteric. A number of people who use TFT displays attached to the Raspberry Pi via the GPIO pins use a program called rpi-fbcp (https://github.com/tasanakorn/rpi-fbcp/blob/master/main.c) so that they can see videos etc on their little TFT screens. The rpi-fbcp program calls vc_dispmanx_snapshot() / vc_dispmanx_resource_read_data() with the width and height of the TFT so that the GPU scales the image that it to be displayed on the screen. The rpi-fbcp program is affected by this bug.

[popcornmix]

Okay I can see an issue here. Can you try this test firmware build. It is a fixed memory split build (256M/256M).
https://dl.dropboxusercontent.com/u/3669512/temp/start_snap.elf

[AndrewFromMelbourne]

Thank you very much! Yes, works for me!

[popcornmix]

Let me know if you spot any regressions with this firmware, but otherwise the fix will be in next rpi-update firmware.

[popcornmix]

Now pushed in official update.
Please run rpi-update and close if good.

[AndrewFromMelbourne]

Thanks! Everything I can test works well. Thanks for all the help!

[AndrewFromMelbourne]

@popcornmix, it appears that this issue has re-appeared. I can see this issue both in the current master and next branches of the firmware. I have not had a chance to narrow down the firmware commit that re-introduced this issue.

tested using composite output with a Pi2 and a 512Mb Pi B.
tested using HDMI output with a Pi2

Easiest way to reproduce is

omxplayer -b /opt/vc/src/hello_pi/hello_video/test.h264 (as long as test.h264 doesn't fill the screen).

[AndrewFromMelbourne]

Appears to be fixed again. Must have been a temporary regression.