Disable video via tvservice vs vcgencmd

[jakemagee]

While trying to reduce power usage on a headless / lite RPi 3B module, I tested differences using vcgencmd display_power 0 and "hdmi_blanking=2" in config.txt (from raspberrypi/firmware#352). I had come to the conclusion that the video output was being automatically disabled when an HDMI cable was not connected since neither reduced my power usage any amount. However, by chance I tried tvservice -o and instantly saw a 17mA reduction.

Is this expected? If so, can anyone explain what tvservice -o does that the other commands do not?

[hex007]

Any updates on this ?

@jakemagee Can you test it with latest image if the problem still persists?

[popcornmix]

vcgencmd display_power 0 just disables output from the hdmi PHY.
This allows display to go into a low power mode.

tvservice -o disables the whole display pipeline, including clocks, the Hardware Video Scaler, the Pixel Valve, fetches of display layers from sdram etc.

So, yes, tvservice -o will have a larger effect on power consumption.
However tvservice -o will generally break running apps that are using dispmanx, but vcgencmd display_power 0 will have no effect on them.

[hex007]

Yea I noticed that the Display 0 cannot be opened after calling tvservice -o

@popcornmix "hdmi_blanking=2" is equivalent to vcgencmd display_power 0 rather than tvservice -o ?

I was hoping for a solution in raspberrypi/firmware#352 that actually disabled the entire pipeline rather than just the HDMI. This would help with decreasing the power draw. I agree that tvservice -o can certainly be used in rc.local to achieve the same effect.

Is there a chance of total disabling of video pipeline from boot to be implemented?

[popcornmix]

hdmi_blanking uses the sample disabling logic as vcgencmd display_power 0.

Is there a chance of total disabling of video pipeline from boot to be implemented?

I'll have a look, but there could be complications with kernel frame buffer driver.

[jakemagee]

Thanks for the information @popcornmix ... that's exactly what I was looking for. Do you think this information was already documented somewhere and I just overlooked it? If not, do you think it should be?

I wouldn't complain about having the tvservice -o functionality in config.txt, but I can also see it being rejected as low priority and adding more code / complication for little return.

[hex007]

Considering that this code is hackish and not stable it is better to not add it to the official documentation. Its

[popcornmix]

I don't believe it is formally documented as the behaviour of two commands is quite low level and isn't something that 99% of users would be advised to use.
The difference has been explained a number of times in forum and github threads. e.g.
raspberrypi/linux#892

[jakemagee]

I think for headless projects / OS this might be a common desire to have. Especially in low power, solar, battery type situations (the majority of my use cases). A 10% lower power draw from one command that disables unused functionality is a win-win in my book. I added the info to my personal notes and its obviously here in github now to be found / referenced, so that's good enough for me.

[popcornmix]

Is there a chance of total disabling of video pipeline from boot to be implemented?

@hex007 If display is disabled at boot, are you happy that display is not available until a reboot?
I had a quick look and it doesn't look hard to display display display init on boot, but kernel framebuffer init will fail and you don't get a /dev/fb0 so I'm not sure if can subsequently enable framebuffer.

[jakemagee]

That would be fine from my perspective...

[popcornmix]

You could try this firmware: https://drive.google.com/uc?id=1AZxW2nKor4MHuGkgCwtHkW4MwtWuVeJ-&export=download
By default hdmi initialisation will be skipped and composite will be the default if hdmi is disconnected on boot (or hdmi_ignore_hotplug=1)
Add hdmi_ignore_composite=1 to also avoid the composite initialisation. That should result in:

pi@domnfs:~ $ tvservice -s
state 0x120001 [TV is off]

on boot and hopefully the lower power state. There may be some complaints in dmesg log due to the missing framebuffer but this didn't appear to be fatal to me.

[jakemagee]

I'll give it a shot first thing in the morning and report back.
Thanks!

[hex007]

@popcornmix Yea actually in headless state it would be fine to have no display at all. There is no hard requirement of headless and high uptime. If debugging is needed a quick reboot works for me.

[jakemagee]

I see the frame buffer failure messages as well... however, I'm curious if the "bcm2835-clk can't lock PLL" trace messages are possibly an indication of something more serious.

[popcornmix]

I suspect the kernel hasn't been tested without PLLH running (used by hdmi/composite).
I don't imagine it will cause any issues.

[jakemagee]

Fair enough... I wasn't sure what else might be using that clk / PLL.

I'm not sure what else needs to be done on this issue before closing... my original question was answered way back. There's a good chance that I'll just stick with running tvservice -o on boot so that I don't have to keep track of ignoring the clk PLL trace message in my logs.

[popcornmix]

Okay, I'll close. You have a couple of options for reducing power by disabling the display output.

[nullr0ute]

Can the docs be updated, looks like hdmi_ingore_hotplug is there but not hdmi_ignore_composite.
https://www.raspberrypi.org/documentation/configuration/config-txt/video.md
https://elinux.org/RPiconfig

[JamesH65]

@popcornmix @nullr0ute CanI just confirm its just hdmi_ignore_composite that need to be added to the docs, and that it simply doesn't start up the composite HW to save some power?

Note, that ELinux site is out of date, and nothing to do with us, so I will only be updating our own docs.

[popcornmix]

Personally I'm not sure if it is wise to add this to main documentation.

There exist a number of options that are intended for debugging purposes or for specific user's requests, who understand the limitations of the feature and are not recommended for average users to switch on without understanding the background of the option (e.g. by reading the github issue that introduced it).

This has a very niche use case and a number of significant limitations (the kernel errors on boot and the inability to subsequently enable the framebuffer if a display is powered on), and putting it into the primary documentation is probably going to increase confusion.

[nullr0ute]

It might be useful to have it documented in an advanced section, power saving in a headless environment is not exactly niche IMO, and trying to find things by digging through github in the vague hope that you find the thing you need isn't very useful. I feel it's useful to have these options documented somewhere even it's not in the core docs.

[jakemagee]

I agree on both sides... I can see not documenting the hdmi_ignore_composite=1 because of the kernel errors that will surely cause confusion. However, it might be useful to document the nice power savings that can be achieved via tvservice -o (but which would need to be executed on each boot).

[manio]

Hi!
In my use case I also like to have totally disabled HDMI (and composite) from early boot. It is a headless system and I don't even need to re-enable it after boot. Kernel message are also not a problem for me as long as it doesn't cause real problems (and in this case I understand that it doesn't harm).
Running a binary from /opt/vc after boot is another complication for me as I have specially crafted filesystem which is booting from NFS and then it is switched-over to running from ramdisk only (details: https://skyboo.net/2017/04/rpi-creating-a-ram-disk-running-linux-environment-from-nfs-booted-raspbian/).

As I am still confused after reading this thread I want to make sure and sum it all up:

1. To maximize the power saving effect (same as tvservice -o after boot) I have to add in config.txt:
   hdmi_ignore_hotplug=1
   hdmi_ignore_composite=1
   Is that right?
2. To have the above config lines working do I need to use this special firmware from google drive or it is now in official firmware (but undocumented)?

[popcornmix]

1. Correct
2. It is now in official firmware (from this version raspberrypi/firmware@a154f21)

[MichaIng]

@popcornmix
Many thanks for implementing this.

About the errors on boot, the following are expected and already showed up, when lowering gpu_mem beneath 32M (without disabling video completely):

[    0.219431] BCM2708FB: allocated DMA memory fdd00000
[    0.219503] BCM2708FB: allocated DMA channel 0 @ be813000
[    0.219697] bcm2708_fb soc:fb: Failed to allocate GPU framebuffer (-22)
[    0.219750] bcm2708_fb soc:fb: probe failed, err -22
[    0.219802] bcm2708_fb: probe of soc:fb failed with error -22
...
[    0.688467] vchiq: vchiq_init_state: slot_zero = bdd80000, is_master = 0
[    0.690078] [vc_sm_connected_init]: start
[    0.693547] vc_vchi_sm_init: failed to open VCHI service (-1)
[    0.693559] [vc_sm_connected_init]: failed to initialize shared memory service
[    0.693622] [vc_sm_connected_init]: end - returning -1 

• Since bcm2708_fb is kernel built-in, I guess there is no way to prevent this module from loading at all, right?
• But the second is part of the VideoCore and perhaps there is a way to prevent the shared memory service from attempting to load, if gpu_mem is beneath 32 and/or hdmi_ignore_composite=1 is set?

But then I also get the following, four times, one each CPU core, I guess:

[    0.797461] bcm2835-clk 3f101000.cprman: pllh: couldn't lock PLL
[    0.797502] ------------[ cut here ]------------
[    0.797546] WARNING: CPU: 2 PID: 31 at drivers/clk/clk.c:653 clk_core_enable+0xb4/0x224
[    0.797577] Modules linked in:
[    0.797611] CPU: 2 PID: 31 Comm: kworker/2:1 Not tainted 4.14.79-v7+ #1159
[    0.797637] Hardware name: BCM2835
[    0.797670] Workqueue: events deferred_probe_work_func
[    0.797726] [<8010ff30>] (unwind_backtrace) from [<8010c174>] (show_stack+0x20/0x24)
[    0.797773] [<8010c174>] (show_stack) from [<80788fa4>] (dump_stack+0xd4/0x118)
[    0.797819] [<80788fa4>] (dump_stack) from [<8011dd50>] (__warn+0xf8/0x110)
[    0.797857] [<8011dd50>] (__warn) from [<8011de38>] (warn_slowpath_null+0x30/0x38)
[    0.797901] [<8011de38>] (warn_slowpath_null) from [<804f0b44>] (clk_core_enable+0xb4/0x224)
[    0.797951] [<804f0b44>] (clk_core_enable) from [<804f324c>] (clk_register+0x52c/0x650)
[    0.797999] [<804f324c>] (clk_register) from [<804f33e0>] (devm_clk_hw_register+0x4c/0x90)
[    0.798046] [<804f33e0>] (devm_clk_hw_register) from [<804f80d0>] (bcm2835_register_pll+0xac/0xd4)
[    0.798093] [<804f80d0>] (bcm2835_register_pll) from [<804f8810>] (bcm2835_clk_probe+0x178/0x218)
[    0.798141] [<804f8810>] (bcm2835_clk_probe) from [<80546bb0>] (platform_drv_probe+0x5c/0xc0)
[    0.798188] [<80546bb0>] (platform_drv_probe) from [<80545190>] (driver_probe_device+0x244/0x300)
[    0.798234] [<80545190>] (driver_probe_device) from [<805453f8>] (__device_attach_driver+0xa4/0xbc)
[    0.798279] [<805453f8>] (__device_attach_driver) from [<80543280>] (bus_for_each_drv+0x74/0xa8)
[    0.798324] [<80543280>] (bus_for_each_drv) from [<80544e04>] (__device_attach+0xc0/0x120)
[    0.798368] [<80544e04>] (__device_attach) from [<8054542c>] (device_initial_probe+0x1c/0x20)
[    0.798412] [<8054542c>] (device_initial_probe) from [<805442f4>] (bus_probe_device+0x94/0x9c)
[    0.798457] [<805442f4>] (bus_probe_device) from [<8054479c>] (deferred_probe_work_func+0x5c/0x154)
[    0.798503] [<8054479c>] (deferred_probe_work_func) from [<801379b4>] (process_one_work+0x158/0x454)
[    0.798548] [<801379b4>] (process_one_work) from [<80137d14>] (worker_thread+0x64/0x5b8)
[    0.798592] [<80137d14>] (worker_thread) from [<8013dd98>] (kthread+0x13c/0x16c)
[    0.798639] [<8013dd98>] (kthread) from [<801080ac>] (ret_from_fork+0x14/0x28)
[    0.798673] ---[ end trace 049453980c0b9921 ]---

• I am not 100% sure if this is related to hdmi_ignore_composite=1, since I by times struggle with SDcard corruption, but at least it showed up the first time after trying the above setting. Since this takes a large part of systemctl/dmesg after boot, it is something I would like to avoid.
• Is it expected at least?