Closed notGMman closed 4 years ago
hdmi_blanking=1 isn't implemented yet on Pi4, due to differences in the HDMI hardware. Hopefully, this can be fixed via a firmware update.
Thanks timg236 for the info. Are you aware of whether it's on anyone's radar for fixing?
Yes it is - Tim is one of us.
Yes, it's on the radar along with hdmi_boost which also isn't implemented. It's a little way down the list behind general display stability & power management bugs (and probably PXE boot for improving test automation). There's a new HDMI block and HDMI PHY so this is more of a re-implement rather than a trivial port. Possible but needs a little though to avoid problems where the display doesn't come back or causes a lockup.
Thanks for the updates Tim & Phil. I think I can cope with turning the screen off for the time being :-) The irony for me is that I look after Pi's running signage at work and where they use TVs as displays (which they do because budgetholders buy whatever TV is on offer) I've had real trouble sometimes stopping them from switching off. And now at home I have the opposite problem! Still love Pi's though.
Hi, I have what appears to be the same issue. Not on Pi4, but on Buster. Some time after booting, the screen blanks. I can then still ssh into the box and even make cvlc play back videos. But the gui is gone. All is pitch black. In my case, the issue seems to be related to drm_crtc_vblank_get() not returning 0 and the vc4 driver crashing, here: https://github.com/raspberrypi/linux/blob/rpi-4.19.y/drivers/gpu/drm/vc4/vc4_firmware_kms.c#L899 notGMman, did you check dmesg? Please let me know if you see the same "Xorg Tainted" stack trace. If not, I should file a separate issue. Here some other people having the same issue: https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=244796
A person just posted a fix for the screen blanking issue. Maybe not a complete solution, but an effective fix: https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=244796#p1504694
notGMman, I hope you don't mind if I litter your thread a little more, but today I apt-upgraded the kernel from 4.19.57-v7+ to 4.19.58-v7+ and the blanking fix, mentioned above, has stopped working. I had a great 48h with no screen blanking issues, but the new kernel now gives me this choice: a) use an unmodified /etc/lightdm/lightdm.conf and have the screen blank on me 10-20 minutes after boot, or b) modify /etc/lightdm/lightdm.conf with what has worked with 4.19.57-v7+ ("xserver-command=X -s 0 dpms") and have the screen blank on me when x11 is starting up. I'm picking a) for the time being... ssh and everything else still working fine.
The warnings are gone with 4.19.58-v7+. But the x11-blanking is back.
Q: How is it possible that "xserver-command=X -s 0 dpms" did totally fix the issue in 4.19.57-v7+, but under 4.19.58-v7+ doing the same leads to the immediate blanking of x11?
The warnings are still here also. My dmesg log: https://pastebin.com/raw/J2Zsbbr2
The first two warnings don't have a blanking effect. But the third warning (at time stamp 765.364852) correlates exactly with the full blanking of the x11 session.
I say "blanking of the x11 session" and not "HDMI screen blanking" like OP did, because I am able to use cvlc and/or omxplayer (via ssh) to play back videos on screen AFTER the blanking has occured. Apparently, there is nothing wrong with the HDMI signal. It's just that the screen is all black and I assume it has something to do with x11.
Also note that this is not at all Pi4 specific.
The warnings will be present if you have dtoverlay=vc4-fkms-v3d
in config.txt, and are noted under #3020 (as I have already linked to).
They are harmless and are due to producing DRM flip events at incorrect moments around mode changes. They have no actual link to screen blanking itself.
As timg236 has already said, HDMI display blanking is still on the radar as a feature to be implemented. Currently the screensaver will remove all layers from the screen, but the pipeline will continue to produce black output.
If the kernel warnings are unrelated, then I apologize. The warnings state "Xorg Tainted", which fits just too well with the situation.
Currently the screensaver will remove all layers from the screen, but the pipeline will continue to produce black output.
Can I prevent the screensaver from doing that, maybe disable it before hand? Or do something after the fact, maybe by restarting a service? I am currently rebooting the device about every 10 minutes.
@mehrvarz You've hijacked someone else's report of screen blanking not putting the monitor into standby mode with something different. Please don't do that.
All the X screensaver settings can be tweaked via xset s <command>
(read status with xset q
). You probably want xset s off
if you're not wanting the screensaver to ever kick in, and xset -dpms
to stop the monitor sleeping (or at least attempting to sleep).
(xset
by itself gives you the help text)
@mehrvarz You've hijacked someone else's report of screen blanking not putting the monitor into standby mode with something different. Please don't do that.
All the X screensaver settings can be tweaked via
xset s <command>
(read status withxset q
). You probably wantxset s off
if you're not wanting the screensaver to ever kick in, andxset -dpms
to stop the monitor sleeping (or at least attempting to sleep). (xset
by itself gives you the help text)
I am not sure my issue is different. Up to this minute I was convinced that it is the same issue. If those are different, then they certainly look the same.
I am using these xset commands in my /etc/xdg/lxsession/LXDE-pi/autostart since forever like so: @xset s noblank @xset s off @xset -dpms
Original report:
Expected behaviour Screen blanks after 5 miniutes. Backlight switches off when screen receives no HDMI signal.
Actual behaviour On Pi 3b+, after blanking the screen briefly displays blue with backlight, then switches off (which is fine). > On Pi 4 it blanks completely, then the backlight switches on (which is no so good).
ie the issue is that it isn't turning off the backlight / making the monitor sleep.
Your issue appears to be that the screen blanks in the first place, which is a very different issue.
I've checked xset s off
xset -dpms
, and my monitor hasn't blanked in the last hour. I see nothing further to do on that.
Hi 6by9 I may be about to litter my own report. I do agree that that @mehrvarz issue is not the one I reported. However, I do also see a very similar issue to his. With the dpms settings above (because blanking the screen is better than nothing!), my screen goes black for several seconds during use. it happens intermittently whilst I'm typing and coincides with a kernel "xorg.tainted" error that does appear to be the same as reported above. Is this a known issue? I've not found anyone reporting it on the raspberry pi forum, aside from me! Regards
AIUI DPMS blanking is meant to be triggered by disabling the CRTC from DRM/KMS. That action is missing.
However the FKMS driver does support changing HDMI modes, and as part of that we issue avmute and various other commands over the HDMI link as required by the HDMI spec (I believe). Waking up from sleep normally includes a mode reset for various reasons, so it is most likely the avmute then that is being interpreted by your monitor as a sleep/backlight off request. Why it is happening whilst you are typing is a totally different question, and one I can't answer at present.
Any info when this would be fixed? I have the same issue even though I'm not even using a HDMI interface. I have an official RPi 7" screen connected to my Pi 4B via a display cable and also can't turn off the screen with dpms force off
(it just blanks).
I can turn it on/off with echo 0 > /sys/class/backlight/rpi_backlight/bl_power
but I want it to turn off automatically after a certain timeout and come back on on user press/interaction.
@crocy You're bringing in a totally separate issue. This issue is for DPMS blanking of HDMI displays only.
The 7" display is a DSI display and I don't believe it has ever supported blanking via the screensaver/DPMS calls. DSI and DPI displays control their backlights in a totally different manner to HDMI, therefore this is a different issue, and different solution required. It can be added to the list of tasks, but isn't a high priority.
Hey, thanks for the info. The issue seemed the same to me (that's why I commented on this thread, not a new one), because I had no issues with blanking/turning off on an older Pi 3B (same interface, same display) using the same command. I can open a new issue if you think that would be more appropriate?
I had no issues with blanking/turning off on an older Pi 3B (same interface, same display) using the same command.
Trying this on a Pi3 with DSI display and I can't tell if the backlight goes off or not, and I haven't got a current meter to hand to measure that. /sys/class/backlight/rpi_backlight/bl_power is still reporting it as on, but that may well be a quirk of the driver thinking it is the absolute master when it isn't.
Please open a new issue to allow us to track this better.
Will do. Can you just advise me if I should post it under "linux" or "firmware" repo?
Hm, or the #1210 firmare issue could just be reopened?
I am experiencing the same issue with a Spectre E16 HDMI monitor on RPi4B/4GB. Using dpms, it does not turn the monitor off, it just blanks the screen on timeout. When I hit a key or mouse moved, the monitor turns off then back on with the OSD saying HDMI connected.
What is the timeframe do you think the firmware can be corrected to make pi4 can send the hdmi display to go in a low power standby mode? Or is it a hadware limitation of the pi 4 hardware which will never be able to activate a proper hdmi display standby?
I don't believe this a HW limitation, so it's hopefully just a matter of finding some time to implement it
Did you make any progress to solve this issue?
I'm really ready for this update so I don't have to power off my monitor at night and back on in the morning!
Going to take a look at this. You can turn the power off using vcgencmd display_power 0
and on using vcgencmd display_power 1
in the meantime. This means the HW does support the power off, I just need to plumb it into the correct places.
@JamesH65 Yes, I can program it that way but I don't know when the mouse/keyboard triggers to turn the display back on. I tried to use dpms to trigger it back on but it didn't work. Any suggestions in the interim? Would be nice to have the OS handle that instead of a separate app.
At the moment DPMS isn't connected internally to DRM. I've got some changes here that do make it do what is needed buts not suitable for release as there are unintended consequences with regard to memory usage (extra framebuffer is created). To do this properly requires a bit more thought and time, but hopefully not much more than a couple of days.
tvservice -o WILL put the HDMI device into standby (powers off) tvservice -p brings it back to its set preferences. those commands DO work, and it seems to be an older issue with possibly the pi2 i also have a rpi3b+ and a rpi4b on a kvm, the 3+ standby's properly as expected. the 4 does not.
@JamesH65 You are awesome! Thanks for your effort to fix this annoying issue. In my case I would use rpi4 with large lcd panel in kiosk mode. The screen should be in standby mode in the sake off saving lot of energy whenever nobody is watching at it. A script would to wake it up from screen standby (triggered by motion detection and or sound detection). Poweing off is not good option because after we poweroff the input, the screen is starting search for signal around (with a not elegant no signal message) for minimum 5 minutes and then just would poweroff the screen.
@nor500 Note that the stuff I am looking at powers down the HDMI datalanes, so HDMI output is stopped. What happens then depends on the screen. It doesn't specifically ask to power down the monitor (if that is possible). My monitor scans for a few seconds then turns itself off.
I've pushed some changes to this repo, but these will require a firmware change to work correctly, so once that is accepted this should be good to go.
@JamesH65 How can I install the update? Should I just sudo rpi-update?
None of the changes have been merged yet, so not yet available.
You can shut off power to the HDMI port using vcgencmd display_power 0
. (the backlight will turn off) This was recently implemented for the Pi 4, so it may be necessary to do an apt update/upgrade first.
Shutting of the hdmi port is not a good option. It makes the monitor searching for signal contionously until after a while is giving it up. Around 5 minutes. During this period the monitor is showing searching for signal error message. On the other hand display standy by will send the display into standby mode, where the display is actually kind off turned off but still the hdmi port active so no annoying searching for signal error message showing. Hoever, the pi 4 in this moment cannot send the display into standby mode.
Just a comment to confirm issue #3050 as I was also trying to get it to work with an Rpi 4.
As of Tue 22 Oct 12:28:20 UTC 2019 DPMS does not power down HDMI , e.g. from xscreensaver or xset.
Tested after sudo apt update && sudo apt upgrade
and hdmi_blanking=1
in /boot/config.txt and reboot. kernel 4.19.75-v7l+ firmware: version cd3add54955f8fa065b414d8fc07c525e7ddffc8
xset dpms force off #forces the monitor to blank but the back light is still on
vcgencmd display_power 0 #does power down HDMI
Hello. When will you merge it into the official firmware?
@nor500 It's available now if you use rpi-update
, it works flawlessly on my setup, definitely a huge thanks to @JamesH65 for getting this fixed up.
Ditto: "huge thanks to @JamesH65 " for making this happen!!! Works great, even on Arch Linux ARM. My desktop is now complete!
Cool, its made it to rpi-update. Can people using it keep an eye on it, and report back any issues please. Not expecting any, but this is one of those changes that might have some unintended consequences.
Hello everyone. I am testing this latest update. However, It is not working as it supposed to be. Standby mode is turning off the hdmi port instead of putting the screen to standby mode. My settings is: DPMS (Energy Star): Standby: 60 Suspend: 65535 Off: 65535 DPMS is Enabled
Thanks for the work on this.
Has the change made it to the regular Raspbian repos? I thought that it was
no longer necessary to run rpi-update
as the changes it performs are now
incorporated in the normal Debian apt update
/apt upgrade
process. The
behavior of my Pi 4B has not changed. The screen blanks but the monitor
does not go into standby.
Thanks!
On Sun, Nov 3, 2019 at 5:08 AM James Hughes notifications@github.com wrote:
Cool, its made it to rpi-update. Can people using it keep an eye on it, and report back any issues please. Not expecting any, but this is one of those changes that might have some unintended consequences.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/raspberrypi/linux/issues/3050?email_source=notifications&email_token=AAZM47SUDPCBWXWM5ADH2LDQR2WK7A5CNFSM4H6AFTZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC5P52A#issuecomment-549125864, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZM47SYBKQ6UFWMKR4EER3QR2WK7ANCNFSM4H6AFTZQ .
-- '03 BMW F650CS - hers '98 Dakar K12RS - "BABY K" grew up. '93 R100R w/ Velorex 700 (MBD starts...) '95 Miata - "OUR LC" polish visor: apply squashed bugs, rinse, repeat Beautiful Sunny Winfield, Illinois
I don't believe it has got to the repo's yet - we like to leave time for testing to shake out bugs for all the changes that have been made, not just this one. Not sure when the next release is, just spoken to the people involved, need to check there isn't anything that might cause problems but could be out in next day or two.
Confirmed this works for me. Just used rpi-update and this fixed the backlight issue. I have an energy star monitor with dpms on
Hello everyone. I am testing this latest update. However, It is not working as it supposed to be. Standby mode is turning off the hdmi port instead of putting the screen to standby mode. My settings is: DPMS (Energy Star): Standby: 60 Suspend: 65535 Off: 65535 DPMS is Enabled
Yes, this is working as written. I simply turn off the HDMI, which in all the devices I have tried, also turns off the monitor. Sending a CEC command or whatever is required to turn off is unlikely to be done, just don't have the time given this method works for most people.
DPMS is working fine on Raspbian (Pi4B). Thanks for the fixes.
I am not sure if there's much overlap between Raspberry Pi Foundation and Canonical with kernel builds, or indeed resolution of other issues, please clarify if possible. My apologies if below is not relevant to this issue, but just in case it's of interest:
DPMS is still a problem for Xubuntu on Ubuntu 19.10 ARM64.
xset dpms force off
blanks the screen but leave the back light on
tvservice -o
does switch off hdmi
I'm not sure if this is a kernel or xubuntu issue as tvservice works but I've posted the issue on the Ubuntu Desktop forum with optimism ;-)
Describe the bug Issue noted on a Raspberry Pi 4, running Buster using both the stable kernel and the current bleeding edge. The setting in /boot/config.txt "hdmi_blanking=1 is set. The X dpms settings are active. The screen blanks after the defined timeout but the backlight stays on. This issue does not occur on a respberry pi 3b+ with the same SD card (this was tested prior to upgrading the kerne - so only on the current stable kernell) This occurs on an ASUS HDMI monitor. Have no other display devices to test with.
To reproduce Configure /boot/config.txt with hdmi_blanking=1. In /etc/xdg/lxsession/LXDE-pi/autostart add: point-rpi @xset s 0 0 @xset s noblank @xset s noexpose @xset dpms 0 0 300
Expected behaviour Screen blanks after 5 miniutes. Backlight switches off when screen receives no HDMI signal.
Actual behaviour On Pi 3b+, after blanking the screen briefly displays blue with backlight, then switches off (which is fine). On Pi 4 it blanks completely, then the backlight switches on (which is no so good).
System Pi 4. Debian 10.0 Kernel4.19.50-v7l+ #895 and Debian 10.0 Kernel 4.19.57-v7l+ #1244
Logs Nothing logged in Xorg.0.log.
Additional context Happy to try any suggested troubleshooting.