Linux: bcm2708_fb_blank not implemented (prevents DPMS from working in X)

[AGWA]

Are there any plans to implement bcm2708_fb_blank? This function is called when the FBIOBLANK ioctl is made on the frame buffer and is supposed to put the monitor into power saving mode. Since it has not been implemented, X on the Raspberry Pi is unable to put the monitor into power saving mode (aka DPMS).

You can see the problem by running xset dpms force off in X. The monitor blanks but does not enter power saving mode, and the message "(EE) FBTURBO(0): FBIOBLANK: Operation not permitted" is printed to the X log. (It says "Operation not permitted" because bcm2708_fb_blank always returns -1, and 1 == EPERM.)

[popcornmix]

What behaviour is needed to make monitor enter power saving mode:
outputting a black screen?
tvservice -o ?

I assume when the blank is removed, you want the previous contents of framebuffer preserved?
Or will it be updated by X?

[P33M]

In the olden days (and presumably would still be valid for RCA output) if you turned off Vsync or Hsync pulses (and blanked the screen) then the monitor would enter power save mode.

http://en.wikipedia.org/wiki/VESA_Display_Power_Management_Signaling

I think for HDMI, CEC messages for suspend are required.

[popcornmix]

CEC won't help DVI monitors (and older HDMI TVs) nor composite.
And it's not simple. We only support CEC control from the ARM, so something like libCEC would be required, which wouldn't be good in a kernel module.

With my current LG TV, running:

tvservice -o

Shows "LG No Signal" on screen after a few seconds.
This persists for some minutes and then TV goes to standby, so I think it is possible for the TV to detect a lack of output, but I don't know if this is widely implemented.

[P33M]

I have a DVI monitor connected and doing tvservice -o, the Dell switches off and goes to standby pretty quick.

Unfortunately it doesn't seem to come back after a tvservice -p but I assume that is a separate issue.

[popcornmix]

Yes, "fbset -depth 8 && fbset -depth 16" or xrefresh will bring back the framebuffer.

The problem is powering off a display frees any dispmanx elements, and someone has to put them back.
That makes FBIOBLANK more complicated.

I was thinking of an mailbox message to FBIOBLANK, which when unblanked puts the framebuffer back on the display. There could still be problems if additional dispmanx layers had been added by other applicatons.
(But only the same as if you had typed in "tvservice -o && tvservice -p").

[AGWA]

Thanks for the quick replies to this.

tvservice -o puts my IBM DVI monitor into standby mode (backlight off). tvservice -p brings it out of standby, though the screen remains blank until I switch VTs (neither fbset nor xrefresh work). This seems like the right approach, assuming you can get the framebuffer back on the display after it's unblanked. I'll also see if I can test with some other DVI monitors.

[popcornmix]

fbset needs to change something or else it is no-op.
fbset -depth 8 && fbset -depth 16
should bring framebuffer back.

[AGWA]

I tested with a NEC DVI monitor, and tvservice -o and tvservice -p brings it into and out of power saving mode.

Also, section 2.4 of the DVI spec looks useful. It say that all DVI-compliant monitors must support the "active-off" power state, which is entered by disabling the T.M.D.S. link, and exited by re-activating the link. I think that means that tvservice -o/tvservice -p should be expected to work properly with any DVI monitor.

[arionl]

I'm running the standard X server (part of Raspian distro) and have a Acer monitor hooked up to my Pi via DVI. From an SSH session tvservice -o will power the display down, but as others have mentioned tvservice -p powers it back on but nothing is displayed. If I issue fbset -depth 8 && fbset -depth 16 followed by xrefresh I get a corrupt version of what was on the screen before power down -- with artifacts that look like display-resizing problems, etc.

I'm using my Pi for a kiosk display and my intension is to hook up a motion detector via GPIO that I could monitor to issue display on/off commands. Any progress on this or other approaches to control display power?

[AGWA]

@arionl, I've found the most reliable technique is to switch VTs and back after running tvservice -p. I use the following script to control the HDMI: https://gist.github.com/AGWA/9874925 - I'd be curious to know if this works for you.

[arionl]

@AGWA Thanks! I didn't realize you could switch VTs programmatically via chvt and get status with fgconsole. I'll comment further on your gist page. Still will be nice to get a formal solution implemented with standard DPMS calls, etc..

[trevd]

Hi Folks.

Here's my FBIOBLANK handling implementation using the mailbox interface like @popcornmix suggested. I know FB_BLANK_UNBLANK and FB_BLANK_NORMAL work, the others arguments but I've not tried them

static int bcm2708_fb_blank(int blank_mode, struct fb_info _info)
{
int result;
struct vc_msg msg;
printk("bcm2708_fb_blank blank_mode=%dn",blank_mode);
memset(&msg, 0, sizeof msg);
msg.tag.tag_id = VCMSG_SET_BLANK_SCREEN;
msg.msg_size = sizeof msg;
msg.tag.buffer_size = 4;
msg.tag.data_size = 4;
msg.tag.dev_id = blank_mode ;
/_ send the message */
result = bcm_mailbox_property(&msg, sizeof msg);
printk("bcm2708_fb_blank result=%dn",result);
return result;

}

I'm also adding FBIO_WAITFORVSYNC once I get head round the hows and the whys of it all :)

@popcornmix I'll submit a pull request if you want

[popcornmix]

@trevd
Sure, a PR would be good. Also good to add FBIO_WAITFORVSYNC.

[trevd]

Apologises for the spam ... That'll teach me for not doing a proper fork .

[slu-010101]

Same here, screen blank only but never power off.
This waste a lot of power in my case.

[t3chguy]

Are there any updates on this, recently got an RPi2 and running Ubuntu Mate (15.04) on it but am experiencing this issue

[lealanko]

I wrote a simple tool to work around the problem. It simply polls the X server for the DPMS state and calls tvservice accordingly. It's available here: https://github.com/lealanko/vcdpmsd

[t3chguy]

@lealanko I will install it when I next plug my Pi in and if it doesn't work for me will raise an Issue there, else will Star and Follow it; Thanks in Advance!!

Edit:
Works perfectly lealanko! Thank you very much
(Ubuntu Mate 15.04 on Raspberry Pi 2)

[popcornmix]

@lealanko you may be better off using vcgencmd display_power 0 to switch off and vcgencmd display_power 1 to switch on again. You won't lose your hdmi mode and framebuffer doing that.

We did add this into the firmware, but some applications (like omxplayer) don't stop the blanking and we got complaints about video blanking. You can enable the behaviour with hdmi_blanking=1 in config.txt.

[lealanko]

I did consider that, but calling tvservice -o lowered the Pi's power consumption measurably, unlike vcgencmd display_power 0. Maybe tvservice turned off some video processing circuits and not just the signal? Since the point of DPMS is to save power, it seemed like the more reasonable thing to use.

[t3chguy]

@popcornmix I can confirm this works for me, and is much better done at the firmware level rather than the application level; This hould be in https://www.raspberrypi.org/documentation/configuration/config-txt.md so I will PR it in shortly.

[popcornmix]

tvservice -o does kill the framebuffer, so will avoid the HVS (hardware video scaler) fetching/converting/scaling framebuffer. However you are probably talking less than 100 milliwatts.
Successfully getting your monitor into power saving mode may be saving you tens of watts.

[lealanko]

My AC power meter (of course notoriously imprecise at such low currents) showed the power of Pi2 dropping from 3 W to 2 W upon tvservice -o. I might do more precise DC current measurements later. In any case, DPMS off mode does actually turn some video hardware off both on AMD and Intel, saving several watts. Surely RPi, meant for much more power-conscious use, should follow suit?

Setting hdmi_blanking=1 indeed works, although it seems to leave the framebuffer on. I must say I'm quite miffed that I only now found out about it now after writing the workaround. There are numerous questions about DPMS not working, both on stackoverflow, the rpi forums, and of course right here. This is the first time the solution has actually been advertised.

In any case, preventing DPMS from working seems like a very questionable default. It breaks the principle of least astonishment. DPMS is a standard facility on every X desktop, and anyone using X on the Pi would expect it to work the same there as everywhere else. It's much easier to disable DPMS on X than to enable blanking on config.txt. So please consider changing the default.

[t3chguy]

I will shortly do some precise measurements on a milliamp+milliwatt scale, between hdmi_blanking=1 and tvservice -o
And I agree @lealanko that a LOT of sources want this but nowhere seems to document hdmi_blanking=1 except the changelog. I have added a PR to add this into the main MD file for the config.txt.

[t3chguy]

| Test | Current (mA) | Power (mW) |
| --- | --- | --- |
| idle Logged in | 381 | 2035 |
| hdmi_blanking | 373 | 2013 |
| tvservice -o | 343 | 1819 |

So there is a difference and saving, but it is very minor in comparison to the saving made by the Monitor actually switching into standby.

[kukabu]

I'm using a headless RPi and disabled video via 'tvservice -o'

now I see it in dmesg:
[ 1831.045696] raspberrypi-firmware soc:firmware: Request 0x00040002 returned status 0x80000001
[ 1831.045731] bcm2708_fb soc:fb: bcm2708_fb_blank(1) failed: -22

[popcornmix]

@kukabu that makes sense. If display is turned off then blanking it is impossible.
Possibly we should suppress the message, but it is harmless.

[kukabu]

@popcornmix thanks

[robbharvey]

tvservice -o will not support the requirements for my hardware application (as it produces lines within our products selected 7in touch screen). Screen blanking doesn't pose a power issue but produces too much ambient light for my specific needs (my application requires complete blackout conditions). Does anyone know of any alternatives to enable proper DPMS shutdown from the Pi?

[t3chguy]

@robbharvey read from about 10 lines up about hdmi_blanking in config.txt [https://github.com/raspberrypi/documentation/pull/245]

[robbharvey]

Thanks for the quick response @t3chguy. Unfortunately "vcgencmd display_power 0" with "hdmi_blanking=1" produces the same result as tvservice -o. This may be an issue with my choice of LCD panel (which seems to handle an absence of HDMI signals with vertical lines). Can you (or anyone else) confirm that switching the HDMI off is equivalent to a DPMS (off) result...meaning, when DPMS shuts "off" the monitor, does it just disable the HDMI port(like tvservice -o - implying the monitor responds to the absence of an input with a power saving state) or are there specific set of instructions sent to the monitor/screen to move it into a power saving mode? Thank you for your time!

[popcornmix]

@robbharvey why don't you connect the LCD to another device that supports DPMS (e.g. a windows or linux PC) and see how LCD behaves?

[falaca]

tvservice is giving me a lot of trouble, and I have DPMS disabled ("xserver-command=X -s 0 dpms" in lightdm.conf, and both BLANK_TIME and POWERDOWN_TIME set to 0 in /etc/kbd/config).

When I run tvservice -o, and then tvservice -p shortly after, I need to run "fbset -depth 8; fbset -depth 16; DISPLAY=:0 xrefresh" as others here have reported. That is no problem. However, if I leave it for a more extended period of time (~30 minutes), it doesn't work. I have a completely blank screen, and when I run fbset -depth 8 I get:

ioctl FBIOPUT_VSCREENINFO: Invalid argument

And my dmesg is full of these sort of errors:

[ 2428.465039] raspberrypi-firmware soc:firmware: Request 0x00048003 returned status 0x80000001
[ 2428.465056] bcm2708_fb soc:fb: Failed to allocate GPU framebuffer (-22)
[ 2428.465062] detected fb_set_par error, error code: -22
[ 2428.465288] raspberrypi-firmware soc:firmware: Request 0x00048003 returned status 0x80000001
[ 2428.465303] bcm2708_fb soc:fb: Failed to allocate GPU framebuffer (-22)
[ 2428.465309] bcm2708_fb_pan_display(0,0) returns=-22

This seems to be more easily reproducible if omxplayer is running when I run tvservice -o. So I modified my cron job to first shut down omxplayer and then turn off the display. My results seem to be a bit different (before, both fbset -depth 8 and fbset -depth 16 used to throw errors, but now only the former throws the error). I'm really not concerned about 1 or 2 watts, I just want to be able to shut down the TV and turn it back on the next day. @popcornmix maybe I'll try vcgencmd display_power 0 and vcgencmd display_power 1 like you suggested in one of your comments above.

Is this the right place to report this, and is there any further information I can provide?

[falaca]

So I tried "vcgencmd display_power" instead, and for a few hours it seemed to be working, but then something went wrong and this is what I got in dmesg after typing "vcgencmd display_power" in the terminal (without a 1 or 0, I just wanted to see it print out the status):

[ 8517.172639] ------------[ cut here ]------------
[ 8517.172713] WARNING: CPU: 0 PID: 20641 at drivers/misc/vc04_services/interface/vchiq_arm/vchiq_arm.c:2484 vchiq_release_internal+0xb8/0x264()
[ 8517.172787] Modules linked in: cfg80211 rfkill ip6table_filter ip6_tables iptable_filter ip_tables x_tables bcm2835_rng bcm2835_gpiomem snd_bcm2835 snd_pcm snd_timer snd uio_pdrv_genirq uio i2c_dev fuse ipv6
[ 8517.172929] CPU: 0 PID: 20641 Comm: HTV Notify Not tainted 4.1.17+ #834
[ 8517.172947] Hardware name: BCM2708
[ 8517.173017] [<c0016a1c>] (unwind_backtrace) from [<c00138dc>] (show_stack+0x20/0x24)
[ 8517.173052] [<c00138dc>] (show_stack) from [<c052df78>] (dump_stack+0x20/0x28)
[ 8517.173096] [<c052df78>] (dump_stack) from [<c00237ec>] (warn_slowpath_common+0x8c/0xc4)
[ 8517.173128] [<c00237ec>] (warn_slowpath_common) from [<c00238e0>] (warn_slowpath_null+0x2c/0x34)
[ 8517.173164] [<c00238e0>] (warn_slowpath_null) from [<c036587c>] (vchiq_release_internal+0xb8/0x264)
[ 8517.173196] [<c036587c>] (vchiq_release_internal) from [<c0366534>] (vchiq_ioctl+0x840/0x1740)
[ 8517.173236] [<c0366534>] (vchiq_ioctl) from [<c0132dd8>] (do_vfs_ioctl+0x3f0/0x5bc)
[ 8517.173268] [<c0132dd8>] (do_vfs_ioctl) from [<c0132fe8>] (SyS_ioctl+0x44/0x6c)
[ 8517.173299] [<c0132fe8>] (SyS_ioctl) from [<c000f500>] (ret_fast_syscall+0x0/0x54)
[ 8517.173318] ---[ end trace f5af9a7ec2528f9d ]---
[ 8517.173339] vchiq: vchiq_ioctl: cmd VCHIQ_IOC_RELEASE_SERVICE returned error -1 for service TVNT:20638

In the terminal, I got the following output:

vc_gencmd_send returned -1
vchi_msg_dequeue -> -1(22)

[popcornmix]

@falaca Can you provide a way of reproducing the issue?
e.g. provide a script that when run on a clean raspbian image produces that failure?

[falaca]

@popcornmix For the first issue (using tvservice), it's very easy for me to reproduce. Just start a live RTSP stream with omxplayer, run tvservice -o, wait roughly 30 minutes, and then run tvservice -p. The screen will be blank, and trying to "revive" it with fbset and xrefresh will generate those errors in dmesg.

I start omxplayer via /etc/xdg/autostart, with the following bash script:

#!/bin/bash
until false; do
    stream=`cat /home/pi/streamvid/stream.txt`
    omxplayer --live --threshold 0 $stream
    echo "Restarting omxplayer..."
    sleep 3
done

And I have a cherrypy (python) web application running, which listens on localhost:8000/tvon and /tvoff, and executes a bash script that runs tvservice -p or -o when it receives a GET request at those URLs. I also autostart the web application in /etc/xdg/autostart. It doesn't make a difference whether I run the command manually or through the web app, but I'm sharing just in case it matters in some way that doesn't occur to me.

As for the stack trace that came up last night when I tried "vcgencmd display_power" instead of tvservice, I restarted the pi and it seems like so far today it hasn't reoccured. So it seems like that might be an intermittent issue, as opposed to the omxplayer/tvservice issue which is easily reproducible.

I am running Raspbian Jessie, and almost everything is default (no overclocking or anything) except for disabling DPMS via lightdm.conf and /etc/kbd/conf. Other than that, I just have a few python and bash scripts as described above.

[falaca]

@popcornmix I ran some more tests tonight (on a different raspberry pi and different TV) and found out what the real issue was - now I have a simple and bullet-proof way for you to reproduce it.

It turns out that it has nothing to do with omxplayer - I had neglected another change that I made last week, which was to add a /snapshot URL to my web application, which returns a screenshot of the raspberry pi taken with this little program: https://github.com/AndrewFromMelbourne/raspi2png

So here's how to reproduce the problem:
1) Boot up into the default Raspbian desktop (I have only tested this issue with the GUI running)
2) ssh into the raspberry pi
3) Run tvservice -o
4) Run ./raspi2png -w 240 -h 135 -c 1 -s > /dev/null several times in quick succession (I just copy/paste and then press up/enter on my keyboard ~20 times)
5) Each time you run the command, you will see the error raspi2png: vc_dispmanx_snapshot() failed
6) Run tvservice -p

After the above steps, your display will be blank. Running fbset -depth 8 && fbset -depth 16 && DISPLAY=:0 xrefresh as suggested in some of the above comments will be ineffective, and result in the error messages in dmesg which I shared previously.

Interestingly, I realized when testing on the other raspberry pi that the latest commit to that program fixes the issue by checking that that the display handle returned by vc_dispmanx_display_open() is not 0 before attempting to call vc_dispmanx_snapshot(): https://github.com/AndrewFromMelbourne/raspi2png/commit/808fb0221e3a5e52e9f0c685cbe5fd7e0ac7911e

So to reproduce this bug, you will have to revert that last commit. So to put it simply, I believe that this bug is triggered by running vc_dispmanx_snapshot() with 0 as the first function parameter while the HDMI port is powered off.

[falaca]

@popcornmix After compiling the updated version of raspi2png, everything seemed to be working fine throughout the day (the TV was turning on and off at the scheduled times, and I would occasionally check my web interface to make sure that it was displaying the correct content). About an hour ago I pulled up my web interface and just left it running on the side. It grabs an updated thumbnail of the display (240x135 pixels) every 5 seconds, and eventually I got the kernel oops again. This was with display_power set to 0, and just displaying the default Raspbian desktop (I modified my cron job to stop omxplayer when it shuts off the TV). So I think there must be more issues with the firmware's snapshot API.

Here's the stack trace:

[88010.798884] ------------[ cut here ]------------
[88010.798956] WARNING: CPU: 0 PID: 25716 at drivers/misc/vc04_services/interface/vchiq_arm/vchiq_arm.c:2484 vchiq_release_internal+0xb8/0x264()
[88010.798975] Modules linked in: cfg80211 rfkill ip6table_filter ip6_tables iptable_filter ip_tables x_tables bcm2835_gpiomem snd_bcm2835 bcm2835_rng snd_pcm snd_timer snd uio_pdrv_genirq uio i2c_dev fuse ipv6
[88010.799071] CPU: 0 PID: 25716 Comm: HTV Notify Not tainted 4.1.17+ #834
[88010.799084] Hardware name: BCM2708
[88010.799151] [<c0016a1c>] (unwind_backtrace) from [<c00138dc>] (show_stack+0x20/0x24)
[88010.799242] [<c00138dc>] (show_stack) from [<c052df78>] (dump_stack+0x20/0x28)
[88010.799286] [<c052df78>] (dump_stack) from [<c00237ec>] (warn_slowpath_common+0x8c/0xc4)
[88010.799318] [<c00237ec>] (warn_slowpath_common) from [<c00238e0>] (warn_slowpath_null+0x2c/0x34)
[88010.799354] [<c00238e0>] (warn_slowpath_null) from [<c036587c>] (vchiq_release_internal+0xb8/0x264)
[88010.799386] [<c036587c>] (vchiq_release_internal) from [<c0366534>] (vchiq_ioctl+0x840/0x1740)
[88010.799427] [<c0366534>] (vchiq_ioctl) from [<c0132dd8>] (do_vfs_ioctl+0x3f0/0x5bc)
[88010.799459] [<c0132dd8>] (do_vfs_ioctl) from [<c0132fe8>] (SyS_ioctl+0x44/0x6c)
[88010.799557] [<c0132fe8>] (SyS_ioctl) from [<c000f500>] (ret_fast_syscall+0x0/0x54)
[88010.799579] ---[ end trace 524380e672d2d838 ]---
[88010.799646] vchiq: vchiq_ioctl: cmd VCHIQ_IOC_RELEASE_SERVICE returned error -1 for service TVNT:25709

So basically these are 2 separate bugs:
1) Described in my previous post, where the framebuffer is permanently killed as a result of attempting (and of course failing) to take a snapshot after running tvservice -o.
2) Kernel oops occurs after taking many snapshots after setting display_power set to 0.

Edit: Also, I was able to reproduce (1) on another raspberry pi + TV, but I haven't tried to reproduce (2). The other TV I'm using supports CEC so I'm able to turn that one on/off using cec-client. So I seem to have no issues taking snapshots as long as the raspberry pi's HDMI port is active.

[Ruffio]

@AGWA has this issue been resolved? If yes, then please close this issue.

[TheTechnoGuy]

My #1 issue with my Raspberry Pi boards is that I can't walk away and leave the display turned on because VESA Display Power Management (DPMS) doesn't work. It works on Beaglebone Black - why not on Raspberry Pi? I've been waiting 2 years for a fix; I think there are many other people waiting for this fix as well. Please do NOT close this until the problem is resolved.

[t3chguy]

@TheTechnoGuy try what I tried adding to the config.txt docs
https://github.com/raspberrypi/documentation/pull/245

[popcornmix]

bcm2708_fb_blank was implemented in kernel with:
https://github.com/raspberrypi/linux/commit/bbbf1fc3697bb4ba419630ab6deb1cc79d6af0f3

We initially disabled the HDMI based on that, but it caused issues for apps that didn't use the framebuffer (e.g. omxplayer) which would lose the display after a few minutes.

So, it is now optional. Enable with hdmi_blanking=1 in config.txt.

[t3chguy]

@popcornmix or anyone else that may be able to help, anything you can do to get https://github.com/raspberrypi/documentation/pull/245 applied, as https://www.raspberrypi.org/documentation/configuration/config-txt.md still contains no mention of hdmi_blanking.

[xeusito]

hdmi_blanking works great with Touchscreen monitor 27" iiyama T2735MSC.

I was wondering if anyone knows how to adjust the time rpi waits until it switches the monitor off.

[t3chguy]

@xeusito it'll be in userland, as in likely whatever screensaver your DE ships with will trigger it. So configure that

[xeusito]

erhm.. could you be a bit more specific? I'm not sure what userland means.. is it somewhere in folder /usr?
and DE means distribution right? I'm running raspbian jessie with pixel kernel 4.4.

Thanks !

[t3chguy]

Sorry, DE is Desktop Environment, as in Pixel
Probably a menu in some Pixel settings pane.
I will likely install Pixel later on today so will get back to you if you cannot find it.