[raspi] Ubuntu 22.10 does not turn off monitor

[Gordon Fresh]

I am using Ubuntu Desktop 22.10 on Raspberry Pi 4, and noticed a strange behaviour of the screen saver.

In settings -> energy -> power saving options I selected Screen Blank after 5 minutes. After 5 minutes of inactivity, the screen goes blank, the monitor says No Signal and turns off, but a few seconds after it turns on again, showing a completely black screen.

The desired behaviour here is that Ubuntu sends no signal to the monitor, so the monitor goes into low-consumption mode. But this is not happening, the monitor is on and showing a black screen.

I wonder how to solve this problem, especially given the current energy situation in Europe.

This bug is related to the Ubuntu 22.04 LTS and 22.10 version.

ProblemType: Bug
DistroRelease: Ubuntu 22.10
Package: gnome-shell 43.0-1ubuntu2
ProcVersionSignature: Ubuntu 5.19.0-1009.16-raspi 5.19.7
Uname: Linux 5.19.0-1009-raspi aarch64
ApportVersion: 2.23.1-0ubuntu3
Architecture: arm64
CasperMD5CheckResult: unknown
CurrentDesktop: ubuntu:GNOME
Date: Sun Dec 4 21:31:27 2022
DisplayManager: gdm3
GsettingsChanges:

ImageMediaBuild: 20221018.1
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 LANG=pl_PL.UTF-8
 SHELL=/bin/bash
RelatedPackageVersions: mutter-common 43.0-1ubuntu4
SourcePackage: gnome-shell
UpgradeStatus: No upgrade log present (probably fresh install)

[Gordon Fresh (autominus)]

Currently after the last update, the screen dims and still does not turn off.

[Gordon Fresh (autominus)]

A video showing the problem is attached.

[postal (spaminator23)]

I have the same problem on a PC. This also came with the last update.

[Daniel van Vugt (vanvugt)]

This bug is not related to PC. Please log a new bug from your PC by running:

  ubuntu-bug gnome-shell

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Manuel Diewald (diewald)]

I was unable to reproduce this behavior on an up-to-date 22.04 and on 22.10 (5.19.0-1009-raspi) with gnome-shell 43.0-1ubuntu2 running on a Pi4 device.

Do you still experience the issue with the latest kernel image and firmware installed? Have you tried to reproduce the problem with a different monitor?

[Dave Jones (waveform)]

I'm still seeing this behaviour (precisely as described at the top: fades to black, switches off, then switches on to black a second or two later) with the lunar daily image and the bootstrap 6.2 kernel, so it'll likely be an issue in lunar.

I'll flash a jammy and kinetic image to a card in a bit and try and re-confirm them there but kinetic certainly exhibited the issue last week before I upgraded my devel system.

In case this is monitor specific, the monitor I'm using is a Benq GW2270H running at 1080p.

[Juerg Haefliger (juergh)]

FWIW, works for me as well with 5.19.0-1015-raspi. Fades to black, cuts signal, monitor turns off and stays off.

My monitor: https://www.edid.tv/edid/1091/

[Juerg Haefliger (juergh)]

Also works with this monitor: https://www.edid.tv/edid/2266/

[Dave Jones (waveform)]

Fails with this monitor: https://www.edid.tv/edid/2267/

[Dave Jones (waveform)]

FYI, in case anyone wants to add their monitor (and whether it succeeds or fails at suspending with the Ubuntu raspi kernel) to this ticket:

$ cp /sys/devices/platform/gpu/drm/card1/card1-HDMI-A-1/edid hdmi0-monitor.edid
$ cp /sys/devices/platform/gpu/drm/card1/card1-HDMI-A-2/edid hdmi1-monitor.edid

As you may guess, hdmi0-monitor.edid is the EDID for the monitor plugged into HDMI0 (the socket closest to the USB-C power port on the Pi4, and the socket closest to the uSD slot on the Pi400), whilst hdmi1-monitor.edid is the EDID for the monitor plugged into HDMI1. If you have no monitor connected to a socket, you'll still get an EDID file but it'll be 0 bytes. A valid EDID file should be 256 bytes (or more? I forget the details of EDID, but there's some extended blocks I vaguely recall).

Upload valid EDID files to https://www.edid.tv/edid/upload/binary/ if you wish (bear in mind this will share the serial # of your monitor but I don't think there's any particular security risk in that), and add the link here along with whether or not this particular monitor suspends successfully or not.

[Ubuntu QA Website (ubuntuqa)]

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
https://iso.qa.ubuntu.com/qatracker/reports/bugs/1998716

[Daniel van Vugt (vanvugt)]

Success, no bug: https://www.edid.tv/edid/2366/

[Manuel Diewald (diewald)]

It appears this issue is also being tracked upstream [1].

The issue was fixed by adding firmware code that powers off the HDMI port, which in turn causes most monitors to go into suspend mode and turning off [2]. The fkms driver was modified to make use of that firmware feature [3]. Since I can't reproduce the issue, I can't verify this myself, but my assumption would be that the issue does not present itself when the fkms overlay is being used.

With regards to the full kms driver, I don't see how this could be fixed, considering that using a firmware feature is required. So as far as I can see, if using the fkms driver is not an option, there is nothing we could do to solve this issue.

[1]: https://github.com/raspberrypi/linux/issues/3050
[2]: https://github.com/raspberrypi/firmware/commit/00ea13eff012e6ca1488dc84e73bfea7fd6a0612
[3]: https://github.com/raspberrypi/linux/pull/3289

[Dave Jones (waveform)]

> It appears this issue is also being tracked upstream [1].
>
> The issue was fixed by adding firmware code that powers off the HDMI
> port, which in turn causes most monitors to go into suspend mode and
> turning off [2]. The fkms driver was modified to make use of that
> firmware feature [3]. Since I can't reproduce the issue, I can't
> verify this myself, but my assumption would be that the issue does
> not present itself when the fkms overlay is being used.

I'll try and reproduce the issue under fkms.

> With regards to the full kms driver, I don't see how this could be
> fixed, considering that using a firmware feature is required. So as
> far as I can see, if using the fkms driver is not an option, there
> is nothing we could do to solve this issue.

A firmware feature would, presumably, only be required if fkms were in
use (where the closed firmware is in charge of handling the display).
Under kms, the Linux kernel is in charge of the display; no firmware
feature should be required because (as I understand it) there's no
closed firmware driving the display?

[Dave Jones (waveform)]

Okay, some more data-points:

1. I've attempted fkms with the same monitor and as surmised, Ubuntu does manage to suspend the monitor correctly with that overlay in place.

2. I tried my laptop hooked up to the same monitor (it's running Ubuntu Jammy and according to gnome-control-center the graphics card is "Intel UHD Graphics 600") and it too suspends the monitor correctly.

3. I tried another Pi running RaspiOS (which also defaults to the kms overlay). This, too, failed to suspend the monitor in the same way as Ubuntu.

So the only configuration which fails to suspend the monitor is kms (whether under Ubuntu or RaspiOS). I suspect this is an upstream issue therefore (though separate from the fkms one which was indeed fixed). I'll see if I can report it up there against kms specifically.

In the meantime, I'll reset this to confirmed -- though there's little we can do about it, it is a valid issue.

[Sam Vervaeck (samvv)]

Can confirm the same issue appears as described by Dave Jones on my ASUS TUF Gaming A15 (2023) laptop. There might be something wrong with the KMS driver.

[Daniel van Vugt (vanvugt)]

Ubuntu 22.10 is no longer supported, but there's a large number of people tracking the same issue in bug 1971434 so let's move there.