Linux: tvservice -o then tvservice -p results on powered on dipslay but donthing displayed.

Created on 17 Mar 2015  ·  9Comments  ·  Source: raspberrypi/linux

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

Most helpful comment

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.

All 9 comments

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"

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.

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.

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.

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.

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

You can read about the problem here - https://github.com/raspberrypi/firmware/issues/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.

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

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.

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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

unkissedfrog picture unkissedfrog  ·  9Comments

mi-hol picture mi-hol  ·  8Comments

Joulinar picture Joulinar  ·  5Comments

XECDesign picture XECDesign  ·  6Comments

awlx picture awlx  ·  4Comments