RPi4B does not support vcgencmd display_power 0

[frankgould]

Is this the right place for my bug report?
I was referred here by RPF forum moderator.

Describe the bug
I am migrating my app from the previous version of Raspbian that supported the vcgencmd display_power 0 command to turn off RPi4B attached HDMI monitor. It does not appear to work returns display_power=1 but does not turn off the monitor. This same SDcard installed in RPi3B+ does turn the monitor on/off using vcgencmd.

I tried tvservice -o but that appears to suspend all processes and my app never returns after a 60 second scheduled return. Only after I issue the tvservice -p command does my app return to restore the HDMI monitor using tvservice -p. I cannot find the TV address using cec-client. What is the recommended way for Buster to turn off and on the HDMI monitor?

To reproduce
With HDMI monitor attached to RPi4B, CLI 'vcgencmd display_power 0'

Expected behaviour
HDMI monitor turned off.

Actual behaviour
Nothing but echos 'display_power=1' in terminal

System
https://pastebin.com/haejHaZ3

• Which model of Raspberry Pi?
  When inserting RPi4B SDcard in RPi3B+, HDMI off/on works with vcgencmd

Logs
see pastebin above

Additional context
Add any other relevant context for the problem.

[popcornmix]

This is the right place. It is something we are aware of but it's not top of the list of issues.

Basically the HDMI hardware is different on Pi4 and 4kp60 scrambling adds another layer of difficulty to achieving this.

It will come but we can't say when.

[6by9]

raspberrypi/linux#3050

[Janghou]

IMHO this issue is not only a nuisance for users but also harming the planet.

KODI doesn't turn off idle monitors, burning unnecessary WATTS for hampering monitors turning off / going into powersave mode.

E.g. this great plugin stopped working on RPI4 LibreElec:
https://github.com/asavah/script.pidisplaypower

A workaround could be using tvservice -o, and tvservice -p, but tvservice seems to disable more than just HDMI output.

Also: https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=244425&p=1493575&hilit=hdmi+power+off+monitor+raspberry+4

[LorenKeagle]

This also affects those of us using the Pi 4 with various MagicMirror setups. The scripts that turn on/off the display based on sensor input (e.g. PIR sensor) depend on 'vcgencmd display_power '.

[popcornmix]

Latest firmware should support vcgencmd display_power on Pi4.

[Janghou]

Not working in LibreElec 9.2 Beta1 (11-09-2019) LibreELEC-RPi4.arm-9.1.501 (Kernel 4.19.66)

[MilhouseVH]

@Janghou unfortunately this fix didn't make the cut for LibreELEC 9.2 Beta 1.

[MilhouseVH]

@Janghou try this test build of LibreELEC 9.2 which does include the latest Sep 9 firmware and kernel 4.19.71:

http://milhouse.libreelec.tv/builds/stable/RPi4/LibreELEC-RPi4.arm-9.2.0-20190910001316.tar

[Janghou]

@MilhouseVH. Copied your tar to updates/ but it won't update from 9.1.501 after reboot. Just restarts.

Tried kernel 4.19.71 in raspbian (rpi-update), and vcgencmd display_power is working now on Buster. Great.

[MilhouseVH]

I can assure you it will upgrade 9.1.501 when copied into the correct location! 😄

It doesn't sound like it matters now, but the LibreELEC tar file needs to be copied into /storage/.update - if the /storage/.update folder doesn't exist then you may need to create it (it will also be hidden, due to the leading .). Perhaps you didn't copy it to the correct location (it's .update not updates)? Alternatively, copy the tar file into the Samba folder \ipaddress\Update, then reboot.

So that you know what is in this build, should you decide to try again:

• Kodi 18.4 (same as 9.1.501)
• 4.19.71 kernel
• 9 Sep firmware
• Ability to upgrade SPI bootloader with new bootloader firmware 2019-07-15: Settings > LibreELEC > Updates
• New bugs not in 9.1.501! In particular an HDMI signal drop out issue with the Kodi GUI at 50Hz

You could test this build, upgrade your SPI bootloader (this change is persistent) then return to 9.1.501 if you wish.

Any further support issues relating to this test build would best be handled on the LibreELEC forum.

[Janghou]

@MilhouseVH. Sorry, my mistake. Yes, vcgencmd display_power is working now. Thx.

[popcornmix]

@frankgould okay to close?

[frankgould]

@popcornmix Yes. It appears opt/vc/bin/vcgencmd display_power 0 now works on ALARM 4.19.71. Thanks for asking and how timely.

Is it possible to delete or hide the following forum post, link below? I wasted two sdcard builds trying to use rpi-update when all I needed to do was run pacman -Syu and the firmware was updated and works.

https://www.raspberrypi.org/forums/viewtopic.php?t=53773

[Janghou]

FYI On LibreElec it reports display_power=-1, after setting it to 0.

# vcgencmd display_power 0
display_power=0
vcgencmd display_power 
display_power=-1

[MilhouseVH]

@Janghou yes, confirmed:

The reported display_power is always -1. Odd... Presumably this is not the case with Raspbian?

[Janghou]

Also on Buster, but AFAIR not on <= rpi3

[popcornmix]

@Janghou @MilhouseVH latest rpi-update firmware should fix querying the display_power.

[giddyhup]

@popcornmix, it doesn't appear fixed for me.

$ vcgencmd display_power 0
display_power=0
$ vcgencmd display_power 1
display_power=0
$ vcgencmd version

Sep 24 2019 17:34:30
Copyright (c) 2012 Broadcom
version cd3add54955f8fa065b414d8fc07c525e7ddffc8 (clean) (release) (start)

[giddyhup]

I should mention that I use HDMI output 1 only, not HDMI 0.

[JamesH65]

@giddyhup That version is too old. Do a sudo apt update && sudo apt full-upgrade and see if that helps.

[giddyhup]

@JamesH65 Thanks for the comment but I think I'm as up-to-date as I can be:

$ sudo apt update && sudo apt full-upgrade
Hit:1 http://archive.raspberrypi.org/debian buster InRelease
Hit:2 http://raspbian.raspberrypi.org/raspbian buster InRelease
Hit:3 http://repo.mosquitto.org/debian buster InRelease
Hit:4 https://deb.nodesource.com/node_10.x buster InRelease
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

I actually did an rpi-update earlier to get the latest fixes.

[JamesH65]

Hmm, just tried this and its not working for me either, which is weird because I was looking at this the other day and ISTR it working fine. I might have a dodgy test firmware installed, so will need to check. however, off on a few days off now, so will need to be next week.

[giddyhup]

@JamesH65 could this issue please be reopened?

[helgeerbe]

I can confirm that vcgencmd display_power is not working on 3B+ to get the display status.
Toggeling the display on and off works!
I just upgraded to buster.

pi@picframe:~ $ vcgencmd display_power 0
display_power=0
pi@picframe:~ $ vcgencmd display_power 1
display_power=1
pi@picframe:~ $ vcgencmd display_power
display_power=-1
pi@picframe:~ $ vcgencmd version
Dec 11 2019 15:14:22
Copyright (c) 2012 Broadcom
version 44e6357b14365c3029d973dc32956fc5730dc334 (clean) (release) (start)
pi@picframe:~ $ uname -a
Linux picframe 4.19.88-v7+ #1284 SMP Wed Dec 11 13:46:41 GMT 2019 armv7l GNU/Linux

[JamesH65]

Looking at the code, specifying the display number in the vcgencmd might help.

So something like

vcgencmd display_power -1 display_id

where display id is 2 for HDMI1 and 7 for HDMI2. Will give 1 for on, -1 for off. Note, that should really be 0, I've found that bug and will fix it. There is a slight different issue when omitting the display id, where it was defaulting to the HDMI status even on HDMI2, which if nothing is connected to HDMI1 will return -1 (the previous bug!). Will fix that at same time.

[helgeerbe]

Tested it on my 3B+

Display is on!

pi@picframe:~ $ tvservice -l
1 attached device(s), display ID's are :
Display Number 2, type HDMI 0
pi@picframe:~ $ vcgencmd display_power -1 2
display_power=-1
pi@picframe:~ $ tvservice -s
state 0xa [HDMI DMT (68) RGB full 16:10], 1920x1200 @ 60.00Hz, progressive
So specifying display id doesn't help

[JamesH65]

Ah, it's possible that some of the change were not made on the pre-4 firmware branch as no need to support two HDMI's. Will check - may or may not be made there. Nothing will hit rpi-update until the new year anyway.

[helgeerbe]

@JamesH65 Thanks for the quick feedback. So I will wait. If you need someone for testing or other support let me know. Merry Christmas and a Happy New Year.

[JamesH65]

It's clear from the code what the problem is, just need to fix, test and get it code reviewed, and then released.

[JamesH65]

OK, this fix has been merged, just need to wait for the next release. Guys involved on holiday at the moment.

[helgeerbe]

Fix is not complete for 3B+

Without parametes the correct display status is returned. But with parameters I still get -1 as result.

pi@picframe:~ $ tvservice -l
1 attached device(s), display ID's are :
Display Number 2, type HDMI 0
pi@picframe:~ $ vcgencmd display_power -1 2
display_power=-1
pi@picframe:~ $ vcgencmd display_power
display_power=1
pi@picframe:~ $ uname -a
Linux picframe 4.19.93-v7+ #1286 SMP Mon Jan 6 13:18:44 GMT 2020 armv7l GNU/Linux
pi@picframe:~ $ vcgencmd version
Jan 6 2020 13:05:25
Copyright (c) 2012 Broadcom
version f3e39fed4763ce4efbffabb2d4787aaacddeda0f (clean) (release) (start)

[tripplehelix]

I'm still having the original problem on an upto date Rpi4

`pi@kiosk | /home/pi
0:09:48 ▶ vcgencmd version
Aug 9 2022 13:44:40
Copyright (c) 2012 Broadcom
version 273b410636cf8854ca35af91fd738a3d5f8b39b6 (clean) (release) (start)

pi@kiosk | /home/pi
0:08:24 ▶ /usr/bin/vcgencmd display_power 0

display_power=1

pi@kiosk | /home/pi
0:08:29 ▶ /usr/bin/vcgencmd display_power 1

display_power=1

pi@kiosk | /home/pi
0:08:31 ▶ /usr/bin/vcgencmd display_power 0

display_power=1

pi@kiosk | /home/pi
0:08:34 ▶ /usr/bin/vcgencmd display_power

display_power=1`

[popcornmix]

vcgencmd display_power is a control for the firmware display driver.
We not use the kernel driver by default (vc4-kms-v3d), so display_power should not be used.
See #1740

[bagong]

Is there another, vc4-kms-v3d compliant way to turn hdmi off and on?

[helgeerbe]

If you are running a graphical environment you can use
xset -display :0 dpms force on
xset -display :0 dpms force off

To use dpms (DPMS (Energy Star) features) you might have to enable it.

xset +dpms

If some one has an idea for a console environment, please share.

[bagong]

@helgeerbe : thank you, this switches the monitor off completely when screen blanking is enabled (in /etc/xorg.conf.d/10-blanking.conf). ´xrandr --output HDMI-1 --off´ seems to behave very similarly, and not depend on the xorg configuration. But in both cases the screen comes on for me automatically after a few seconds (I've carefully avoided touching the mouse and anything else ;-)). I hope it's not related to the fact that I am using the kde desktop (Pi OS/Debian based version). Just checked with the pi desktop, it's the same there.

[helgeerbe]

@bagong I use this settings on a pi driven picture frame. This works for me to turn screen off during night time.
On my pi blanking is disabled of course.

[popcornmix]

But in both cases the screen comes on for me automatically after a few seconds (I've carefully avoided touching the mouse and anything else ;-)).

I've seen a few reports of this but couldn't reproduce with a clean install of RPiOS. It probably starts with installing a package or changing some configuration.
If you have spare sdcard, I'd be interested if you can reproduce when the image is clean, and if the behaviour starts when you do your usual package installs/customisation.

[bagong]

@popcornmix you are right, the problem was on my side: I use a hdmi splitter that causes the problem. When I connect the Pi directly to the screen it doesn't come on again. Sorry for the noise!

[popcornmix]

Could you link to the splitter you are using? I'm trying to understand which mechanism could cause this?
Possibly hotplug detect being intermittent, but I'd expect that to cause more obvious failures (like often booting with no display).

[bagong]

@popcornmix , sorry for the late reply. It's a cheap 5 port-splitter, branded as primgwire HDMI 3D 4K ULTRA HD. This exact model I can't find any more on Amazon, but the link below is the 3-port version of exactly the same model:

https://www.amazon.de/-/en/CSL-HDMI-2-0-Splitter-60Hz-black/dp/B07VGRD7R1/ref=dp_fod_1?pd_rd_w=Enu4J&content-id=amzn1.sym.8e96aa5e-41ac-45a9-a40c-2c40a52ba2ef&pf_rd_p=8e96aa5e-41ac-45a9-a40c-2c40a52ba2ef&pf_rd_r=HVH5QV0DXF9GR5HZ70JC&pd_rd_wg=TclvC&pd_rd_r=87f5c79a-cd37-4835-b9a1-99448c8350e1&pd_rd_i=B07VGRD7R1&th=1

The splitter tries to switch automatically to the currently active device, so it must have some way to detect which port is active. I guess the signal it sends back triggers the RPI hdmi-port to switch on again. Maybe like a wake-up event.

And yes, the boot display when using this splitter is not identical to when the screen is plugged in directly. When on the splitter, I don't see the raspberries and I think sometimes it doesn't even display the boot messages before X starts. So I just have a black screen until the desktop comes up. It's not the same at each boot. And I have to fiddle with config.txt hdmi modes to make the boot reliable.

[popcornmix]

The splitter tries to switch automatically to the currently active device, so it must have some way to detect which port is active. I guess the signal it sends back triggers the RPI hdmi-port to switch on again. Maybe like a wake-up event.

Yes, reading the specs, I suspected it was the automatic switching to currently active device that triggered the unwanted wake-up. There are two ways information can be transferred from display to source, the hotplug detect signal and CEC.

I'd have thought it's more likely hotplug. What would be useful is you try again with splitter in place, but add to cmdline.txt (on end of existing line) video=:D which should make the Pi assume hotplug signal is always asserted.

If that doesn't help, then try instead vc4.force_hotplug=1 which is a slightly more forceful version.

[bagong]

@popcornmix thank you very much for taking my hand. Unfortunately this doesn't help in my case, no change... But thanks again. If there is more I could try, I'd be happy to do so ;-)

[popcornmix]

Just to confirm the settings applied correctly, can you show output of:
cat /proc/cmdline

[pi-dayun]

@popcornmix , it's me, bagong, the Pi usese a different identity ;-)

Wow, you caught me at a mistake, and I am very grateful! ;-) video=:D doesn't help in any variation so far, but vc4.force_hotplug does!!! My mistake was that for the similarity of that entry with the config.txt entries I put it there earlier, instead of cmdline.txt (your text was clear, I misread). When I did put it in the right place, the monitor stayed off after I shut it down with the xrandr command. Success. However I couldn't wake it up any more, neither with my usual bluetooth input devices, nor with a mouse I connected via USB (I had to reboot via ssh). But then I tried the same procedure with the xset sequence, and both the screen stayed off and woke up from bluetooth. Yey!!!

This is for the video=:D variant (macaddr removed):

pi@dayun:~ $ cat /proc/cmdline 
coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 video=HDMI-A-1:3840x2160M@60 smsc95xx.macaddr=xx:xx:xx:xx:xx:xx vc_mem.mem_base=0x3eb00000 vc_mem.mem_size=0x3ff00000  console=tty1 root=PARTUUID=c4b518f8-02 rootfstype=ext4 fsck.repair=yes rootwait video=:D
pi@dayun:~ $ xrandr --output HDMI-1 --off

Now for vc4.force_hotplug=1:

pi@dayun:~ $ xset +dpms
pi@dayun:~ $ xset -display :0 dpms force off
pi@dayun:~ $ cat /proc/cmdline
coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 video=HDMI-A-1:3840x2160M@60 smsc95xx.macaddr=xx:xx:xx:xx:xx:xx vc_mem.mem_base=0x3eb00000 vc_mem.mem_size=0x3ff00000  console=tty1 root=PARTUUID=c4b518f8-02 rootfstype=ext4 fsck.repair=yes rootwait vc4.force_hotplug=1

Thank you very, very much!!

Best
bagong

[popcornmix]

Thanks for double checking.

Interesting that the hotplug deassert/assert gets noticed by X and treated like a wake up (which is obviously not desired when you've just disabled screen output).

There's been a few other reports that screensaver blanking immediately wakes up. Need to check if they have a similar cause.

[birkoof]

Changing the hardware acceleration driver from vc4-kms-v3d to vc4-fkms-v3d fixed the issue with the vcgencmd display_power command on RPi4B.

Don't quite understand why (and in my case didn't need to), but still wanted to share. Steps:

1. sudo nano /boot/config.txt or any other editor
2. Change dtoverlay=vc4-kms-v3d to dtoverlay=vc4-fkms-v3d
3. reboot

[jtolksdo]

Changing the hardware acceleration driver from vc4-kms-v3d to vc4-fkms-v3d fixed the issue with the vcgencmd display_power command on RPi4B.

Don't quite understand why (and in my case didn't need to), but still wanted to share. Steps:

1. sudo nano /boot/config.txt or any other editor
2. Change dtoverlay=vc4-kms-v3d to dtoverlay=vc4-fkms-v3d
3. reboot

That worked! Thanks!