-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
RPi4B does not support vcgencmd display_power 0 #1224
Comments
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. |
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: A workaround could be using tvservice -o, and tvservice -p, but tvservice seems to disable more than just HDMI output. |
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 '. |
kernel: configs: Set VIDEO_V4L2_SUBDEV_API=y on arm64/bcm2711 kernel: configs: Add GPIO_PCA953X, LEDS_PCA9532/PCA955X See: raspberrypi/linux#3182 kernel: Add Greyworld AWB option to v4l2 and bcm2835-camera driver See: raspberrypi/linux#3212 firmware: platform: Set up emmc clock earlier firmware: hdmi: Implement platform_display_power on 2711 See: #1224 firmware: arm_loader: Pass overscan settings to the kernel firmware: arm_loader: Add option disable_fw_kms_setup to stop FKMS setup by FW firmware: hdmi: Use pixel clock multiplier to determine the core clock
kernel: configs: Set VIDEO_V4L2_SUBDEV_API=y on arm64/bcm2711 kernel: configs: Add GPIO_PCA953X, LEDS_PCA9532/PCA955X See: raspberrypi/linux#3182 kernel: Add Greyworld AWB option to v4l2 and bcm2835-camera driver See: raspberrypi/linux#3212 firmware: platform: Set up emmc clock earlier firmware: hdmi: Implement platform_display_power on 2711 See: raspberrypi/firmware#1224 firmware: arm_loader: Pass overscan settings to the kernel firmware: arm_loader: Add option disable_fw_kms_setup to stop FKMS setup by FW firmware: hdmi: Use pixel clock multiplier to determine the core clock
Latest firmware should support vcgencmd display_power on Pi4. |
Not working in LibreElec 9.2 Beta1 (11-09-2019) LibreELEC-RPi4.arm-9.1.501 (Kernel 4.19.66) |
@Janghou unfortunately this fix didn't make the cut for LibreELEC 9.2 Beta 1. |
@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 |
@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. |
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 So that you know what is in this build, should you decide to try again:
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. |
@MilhouseVH. Sorry, my mistake. Yes, vcgencmd display_power is working now. Thx. |
@frankgould okay to close? |
@popcornmix Yes. It appears 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 |
FYI On LibreElec it reports display_power=-1, after setting it to 0.
|
@Janghou yes, confirmed: The reported |
Also on Buster, but AFAIR not on <= rpi3 |
See: raspberrypi/linux#3224 kernel: drm/vc4: Fix for margins in composite/SDTV mode See: raspberrypi/linux#3223 firmware: Fixups for composite output mode See: #1223 firmware: platform: Allow display_power to be queried from gencmd See: #1224 firmware: arm_loader: Fix no-DT and upstream handling See: #1250
See: raspberrypi/linux#3224 kernel: drm/vc4: Fix for margins in composite/SDTV mode See: raspberrypi/linux#3223 firmware: Fixups for composite output mode See: raspberrypi/firmware#1223 firmware: platform: Allow display_power to be queried from gencmd See: raspberrypi/firmware#1224 firmware: arm_loader: Fix no-DT and upstream handling See: raspberrypi/firmware#1250
@Janghou @MilhouseVH latest rpi-update firmware should fix querying the display_power. |
@popcornmix, it doesn't appear fixed for me.
|
I should mention that I use HDMI output 1 only, not HDMI 0. |
@giddyhup That version is too old. Do a |
@JamesH65 Thanks for the comment but I think I'm as up-to-date as I can be:
I actually did an rpi-update earlier to get the latest fixes. |
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. |
@JamesH65 could this issue please be reopened? |
It's very odd you see it working on some kernels and not others - it's all been committed to the 4.19 tree so should just 'work' past a certain point, not sometimes work and sometimes not. As for the error on HDMI1, will take a quick look. |
I can confirm that vcgencmd display_power is not working on 3B+ to get the display status.
|
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. |
Tested it on my 3B+ Display is on!
|
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. |
@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. |
It's clear from the code what the problem is, just need to fix, test and get it code reviewed, and then released. |
OK, this fix has been merged, just need to wait for the next release. Guys involved on holiday at the moment. |
kernel: configs: Add RTS_DRV_PCF85363 See: #1309 kernel: overlays: i2c-rtc: Add pcf85363 support See: #1309 kernel: overlays: dht11: Allow multiple instantiation kernel: configs: Add CONFIG_NET_SCH_CAKE=m See: raspberrypi/linux#3180 firmware: Fixup for vcgencmd display_power See: #1224 firmware: Add hdmi_wifi_pixel_freq_adj config option userland: vcdbg/debugsym: Add option to specify the file size
kernel: configs: Add RTS_DRV_PCF85363 See: raspberrypi/firmware#1309 kernel: overlays: i2c-rtc: Add pcf85363 support See: raspberrypi/firmware#1309 kernel: overlays: dht11: Allow multiple instantiation kernel: configs: Add CONFIG_NET_SCH_CAKE=m See: raspberrypi/linux#3180 firmware: Fixup for vcgencmd display_power See: raspberrypi/firmware#1224 firmware: Add hdmi_wifi_pixel_freq_adj config option userland: vcdbg/debugsym: Add option to specify the file size
Fix is not complete for 3B+ Without parametes the correct display status is returned. But with parameters I still get -1 as result.
|
I'm still having the original problem on an upto date Rpi4 `pi@kiosk | /home/pi pi@kiosk | /home/pi display_power=1 pi@kiosk | /home/pi display_power=1 pi@kiosk | /home/pi display_power=1 pi@kiosk | /home/pi display_power=1` |
vcgencmd display_power is a control for the firmware display driver. |
Is there another, vc4-kms-v3d compliant way to turn hdmi off and on? |
If you are running a graphical environment you can use 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. |
@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. |
@bagong I use this settings on a pi driven picture frame. This works for me to turn screen off during night time. |
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. |
@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! |
Could you link to the splitter you are using? I'm trying to understand which mechanism could cause this? |
@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: 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. |
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) If that doesn't help, then try instead |
@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 ;-) |
Just to confirm the settings applied correctly, can you show output of: |
@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):
Now for vc4.force_hotplug=1:
Thank you very, very much!! Best |
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. |
Changing the hardware acceleration driver from Don't quite understand why (and in my case didn't need to), but still wanted to share. Steps:
|
That worked! Thanks! |
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 returnsdisplay_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 thetvservice -p
command does my app return to restore the HDMI monitor usingtvservice -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
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.
The text was updated successfully, but these errors were encountered: