Bullseye: problems with screen blanking

[audetto]

Hi,

just installed Bllseye on a Pi400 and noticed that the screen does not go in sleep mode as well as it did with Buster.

In Buster I have been using the Full KMS driver too (this because it makes OpenGLES2 performance skyrocket): dtoverlay=vc4-kms-v3d, and never had any issue.

I noticed as well that the kernel version is the same 5.10.63.

Behaviour on Bullseye is

1. after the required time 600 sec
2. screen goes black
3. stays black for a few seconds
4. back to desktop (removed USB mouse to be sure, no event)
5. depends, either loops back to 1, or sometimes, it stays black the 2nd time

xset q says

pi@raspberrypi:~ $ xset q
Keyboard Control:
  auto repeat:  on    key click percent:  0    LED mask:  00000000
  XKB indicators:
    00: Caps Lock:   off    01: Num Lock:    off    02: Scroll Lock: off
    03: Compose:     off    04: Kana:        off    05: Sleep:       off
    06: Suspend:     off    07: Mute:        off    08: Misc:        off
    09: Mail:        off    10: Charging:    off    11: Shift Lock:  off
    12: Group 2:     off    13: Mouse Keys:  off
  auto repeat delay:  500    repeat rate:  33
  auto repeating keys:  00ffffffdffffbbf
                        fadfffefffedffff
                        9fffffffffffffff
                        fff7ffffffffffff
  bell percent:  50    bell pitch:  400    bell duration:  100
Pointer Control:
  acceleration:  20/10    threshold:  10
Screen Saver:
  prefer blanking:  yes    allow exposures:  yes
  timeout:  600    cycle:  600
Colors:
  default colormap:  0x20    BlackPixel:  0x0    WhitePixel:  0xffffff
Font Path:
  built-ins
DPMS (Energy Star):
  Standby: 600    Suspend: 600    Off: 600
  DPMS is Enabled
  Monitor is On
pi@raspberrypi:~ $ 

[XECDesign]

Not sure who to direct this one at. @popcornmix, @6by9 any idea?

[6by9]

Bullseye has changed the composition manager to Mutter, so most likely it's something in there.

Memory says there's an option to disable Mutter and drop back to the old composition manager which would allow confirmation of that, but I can't remember the details. @spl237 please remind me.

[spl237]

Just enable VNC in the Raspberry Pi Configuration options - that automatically disables Mutter.

[audetto]

Bingo. Disabling mutter (via VNC) solved both issues I had (including the tear I reported elsewhere).

Now the screen goes to sleep at the first attempt. I tried with different standby times.

[spl237]

FWIW, I've just tested this here on a clean copy of the initial bullseye release image, with mutter still enabled, and blanking works correctly for me - the screen goes blank after ten minutes and stays off until I move the mouse.

Looking online, it seems there are some applications which temporarily disable screen blanking under mutter (such as when playing YouTube videos in Chromium) and the mechanism for re-enabling it once they close can fail, which may be what you are seeing.

[spl237]

Just double-checked with a fully updated image - blanking still working fine on mutter for me.

[audetto]

I don't think it is that case of a video player. When I watch a video, the blanking just does not happen.

I have tried again with nothing on the desktop and a short time (10s) so I see more iterations.

I see more of a pattern now. After it blanks correctly, it comes back after a few seconds and then it does not blank any longer.

Only after I move the mouse, does the timer starts again, blanks after the desired time, comes back and stays there.

I cannot observe the looping, which is even worse, if left untouched the screen stays on.

It looks to me that mutter thinks it is blanked, so it does not blank it again, but mutter and the monitor disagree.

It is very likely that only a small fraction of screens are affected, otherwise they would have not released the code, but still, the old code worked a lot better.

https://forums.raspberrypi.com/viewtopic.php?p=1957644#p1944867

could this be another case?

[XECDesign]

I'm unable to reproduce the issue either.

@spl237 should we close this one as a wontfix, or do you have any ideas?

[spl237]

I'd close as wontfix - we can't repeat it, so it looks to be hardware-specific and only affecting a small number of people.

[giddyhup]

Please look at https://forums.raspberrypi.com/viewtopic.php?p=1974238#p1974238 before closing the issue.

[XECDesign]

Please look at https://forums.raspberrypi.com/viewtopic.php?p=1974238#p1974238 before closing the issue.

I have but the comments there and the fact that it seems to be depend on the hardware seems to suggest it's a kernel issue rather than anything directly related to mutter.

[giddyhup]

@XECDesign, so the issue should be moved/reopened? Where would be the right place?

[XECDesign]

@6by9 and @popcornmix look after that part of https://github.com/raspberrypi/linux/, so they may be able to say whether it's worth a shot opening an issue there or if there's just not much that can be done without hardware that exhibits the issue available.

[pablosproject]

Hi, I have the same issue here. I have a bunch of kiosks that are on 3 different screen models, but before the latest update, everything was working fine. Now when the screen blanking is set, the screen goes black for a little fraction of time and comes back on, won't stay off.

I think this is related to the newly released code as the older version was working for 1+ years without any issue.

[XECDesign]

Latest update of what? Do you have a package name and version numbers of working and non-working versions?

[pablosproject]

It's not clear to me if the xset package is included in xserver-common (but looks like), looking at the latest update log on non working machines xserver-common jumped to 2:1.20.4-1+rpt4+deb10u4, previously was 2.8.5-2

[giddyhup]

My conclusion is that my issue is not related to mutter but to the KMS video driver. After some experimenting I discovered that I can use mutter (and VNC) and turn the display/HDMI off when KMS is not enabled with :

export DISPLAY=:0
xset dpms force off
vcgencmd display_power 0

[perbilse]

One year on, problem remains (and the issue remains "closed"). I upgraded to Bullseye last weekend, and promptly found screensaver blanking not working correctly. It would turn the monitors off, but they would power on again after a few moments; moreover, if in 1280x720 resolution, they would power up in 1920x1080, maybe suggesting more of a reset than an unblanking. Changing to the vc4-fkms-v3d overlay restored correct behaviour, while enabling VNC made no difference.

EDIT: having trawled the RPi online forums, I found a suggestion to add vc4.force_hotplug=3 to the kernel command line. This works, behaviour is as expected with the KMS overlay. Hopefully somebody will find this useful, but I don't understand why this is a problem in the first place. My machine is a perfectly regular RPi4 running up-to-date Raspberry Pi OS with a MATE desktop; it has two BenQ monitors and a selection of common USB devices attached, all totally bog standard.

[reidi]

Could someone please specify which script must be edited to "add vc4.force_hotplug=3 to the kernel command line"? Thanks.

[IjvenR]

from what I could gather it is in "/boot/cmdline.txt" but it does not behave as advertised unfortunately (for me at least). it seems to enable hdmi2 (which is not attached) and send that to VNC viewer on a different resolution.

Still no answer to making the screen go to sleep again...

[perbilse]

The hotplug config is a bitmask, so setting it to 3 will apply to both HDMI outputs; try setting it to 1 to enable only HDMI1. The screnblanking problem appears to be a recurring and ongoing issue, it has also been discussed here in the Bullseye comments and bug reports thread: https://forums.raspberrypi.com/viewtopic.php?t=323281 Another thing that worked for me was to downgrade xserver-xorg-core to a previous (non-RPi specific) version, details here: https://forums.raspberrypi.com/viewtopic.php?t=323281&start=1025#p2085091 This didn't work for somebody else, however, see later comments in the thread.

[IjvenR]

@perbilse, Thanks! Reverting the xserver-xorg-core did fix the issue for me!

[axkg]

Thanks @perbilse, downgrading solved it for me, too, note that adding vc4.force_hotplug=3 did not. Even worse, that seems to impact the display mode timings - my display will not accept the signal with that parameter in the command line.

[DeeXii]

I'm having this same issue. I was running pihole for 9 months with the same screen and it was timing out before and now it doesn't. It goes blank for a sec and comes right back on. Any suggestions?

[DeeXii]

The hotplug config is a bitmask, so setting it to 3 will apply to both HDMI outputs; try setting it to 1 to enable only HDMI1. The screnblanking problem appears to be a recurring and ongoing issue, it has also been discussed here in the Bullseye comments and bug reports thread: https://forums.raspberrypi.com/viewtopic.php?t=323281 Another thing that worked for me was to downgrade xserver-xorg-core to a previous (non-RPi specific) version, details here: https://forums.raspberrypi.com/viewtopic.php?t=323281&start=1025#p2085091 This didn't work for somebody else, however, see later comments in the thread.

How do I revert?

[perbilse]

How do I revert?

There are step-by-step instructions if you follow the second link, but downgrading may not work for you. If so, I'm afraid there's nothing more I can do to help, my knowledge about this is limited to what I've already posted.

[gelaw2]

This issue still persists. I have the exact same problem. I get the screen to blank once, then it comes back on it's own and never blanks again. Does this for me in Bullseye and now in Bookworm. Rpi4B. Tried many "fixes". None worked or I wouldn't be posting this.

[perbilse]

What works for me now (on Bullseye, no idea about Bookworm) is to specify "fake" kms dtoverlay=vc4-fkms-v3d in /boot/config.txt and adding vnc4.force_hotplug=3 (bitmask 3 for two monitors) to /boot/cmdline.txt. The rest of the system is up to date without any hacks or modifications (ie no downgrades) and xset s activate works as expected. If this doesn't work for you there must be some other unknown system config difference, but I have no idea what that would be.

Edit: It occurs to me that I use the MATE desktop, that could very well make a difference; MATE has become so much a second nature thing that I never thought about it, sorry.

[6by9]

What works for me now (on Bullseye, no idea about Bookworm) is to specify "fake" kms dtoverlay=vc4-fkms-v3d in /boot/config.txt and adding vnc4.force_hotplug=3 (bitmask 3 for two monitors) to /boot/cmdline.txt.

Contradictory/redundant changes in there vc4-fkms-v3d is deprecated, but also in doing so you've disabled the code that will respond to vc4.force_hotplug=3 (I'm assuming the vnc4 was a typo).

It is suspected that some monitors deassert HotPlug Detect (HPD) when they go to sleep, which generates an event and wakes up the desktop. Retaining vc4-kms-v3d and using vc4.force_hotplug=3 makes the system ignore HPD, and generally the desktop will sleep. It does mean that it doesn't detect any changes if you change monitor though.

And yes, using MATE is a huge difference.

[perbilse]

Many thanks for your notes, very informative. For many people (including myself) the venerable Pi is a platform that we cherish, but it is not a hobby or hacking project, and we have no interest or time to invest in understanding its innards. Hence, it's very frustrating when problems like this persist for release after release, seemingly with nobody caring: this particular thread was started two years ago, and has until now revolved around hearsay, which often is the only option available.

Following on from your notes I can confirm that (at least for me, YMMV) using the MATE desktop and a Bullseye 11.9 updated today, the 'real' KMS overlay works with vc4.hotplug set (yes, vnc4 was a Freudian slip).

Thanks again for your input, much appreciated.