Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vc_dispmanx_snapshot fails when screen is rotated. #267

Closed
AndrewFromMelbourne opened this issue Apr 27, 2014 · 7 comments
Closed

vc_dispmanx_snapshot fails when screen is rotated. #267

AndrewFromMelbourne opened this issue Apr 27, 2014 · 7 comments

Comments

@AndrewFromMelbourne
Copy link

When the Raspberry Pi screen is rotated (for example with display_rotate=1 in config.txt). Any call to vc_dispmanx_snapshot fails (returns -1) on first call and then hangs the program if vc_dispmanx_snapshot is called again. A reboot is then required.

Relates to AndrewFromMelbourne/raspi2png#2

I tried searching for any other reports of this issue. Only found this (http://www.raspberrypi.org/forums/viewtopic.php?p=376546#p445884).

@popcornmix
Copy link
Contributor

The same hardware block (transposer) is used for the display rotation and capturing the snapshot, so it is possible they can't be used together. I'll try and find out if this is possible.

@AndrewFromMelbourne
Copy link
Author

Thanks Dom. It looks like the problem only exist when the display_rotate is set to 1 (90 degrees) or 3 (270 degrees). When display_rotate is set to 2 (180 degrees) vc_dispmanx_snapshot() completes successfully. The horizontal and vertical flip masks are fine too, as long as they aren't used together with 90 or 270 degree rotate.

I am surprised that no one has reported this before. I would have thought that people using texy's TFT display and rpi-fbcp (https://github.com/tasanakorn/rpi-fbcp) would see the same issue.

I will put some code in raspi2png to detect if the display is rotated and fail gracefully.

@popcornmix
Copy link
Contributor

I've had a closer look at this. The transposer hardware doesn't support 24bpp, so if you bump the resource type used for snapshot to A32 when display is rotated, this should work.

There is a bug in the error handling code path where it looks like the hvs channel used for the snapshot is not released, which results in the hang on the next call.

I'll see if I can get a fix for this, but if you use A32 you shouldn't hit this problem.

@AndrewFromMelbourne
Copy link
Author

I gave it a try and at first was confused because the call to vc_dispmanx_snapshot() didn't fail when using VC_RGBA32_T, but the buffer was blank. Then I remembered that I had seen some extra flags for controlling snapshot behaviour in include/interface/vmcs_host/vc_dispmanx_types.h. So I tried calling as follows:-

vc_dispmanx_snapshot(display, resource, DISPMANX_SNAPSHOT_FILL);

Which works for VC_IMAGE_RGBA32, VC_IMAGE_RGBA16 and VC_IMAGE_RGB565 when the screen is rotated.

The only issue is that when the screen is rotated, the snapshot itself is not rotated. I tried adding a rotate flag to the snapshot

vc_dispmanx_snapshot(display, resource, DISPMANX_ROTATE_90 | DISPMANX_SNAPSHOT_FILL);

But, that didn't work. So I will need to transpose the width and height returned from vc_dispmanx_display_get_info() if the screen is rotated. I can live with this, I can just call vc_gencmd() and get "display_rotate" from "get_config int". Even if the rotate flag worked, I would need to work out if the display was rotated.

I am going to close this issue. I am happy that it is resolved. Short answer don't use VC_IMAGE_RGB888 for snapshots. It would be good if the error handling bug is fixed, but I am happy to try and avoid the problem.

@popcornmix
Copy link
Contributor

Rather than using

vcgencmd get_config int

and then parsing for display_rotate, you can just do:

vcgencmd get_config display_rotate
display_rotate=0

popcornmix added a commit that referenced this issue Jul 5, 2014
kernel: conifg: Add CONFIG_DEVPTS_MULTIPLE_INSTANCES
See: raspberrypi/linux#603

firmware: dispmanx: Fix snapshot scaling when a fullscreen dest rect is used
See: #295

firmware: dispmanx: allow rotations into 24-bit memory displays
See: #267

firmware: Add MMAL parameter for render stats
See: #287

firmware: image_decode: Move decode thread to second core
This improves jpeg decode time a little

firmware: imagefx: Separate out the fast 1080i deinterlace algorithm
As the 1080i deinterlace doesn't require the 3 frames of context we can save ~6MB by requesting it explicitly
popcornmix added a commit to Hexxeh/rpi-firmware that referenced this issue Jul 5, 2014
kernel: conifg: Add CONFIG_DEVPTS_MULTIPLE_INSTANCES
See: raspberrypi/linux#603

firmware: dispmanx: Fix snapshot scaling when a fullscreen dest rect is used
See: raspberrypi/firmware#295

firmware: dispmanx: allow rotations into 24-bit memory displays
See: raspberrypi/firmware#267

firmware: Add MMAL parameter for render stats
See: raspberrypi/firmware#287

firmware: image_decode: Move decode thread to second core
This improves jpeg decode time a little

firmware: imagefx: Separate out the fast 1080i deinterlace algorithm
As the 1080i deinterlace doesn't require the 3 frames of context we can save ~6MB by requesting it explicitly
@popcornmix
Copy link
Contributor

There is an update to firmware that should support 24bpp transposes with dispmanx_snapshot.

@AndrewFromMelbourne
Copy link
Author

Thanks I will have a look.

neuschaefer pushed a commit to neuschaefer/raspi-binary-firmware that referenced this issue Feb 27, 2017
kernel: conifg: Add CONFIG_DEVPTS_MULTIPLE_INSTANCES
See: raspberrypi/linux#603

firmware: dispmanx: Fix snapshot scaling when a fullscreen dest rect is used
See: raspberrypi#295

firmware: dispmanx: allow rotations into 24-bit memory displays
See: raspberrypi#267

firmware: Add MMAL parameter for render stats
See: raspberrypi#287

firmware: image_decode: Move decode thread to second core
This improves jpeg decode time a little

firmware: imagefx: Separate out the fast 1080i deinterlace algorithm
As the 1080i deinterlace doesn't require the 3 frames of context we can save ~6MB by requesting it explicitly
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants