HDMI screen doesn't suspend

[dom]

I answered your questions in the quote.

It sounds like this is a deliberate behaviour of chromium and not a bug.
It's not pi specific (in fact it even behaves the same on windows).

It's not something we will change. You'd be better off trying to convince Chromium developers.

Searching around there are a number of users who don't like the behaviour. e.g here.

[zepp]

I answered your questions in the quote.

It sounds like this is a deliberate behaviour of chromium and not a bug.
It's not pi specific (in fact it even behaves the same on windows).

It's not something we will change. You'd be better off trying to convince Chromium developers.

Searching around there are a number of users who don't like the behaviour. e.g here.

Sorry @dom but this is not something that happens on Windows or even Ubuntu. I can testify it.

I thought it was X or LXDE related, but maybe I'm wrong.

[dom]

If you run:

Code: Select all

dbus-monitor "interface='org.freedesktop.ScreenSaver'"

And play a youtube video, you will see:

Code: Select all

method call time=1673962889.849377 sender=:1.93 -> destination=org.freedesktop.ScreenSaver serial=5 path=/org/freedesktop/ScreenSaver; interface=org.freedesktop.ScreenSaver; member=Inhibit
   string "/usr/lib/chromium-browser/chromium-browser-v7"
   string "Video Wake Lock"

which is chromium requesting to inhibit the screensaver. Stopping playback causes:

Code: Select all

method call time=1673962978.539398 sender=:1.93 -> destination=org.freedesktop.ScreenSaver serial=7 path=/org/freedesktop/ScreenSaver; interface=org.freedesktop.ScreenSaver; member=UnInhibit
   uint32 372639618

I'm not an expert on this, but it seems clear that disabling the screensaver is a deliberate action of chromium when displaying certain content (I think, from searching it's WebRTC, which is typically used for video and audio streaming).

[bjtheone]

Sorry @dom but this is not something that happens on Windows or even Ubuntu. I can testify it.

I thought it was X or LXDE related, but maybe I'm wrong.

If it was X related, it would impact Ubuntu as well.

Screen saving and monitor power saving both work fine for me on Bullseye. However, my main desktop system is using MATE and has mutter ripped out. It always has Chromium running, and often has youtube or spotify going. No issues with the screensaver with a youtube or spotify tab open, with the video/music paused. Don't know if it will screen save with an active video/audio stream since I always pause them, before leaving.

I don't think it is an LXDE issue, since I have a couple systems with LXDE that behave properly. Disabling mutter is easy, as a test, and quite frankly mutter does not bring anything particularly useful/earthshattering to the table at this point.

[zepp]

You, engineers, didn't understand me. When video call (or video playback) is over, it is obviously normal that screen can enter suspend mode again. Behaving otherwise is abnormal.

[perbilse]

To add my tuppence worth, 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 (as suggested elsewhere) made no difference.

Having trawled the RPi online forums, I found the suggestion from @kerry_s (Thanks!) to add

Code: Select all

vc4.force_hotplug=3

to the kernel command line. This works, behaviour is as expected with the KMS overlay, 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. Anyway, hopefully somebody will find this useful.

[kerry_s]

To add my tuppence worth, 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 (as suggested elsewhere) made no difference.

Having trawled the RPi online forums, I found the suggestion from @kerry_s (Thanks!) to add

Code: Select all

vc4.force_hotplug=3

to the kernel command line. This works, behaviour is as expected with the KMS overlay, 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. Anyway, hopefully somebody will find this useful.

on my screens i found i had to go in to the settings and turn some of the auto settings to settings i wanted and didn't have to modify cmdline.txt any more.

[zepp]

On Monday (2023/02/06) I got a couple of updates waiting, among them Chromium update to version 109.0.5414.112.

Since the update is applied, my Raspberry Pi and my monitor are behaving as expected, as far as I have tested (video calls). Good news !

[dom]

Since the update is applied, my Raspberry Pi and my monitor are behaving as expected, as far as I have tested (video calls). Good news !

That's good to hear.