Displays wake up pre-maturely (likely driven by notification)

[Dean Henrichsmeyer]

After a period of time, my displays go to sleep as they should. However, I often come back to find that the displays are awake, the mouse pointer is on a screen, but the screens are otherwise black. They're in this weird "awake but not fully on" mode. At that point, they will not go back to sleep as they should unless I fully awake them and let them go back to sleep.

I don't know exactly what triggers the "half awake" but I suspect it's a notification. The displays shouldn't turn on without a user action. It wastes power and is clearly broken. I've attached a photo for an example.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: gnome-shell 3.36.2-1ubuntu1~20.04.1
ProcVersionSignature: Ubuntu 5.4.0-33.37-generic 5.4.34
Uname: Linux 5.4.0-33-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu27.2
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: ubuntu:GNOME
Date: Sun Jun 7 16:10:20 2020
DisplayManager: gdm3
InstallationDate: Installed on 2018-07-24 (684 days ago)
InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 (20180724)
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
RelatedPackageVersions: mutter-common 3.36.2-1ubuntu1~20.04.1
SourcePackage: gnome-shell
UpgradeStatus: Upgraded to focal on 2020-01-07 (152 days ago)

[Daniel van Vugt (vanvugt)]

The most common issue we're seeing in this area right now is that gnome-shell crashes on lock, and so locking fails. That's bug 1877774 with a fix coming soon. Please also check /var/crash in case there is any evidence there (it might be a different crash).

Secondly, we find extensions cause a lot of bugs in gnome-shell. So please try without these:

  '<email address hidden>',
  '<email address hidden>',
  '<email address hidden>'

[Dean Henrichsmeyer (dean)]

I have no crashes in /var/crash of gnome-shell and I've removed all non-system extensions. I'll post an update once I observe either the behavior or lack there of.

[Sebastien Bacher (seb128)]

Could you add your 'journalctl -b 0' log when you notice the issue and add a note about the time where you saw the issue/interacted with the computer?

[Dean Henrichsmeyer (dean)]

I rebooted last night for a new kernel. This morning the monitors were on with nothing but a cursor on the screen again. Attached is the journal output.

[Daniel van Vugt (vanvugt)]

The only possibly-related information I can see there is:

  Jun 12 06:17:30 hero boltd[7027]: power: setting force_power to ON
  Jun 12 06:17:30 hero boltd[7027]: power: state changed: supported/on
  Jun 12 06:17:30 hero boltd[7027]: power: guard '3' for 'fwupd' active

which may be relevant because DisplayPort and Thunderbolt are the same bus, at least for Intel GPUs. So a few more ideas to try:

  1. Disable fwupd, with something like:

     sudo systemctl stop fwupd.service
     sudo systemctl disable fwupd.service

  2. Disable Night Light. There have been some bug reports, and suggestions from upstream, that gnome-settings-daemon managing the colour profile separately to the power state is causing some confused states.

  3. If all else fails, report the issue upstream: https://gitlab.gnome.org/GNOME/mutter/issues

[Sebastien Bacher (seb128)]

@Dean, thanks for the log. Did you see the issue directly on boot? Did you note the time where you saw it (would be useful to match the log activity)

[Dean Henrichsmeyer (dean)]

I've disabled fwupd and cups and I still see it in the morning when I come
into the office. I'm inclined to shutdown boltd and see if that stops it
from happening since I don't have anything plugged into the thunderbolt
port at this time.

[Daniel van Vugt (vanvugt)]

Also check that you don't have a Night Light schedule which might be triggering it:

  Settings > Screen Display > Night Light [in the top bar]

[Dean Henrichsmeyer (dean)]

I don't use nightlight and disabling bolt didn't help. As I think it's
notification related, I'm going to turn on do not disturb this evening and
see what happens.

[Dean Henrichsmeyer (dean)]

OK, I'm out of ideas. Using do not disturb and thereby eliminating
notifications didn't help either.

[Daniel van Vugt (vanvugt)]

If you report it upstream:

  https://gitlab.gnome.org/GNOME/mutter/issues

then they will be able to provide more suggestions to better understand what power management is doing.

[Daniel van Vugt (vanvugt)]

There's a slight chance this is a side-effect of gnome-settings-daemon trying to enforce the default colour profile. It's a bit of a mess but I believe that does so by programming the display hardware directly, independently of the power mode mutter/gnome-shell last set. So if gnome-settings-daemon has touched the hardware more recently than mutter/gnome-shell I imagine problems like this might occur.

To reduce or eliminate the risk of that you can disable (toggle off) the default profile for your display(s) in: Settings > Color

[Daniel van Vugt (vanvugt)]

Also, you say there's no evidence of crashes but we should check to see if there are any crashes occurring without a trace. To do that please run:

  pidof gnome-shell

in the evening and again in the morning. They should both report the same process ID.

[Dean Henrichsmeyer (dean)]

I disabled the color profile of both of my displays and my printer and the
displays are still awake in the morning. I did check the PID of gnome-shell
and it is the same so there don't appear to be any silent crashes.

[Daniel van Vugt (vanvugt)]

Another idea: You seem to be using the default Xorg session so that increases the possible set of components that could tamper with the power state. Please try logging into 'Ubuntu on Wayland' to see if the problem happens there.

And another idea: Check that you don't have 'tlp' installed. It causes random power management bugs. Assuming the issue is not tlp, please also report it upstream at: https://gitlab.gnome.org/GNOME/mutter/issues

If you are feeling adventurous then it might help to figure out the exact time of day the display is waking. Like with a timelapse video next to a clock that's synchronized to the machine's clock. That could then be compared to the system log or might spark other ideas.

[Dean Henrichsmeyer (dean)]

Quick update. I do not have tlp installed and it also does it on Wayland.
I'm out of ideas.

On Wed, Jun 24, 2020 at 9:25 PM Daniel van Vugt <email address hidden>
wrote:

> Another idea: You seem to be using the default Xorg session so that
> increases the possible set of components that could tamper with the
> power state. Please try logging into 'Ubuntu on Wayland' to see if the
> problem happens there.
>
> And another idea: Check that you don't have 'tlp' installed. It causes
> random power management bugs. Assuming the issue is not tlp, please also
> report it upstream at: https://gitlab.gnome.org/GNOME/mutter/issues
>
> If you are feeling adventurous then it might help to figure out the
> exact time of day the display is waking. Like with a timelapse video
> next to a clock that's synchronized to the machine's clock. That could
> then be compared to the system log or might spark other ideas.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1882462
>
> Title:
> Displays wake up pre-maturely (likely driven by notification)
>
> Status in gnome-shell package in Ubuntu:
> Confirmed
>
> Bug description:
> After a period of time, my displays go to sleep as they should.
> However, I often come back to find that the displays are awake, the
> mouse pointer is on a screen, but the screens are otherwise black.
> They're in this weird "awake but not fully on" mode. At that point,
> they will not go back to sleep as they should unless I fully awake
> them and let them go back to sleep.
>
> I don't know exactly what triggers the "half awake" but I suspect it's
> a notification. The displays shouldn't turn on without a user action.
> It wastes power and is clearly broken. I've attached a photo for an
> example.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 20.04
> Package: gnome-shell 3.36.2-1ubuntu1~20.04.1
> ProcVersionSignature: Ubuntu 5.4.0-33.37-generic 5.4.34
> Uname: Linux 5.4.0-33-generic x86_64
> NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
> ApportVersion: 2.20.11-0ubuntu27.2
> Architecture: amd64
> CasperMD5CheckResult: skip
> CurrentDesktop: ubuntu:GNOME
> Date: Sun Jun 7 16:10:20 2020
> DisplayManager: gdm3
> InstallationDate: Installed on 2018-07-24 (684 days ago)
> InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64
> (20180724)
> ProcEnviron:
> TERM=xterm
> PATH=(custom, no user)
> XDG_RUNTIME_DIR=<set>
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> RelatedPackageVersions: mutter-common 3.36.2-1ubuntu1~20.04.1
> SourcePackage: gnome-shell
> UpgradeStatus: Upgraded to focal on 2020-01-07 (152 days ago)
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1882462/+subscriptions
>
> Launchpad-Notification-Type: bug
> Launchpad-Bug: distribution=ubuntu; sourcepackage=gnome-shell;
> component=main; status=Confirmed; importance=Undecided; assignee=None;
> Launchpad-Bug-Tags: amd64 apport-bug focal
> Launchpad-Bug-Information-Type: Public
> Launchpad-Bug-Private: no
> Launchpad-Bug-Security-Vulnerability:...

[Daniel van Vugt (vanvugt)]

Looking at the most recent log in comment #6 again, that was back when you had fwupd and boltd running. I wonder if you could provide a system log from a night where those were disabled?

  journalctl -b0 > journal.txt

I'm still particularly skeptical of fwupd because it appears that caused a redetection of your Dell monitor at Jun 12 06:17:31, which probably also turned the monitor on.

[Dean Henrichsmeyer (dean)]

OK, so an update. I removed fwupd from my system and I can confirm that
once I can get the displays to sleep, they stay that way as they should.

Now for the weird part... they won't go to sleep on their own. Doesn't
matter whether I'm in Wayland or Xorg - they won't go to sleep on their
own. DPMS is shown enabled with xset q in Xorg, settings are default in
terms of displays going to sleep, but they never do. If I do Super-L they
will go to sleep and wake right back up. If I then unlock the machine and
do Super-L again, they will go to sleep and stay that way. The only thing
changed was me apt removing fwupd.

This is a puzzle that refuses to be solved apparently. Should I file a new
bug for the current behavior?

[Daniel van Vugt (vanvugt)]

I've set this bug to track:

  https://gitlab.gnome.org/GNOME/mutter/-/issues/877

but there's also:

  https://gitlab.gnome.org/GNOME/mutter/-/issues/976

and maybe also see:

  https://gitlab.gnome.org/GNOME/mutter/-/issues/915

Although I think we should be careful to keep this bug about a single issue.

[Daniel van Vugt (vanvugt)]

Also try setting the monitor's input source (there's a button for that surely) to something other than 'Auto'. I fear Auto might be doing some active scanning and wake itself up when it comes back to the connector that you're using but wish to keep off.