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

tvservice -o then tvservice -p results on powered on dipslay but donthing displayed. #892

Closed
pssc opened this issue Mar 17, 2015 · 9 comments

Comments

Projects
None yet
3 participants
@pssc
Copy link

commented Mar 17, 2015

I have tried this with two different displays and 3.12 and 3.18.... on a B+ and rev2 B.

@popcornmix

This comment has been minimized.

Copy link
Collaborator

commented Mar 17, 2015

That is normal. Powering off the destroys any overlays (of which the framebuffer is one).
You can recreate it with "fbset -depth 8 && fbset -depth 16"

@pssc

This comment has been minimized.

Copy link
Author

commented Mar 17, 2015

The app I have is sdl based and still outputting to the screen so seeing,
Mar 17 14:33:46 raspberrypi user.err fbcp[3318]: Unable to snapshot -1. (60)
Mar 17 14:34:00 raspberrypi user.info kernel: [ 326.704707] bcm2708_fb_ioctl 40044620,0 returns=0 p[1]=0x80000001
Mar 17 14:34:00 raspberrypi user.err kernel: [ 326.704940] bcm2708_fb_pan_display(0,0) returns=16
Mar 17 14:34:46 raspberrypi user.err fbcp[3318]: Unable to snapshot -1. (120)
Mar 17 14:35:00 raspberrypi user.info kernel: [ 386.693696] bcm2708_fb_ioctl 40044620,0 returns=0 p[1]=0x80000001
Mar 17 14:35:00 raspberrypi user.err kernel: [ 386.693907] bcm2708_fb_pan_display(0,720) returns=16

Tried restoring with
(tvservice -p && sleep 2 && fbset -depth 8 && fbset -depth 16) 2>&1
no screen output
Mar 17 14:43:26 raspberrypi user.warn kernel: [ 268.637255] detected fb_set_par error, error code: 16
Mar 17 14:43:26 raspberrypi user.err kernel: [ 268.649473] bcm2708_fb_blank(0) returns=0 p[1]=0x80000001
Mar 17 14:43:26 raspberrypi user.info kernel: [ 268.821121] bcm2708_fb_ioctl 40044620,0 returns=0 p[1]=0x80000001
Mar 17 14:43:26 raspberrypi user.err kernel: [ 268.821395] bcm2708_fb_pan_display(0,0) returns=16
Mar 17 14:43:26 raspberrypi user.info kernel: [ 268.972086] bcm2708_fb_ioctl 40044620,0 returns=0 p[1]=0x80000001
Mar 17 14:43:26 raspberrypi user.err kernel: [ 268.972286] bcm2708_fb_pan_display(0,720) returns=16
Mar 17 14:43:26 raspberrypi user.info kernel: [ 269.105637] bcm2708_fb_ioctl 40044620,0 returns=0 p[1]=0x80000001
Mar 17 14:43:26 raspberrypi user.err kernel: [ 269.105901] bcm2708_fb_pan_display(0,0) returns=16

changing VT at this point resulted in pi wedging.

@popcornmix

This comment has been minimized.

Copy link
Collaborator

commented Mar 17, 2015

The sdl app will have created it's own framebuffer and will have a pointer to the framebuffer memory, so it will have to handle this itself.
Really I think you should not power off HDMI when apps are using the screen.
You can use:

vcgencmd display_power 0

and

vcgencmd display_power 1

which is a less intrusive way of removing the HDMI output signal but leaves the overlays intact.

@pssc

This comment has been minimized.

Copy link
Author

commented Mar 17, 2015

Yes the SDL app used a HW double buffer allocated via the kernel fb device and pans between the two buffers, I am redrawing the buffer after, issuing the restore command set. according to the out put of fbset -i the fb address doesn't change after going through the power cycle, but I don’t think that’s believable and is probably out of sync hence the crash on vt change. Force a mode change at that point to reallocate the fb and update the pointers?

That all said vcgencmd display_power (minus the s on displays) would seem to do what I want (implementing a soft off) thanks you.

@pelwell

This comment has been minimized.

Copy link
Contributor

commented Mar 17, 2015

There is a patched version of the SDL library referenced from this Forum post (http://www.raspberrypi.org/forums/viewtopic.php?f=38&t=99822&p=692525&hilit=sdl#p692525) that copes with the base address of the FB changing on a resolution change. It might be worth trying that version to see if it behaves better.

@pssc

This comment has been minimized.

Copy link
Author

commented Mar 17, 2015

@pelwell lol yes that was me, from that page ;-)

You can read about the problem here - raspberrypi/firmware#354 - Luckily someone called pssc had already fixed the main issue as part of their squeezeplay work, and so I incorporated the fix into an updated SDL package.

@pelwell

This comment has been minimized.

Copy link
Contributor

commented Mar 17, 2015

LOL indeed. In my defence, it was a while ago, and one unpronounceable handle looks much like another...

@popcornmix

This comment has been minimized.

Copy link
Collaborator

commented Mar 17, 2015

The framebuffer memory allocated is not freed when power goes off, but any dispmanx elements will be removed. If you are using the dispmanx backend of sdl, then the usual dispmanx_element_add sequence will get the framebuffer back on the display.
If you are using the default framebuffer back end, then you will need to change it to make it get removed/added. Effectively do the same as "fbset -depth 8 && fbset -depth 16" from within SDL (e.g. change size or depth).
However the "vcgencmd display_power" solution is probably simplest.

@pssc

This comment has been minimized.

Copy link
Author

commented Mar 19, 2015

vcgencmd display_power coded solution does what I need so closing the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.