raspberrypi / linux

Kernel source tree for Raspberry Pi-provided kernel builds. Issues unrelated to the linux kernel should be posted on the community forum at https://forums.raspberrypi.com/
Other
11.17k stars 5.01k forks source link

HDMI screen blanking but not switching off backlight - Pi 4 #3050

Closed notGMman closed 4 years ago

notGMman commented 5 years ago

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.

timg236 commented 5 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.

notGMman commented 5 years ago

Thanks timg236 for the info. Are you aware of whether it's on anyone's radar for fixing?

pelwell commented 5 years ago

Yes it is - Tim is one of us.

timg236 commented 5 years ago

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.

notGMman commented 5 years ago

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.

mehrvarz commented 5 years ago

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

mehrvarz commented 5 years ago

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

mehrvarz commented 5 years ago

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.

6by9 commented 5 years ago

3020 The vblank warnings (not crash) are harmless.

mehrvarz commented 5 years ago

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?

mehrvarz commented 5 years ago

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.

6by9 commented 5 years ago

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.

mehrvarz commented 5 years ago

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.

6by9 commented 5 years ago

@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 commented 5 years ago

@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)

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

6by9 commented 5 years ago

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.

notGMman commented 5 years ago

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

6by9 commented 5 years ago

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.

crocy commented 5 years ago

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.

6by9 commented 5 years ago

@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.

crocy commented 5 years ago

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?

6by9 commented 5 years ago

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.

crocy commented 5 years ago

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?

frankgould commented 5 years ago

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.

nor500 commented 5 years ago

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?

JamesH65 commented 5 years ago

I don't believe this a HW limitation, so it's hopefully just a matter of finding some time to implement it

nor500 commented 5 years ago

Did you make any progress to solve this issue?

frankgould commented 5 years ago

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!

JamesH65 commented 5 years ago

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.

frankgould commented 5 years ago

@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.

JamesH65 commented 5 years ago

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.

Migamix commented 5 years ago

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.

nor500 commented 5 years ago

@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.

JamesH65 commented 5 years ago

@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.

JamesH65 commented 5 years ago

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.

nor500 commented 5 years ago

@JamesH65 How can I install the update? Should I just sudo rpi-update?

JamesH65 commented 5 years ago

None of the changes have been merged yet, so not yet available.

Botspot commented 5 years ago

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.

nor500 commented 5 years ago

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.

gdevacc12 commented 5 years ago

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

nor500 commented 5 years ago

Hello. When will you merge it into the official firmware?

Kealper commented 5 years ago

@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.

frankgould commented 5 years ago

Ditto: "huge thanks to @JamesH65 " for making this happen!!! Works great, even on Arch Linux ARM. My desktop is now complete!

JamesH65 commented 5 years ago

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.

nor500 commented 5 years ago

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

HankB commented 5 years ago

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

JamesH65 commented 5 years ago

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.

asdf1nit commented 5 years ago

Confirmed this works for me. Just used rpi-update and this fixed the backlight issue. I have an energy star monitor with dpms on

JamesH65 commented 5 years ago

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.

gdevacc12 commented 5 years ago

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 ;-)