[regression] on login screen, monitor stays on forever

[Eugene Crosser]

I am not sure which package sould be responsible for that, probably either xorg-server or lightdm.

Previously, up to raring, when you left the computer alone while it was showing the login screen (lightdm in my case), the monitor would turn off after five or ten minutes. Since upgrade from raring to saucy, monitor stays on indefinitely, after boot and after logout likewise. This is on two machines, one a notebook with Intel graphics, another desktop with Radeon using open source driver.

I guess maybe setting up DPMS got broken in the process of migration to Mir and back to xorg.
---
.tmp.unity.support.test.0:

ApportVersion: 2.12.5-0ubuntu2.1
Architecture: amd64
CompizPlugins: [core,composite,opengl,compiztoolbox,decor,vpswitch,snap,mousepoll,resize,place,move,wall,grid,regex,imgpng,session,gnomecompat,animation,fade,unitymtgrabhandles,workarounds,scale,expo,ezoom,unityshell]
CompositorRunning: compiz
CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0'
CompositorUnredirectFSW: true
DistUpgraded: 2013-10-26 13:27:24,614 DEBUG enabling apt cron job
DistroCodename: saucy
DistroRelease: Ubuntu 13.10
DistroVariant: ubuntu
ExtraDebuggingInterest: Yes
GraphicsCard:
 Advanced Micro Devices, Inc. [AMD/ATI] Trinity [Radeon HD 7660D] [1002:9901] (prog-if 00 [VGA controller])
   Subsystem: ASUSTeK Computer Inc. Device [1043:8526]
MachineType: System manufacturer System Product Name
MarkForUpload: True
Package: xorg-server (not installed)
ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-3.11.0-13-generic root=UUID=72283a55-e0f7-4036-af5e-be1174497a35 ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.11.0-13.20-generic 3.11.6
Tags: saucy ubuntu compiz-0.9
Uname: Linux 3.11.0-13-generic x86_64
UpgradeStatus: Upgraded to saucy on 2013-10-26 (2 days ago)
UserGroups: adm admin audio cdrom dialout lpadmin plugdev sambashare video
dmi.bios.date: 10/09/2012
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 5105
dmi.board.asset.tag: To be filled by O.E.M.
dmi.board.name: F2A85-M LE
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: Rev X.0x
dmi.chassis.asset.tag: Asset-1234567890
dmi.chassis.type: 3
dmi.chassis.vendor: Chassis Manufacture
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr5105:bd10/09/2012:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKCOMPUTERINC.:rnF2A85-MLE:rvrRevX.0x:cvnChassisManufacture:ct3:cvrChassisVersion:
dmi.product.name: System Product Name
dmi.product.version: System Version
dmi.sys.vendor: System manufacturer
version.compiz: compiz 1:0.9.10+13.10.20131011-0ubuntu1
version.ia32-libs: ia32-libs N/A
version.libdrm2: libdrm2 2.4.46-1
version.libgl1-mesa-dri: libgl1-mesa-dri 9.2.1-1ubuntu3
version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
version.libgl1-mesa-glx: libgl1-mesa-glx 9.2.1-1ubuntu3
version.xserver-xorg-core: xserver-xorg-core 2:1.14.3-3ubuntu2
version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.7.3-0ubuntu3.1
version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.2.0-0ubuntu10
version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.904-0ubuntu2
version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.9-2ubuntu1
xserver.bootTime: Mon Oct 28 12:00:05 2013
xserver.configfile: /etc/X11/xorg.conf
xserver.errors:
 Failed to load /usr/lib/xorg/modules/drivers/fglrx_drv.so: /usr/lib/xorg/modules/drivers/fglrx_drv.so: cannot open shared object file: No such file or directory
 Failed to load module "fglrx" (loader failed, 7)
 Failed to load /usr/lib/xorg/modules/drivers/fglrx_drv.so: /usr/lib/xorg/modules/drivers/fglrx_drv.so: cannot open shared object file: No such file or directory
 Failed to load module "fglrx" (loader failed, 7)
xserver.logfile: /var/log/Xorg.0.log
xserver.version: 2:1.14.3-3ubuntu2
xserver.video_driver: radeon

[Quinn Balazs (qbalazs)]

Let's target xorg-server to start with. In addition to the logs from xorg-server, please upload the logs contained in /var/log/lightdm. Collecting the xorg-server logs should be as easy as running "apport-collect 1245474".

[Eugene Crosser (crosser)]

apport information

[Eugene Crosser (crosser)]

apport information

[Eugene Crosser (crosser)]

apport information

[Eugene Crosser (crosser)]

apport information

[Eugene Crosser (crosser)]

apport information

[Eugene Crosser (crosser)]

apport information

[Eugene Crosser (crosser)]

apport information

[Eugene Crosser (crosser)]

apport information

[Eugene Crosser (crosser)]

apport information

[Eugene Crosser (crosser)]

apport information

[Eugene Crosser (crosser)]

apport information

[Eugene Crosser (crosser)]

apport information

[Eugene Crosser (crosser)]

apport information

[Eugene Crosser (crosser)]

apport information

[Eugene Crosser (crosser)]

apport information

[Eugene Crosser (crosser)]

apport information

[Eugene Crosser (crosser)]

apport information

[Eugene Crosser (crosser)]

apport information

[Eugene Crosser (crosser)]

apport information

[Eugene Crosser (crosser)]

apport information

[Eugene Crosser (crosser)]

apport information

[Eugene Crosser (crosser)]

apport information

[Eugene Crosser (crosser)]

apport information

[Eugene Crosser (crosser)]

apport information

[Eugene Crosser (crosser)]

apport information

[Eugene Crosser (crosser)]

apport information

[Eugene Crosser (crosser)]

I've found something that may be useful both for diagnosis and as a workaround.

If you define a "display-setu-script" in the lightdm configuration, like this:

[SeatDefaults]
display-setup-script=/path/to/display-setup.sh

and put this command in the "display-setup.sh":

xset dpms 120 125 130

this does NOT fix the problem. But, if you write instead:

(
  sleep 10
  xset dpms 120 125 130
) &

it DOES help, i.e. login screen goes dark after two minutes.
Apparently, it implies that "something" that is started as a part of the greeter "session", i.e. the greeter itself, or one of the indicators, resets the DPMS settings.

In the meanwhile, my display-setup script may be used as a workaround by those who need it.

[Øyvind Stegard (oyvindstegard)]

Eugene Crosser <email address hidden> writes:

> I've found something that may be useful both for diagnosis and as a
> workaround.
>
> If you define a "display-setu-script" in the lightdm configuration, like
> this:
>
> [SeatDefaults]
> display-setup-script=/path/to/display-setup.sh
>
> and put this command in the "display-setup.sh":
>
> xset dpms 120 125 130

I tried this myself a while back and noticed the same thing: something
resets X server DPMS settings after the xset command has executed. Has
any Ubuntu representative considered the possibility that this bug may
cause burn-in-problems for displays over a longer period ? Not to
mention the obvious power waste.

I will be applying your delayed xset work-around script, thanks for that
idea.

Øyvind

[bitinerant (bitinerant)]

I also can confirm this works. Thank you, Eugene!

It took me an embarrassing number of tries to get this right, so for others wanting to implement this work-around:

  printf '\n[SeatDefaults]\ndisplay-setup-script=/usr/bin/bug1245474-work-around.sh\n' |sudo tee /etc/lightdm/lightdm.conf.d/60-display-setu-script.conf
  sudo chmod 644 /etc/lightdm/lightdm.conf.d/60-display-setu-script.conf
  printf '( sleep 10; xset dpms 120 125 130 ) &\n' |sudo tee /usr/bin/bug1245474-work-around.sh
  sudo chmod 755 /usr/bin/bug1245474-work-around.sh

Don't forget to reboot.

[Matthew Gregg (mcg)]

Workaround works for me as well, but seems to trump the "Turn off screen when inactive" setting for my desktop session. I have that set for 10 minutes and immediate lock, but with this enabled it will blank the screen at the scripts timeout and will not lock.

[Ted Felix (tedfelix)]

Thanks, Eugene. Your solution works for me as well.

To complete this workaround, I've added a script to handle turning off the X dpms timeouts when the user logs in. Here are the three files that I've created. First, the config file:

/etc/lightdm/lightdm.conf.d/50-dpms.conf
--- cut here -------------
[SeatDefaults]
display-setup-script=/etc/lightdm/dpms-enable
session-setup-script=/etc/lightdm/dpms-disable
--- cut here -------------

Make sure the above is owned by root. Easiest is to create it with sudoedit.

Next are the two scripts. These need to be owned by root and made executable (chmod +x).

/etc/lightdm/dpms-enable
--- cut here -------------
#!/bin/sh

(
    # This delay is required. Might be because the X server isn't
    # started yet.
    sleep 10

    # Set up a 5 minute timeout before powering off the display.
    xset dpms 0 0 300
) &
--- cut here -------------

/etc/lightdm/dpms-disable
--- cut here -------------
#!/bin/sh

(
    # This delay is required. Might be because the X server isn't
    # started yet.
    sleep 10

    # Turn off X's handling of dpms timeout. Otherwise
    # gnome-settings-daemon and gnome-screensaver will fight over it.
    xset dpms 0 0 0
) &
--- cut here -------------

Given the above, I get monitor power-down at the login screen, and the dpms timeouts are set to zero for a user session, so the screensaver works properly.

Is this the right solution? I'm not sure. So far, I've been unable to track down how 13.04 did this without config files and scripts. It would be nice to have that for comparison.

[Ted Felix (tedfelix)]

It turns out that in 13.04, display power-off (when lightdm is up) is driven by the X screensaver timeouts. If I do this:

  xset s 60 60

...in lightdm's display-setup-script, the screen powers off (in 13.04) in one minute instead of the usual 10.

13.10 has the X screensaver timeouts set to 10 minutes (600), which should work fine. But nothing happens.

[Sebastien Bacher (seb128)]

> Apparently, it implies that "something" that is started as a part of the greeter "session", i.e. the greeter itself, or one of the indicators, resets the DPMS settings.

That's an interesting comment, maybe somebody could try with lightdm-gtk-greeter to see if that happens there as well?

[Robert Ancell (robert-ancell)]

Unity greeter doesn't do anything to control the power management. It runs gnome-settings-daemon to do this. It seems likely the problem is either unity-greeter not configuring / running the correct plugin in g-s-d or g-s-d being broken.

[Eugene Crosser (crosser)]

Robert, my observations show that the problem is not that proper setting are *not applied*, but that they are *overridden* with wrong values afterwards.

(It conceivable though that g-s-d may be applying the "wrong" values after my display-setup-script has applied the "right" ones. Can you tell where to check the settings that are applied by g-s-d run from the greeter?)

[Ted Felix (tedfelix)]

Robert Ancell:
> It seems likely the problem is either unity-greeter not configuring / running the correct plugin in g-s-d

  It appears that the power plugin is indeed running in both 13.04 and 13.10 as I am seeing logging from it in /var/log/lightdm/x-0-greeter.log in both 13.04 and 13.10.

> or g-s-d being broken.

  One key thing that is different between the two logs is that this line appears in 13.10, but not in 13.04:

(gnome-settings-daemon:1507): power-plugin-WARNING **: Failed to run GetActive() function on screensaver: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface 'org.gnome.ScreenSaver' on object at path /org/gnome/ScreenSaver

  I do know that the power plugin's dpms feature is driven by org.gnome.screensaver, so since connecting to that is failing in 13.10, that might be related to the issue.

Eugene Crosser:
> my observations show that the problem is not that proper setting are *not applied*, but that they are *overridden* with wrong values afterwards.

  This is not what I'm seeing. The DPMS timeouts are not used at the login screen in 13.04 to power off the monitor. The screensaver timeouts are used instead. And the screensaver timeouts are not being modified by anyone when lightdm is running. You can verify this by modifying the display-setup-script and session-setup-script to do an "xset q" before and after the 10 second sleep and log this someplace where it can be easily found. Then examine the screensaver timeouts (not the DPMS) timeouts. The screensaver timeouts stay at 600 for the login screen.

  Certainly, the DPMS timeouts can be used as a successful workaround. However, that's not how 13.04 did it. With 13.04, the DPMS timeouts are 0, and the screen still powers off at the login screen.

  My plan at this point is to try and run g-s-d in debug mode. I'm not sure how to do that elegantly. I'm going to try pointing /usr/bin/g-s-d to a script that adds on --debug. If anyone has a better suggestion, I'd love to hear it. Once g-s-d is running in debug, I should be able to see it power the monitor on/off in 13.04 and perhaps some additional clues in 13.10. Worst case. I have been doing some power plugin hacking recently, so I can easily drop in a replacement with further logging.

  As always, no guarantee this will get me anywhere. I've run into many brick walls trying to figure this out over the past few weeks.

[Ted Felix (tedfelix)]

Through some script trickery, I was able to get g-s-d running in debug mode. It appears from the debug output that in 13.04, g-s-d's power plugin is *not* responsible for powering off the monitor when lightdm/unity-greeter is up. The question is: Who is?

(Power is out here, probably for a week, so I won't be able to do any more digging for the moment.)

[Ted Felix (tedfelix)]

My (completely unconfirmed) suspicion at this point is that the problem lies in xorg-server. I'm guessing that xorg-server has a built-in default screensaver of some sort that turns off the monitor. In 13.04, this was working fine. In 13.10, it no longer is. I'm going to shift my focus to xorg-server and see what I find there....

[Jorge Juan (jjchico)]

Dear friends, please note that gdm works fine (it is currently my workaround):

$ sudo apt-get install gdm
(and/or)
$ sudo dpkg-reconfigure gdm

[Ted Felix (tedfelix)]

I've read through the portions of Xorg that are directly related to the screensaver timeouts (dixSaveScreens() and friends) and it appears that my suspicion is incorrect. I was unable to find any sort of built-in default screensaver. Another dead end.

Then I remembered that the kernel has a built-in screensaver. This appears to be leading somewhere now. In 13.04, you can adjust the login screen timeout by adjusting the terminal blank timeout. Log out of all X sessions (in 13.04) and go to VT1 (Alt-Ctrl-F1). Then login and use setterm to adjust the blank timeout to 1 minute.

  $ setterm -blank 1

Now, switch back to VT7 (Alt-F7) and wait one minute. The display will power off (in 13.04).

This doesn't work in 13.10. However, it does work for the other virtual terminals in 13.10. So, it's as if the kernel's terminal blank feature is somehow set up to have no effect on Virtual Terminal 7. Assuming I'm on the right path, we should have an answer soon.

[Eugene Crosser (crosser)]

@Ted, I am not convinced that you are re-assigning the blame correctly.
I have no 13.04 to compare, but I believe that if the kernel (setterm) blanking timeout affected the X screen in 13.04, that was probably a bug rather than a feature. X blanking is controlled by the builtin "screensaver" feature (command line parameter '-s' and xset's parameter 's'), and by builtin "dpms" feature (command line parameter '-dpms' and xset's parameter 'dpms'). The '-s' parameter, by design, just makes the display show black colour, while the latter can signal the monitor to switch to powersaving mode(s). While Xorg is controlling the display, these settings should override the kernel 'setterm' settings.

Display manager starts the X server. It can specify the command-line parameters, and it can modify the settings of the server afterwards. On Ubuntu/lightdm, the command-line parameters are here:

/etc/lightdm/lightdm.conf.d/50-xserver-command.conf

The default is:

xserver-command=X -core -s 5 v

which means screensaver timeout 5 minutes, dpms not set.
You can easily add '-dpms' argument here. Or you can change screensaver or dpms settings from the display-setup script.

The point is that if you do assign some settings in the command line or from the display-setup script, "something" resets them back shortly afterwards. It might be the power manager that tries to do its job, fails, and just resets the dpms. Or it might be something else.

[Ted Felix (tedfelix)]

Eugene Crosser:
> if you do assign some settings in the command line or from the display-setup script, "something" resets them back shortly afterwards.

  That would be g-s-d's power plugin. See gpm-common.c, disable_builtin_screensaver() and gsd_power_enable_screensaver_watchdog(). g-s-d's power plugin disables the DPMS timeouts because it takes over the job of doing DPMS in response to the screensaver going active (as indicated over d-bus at org.gnome.ScreenSaver). However, unity-greeter does not launch gnome-screensaver, so there is no one to indicate the screensaver is active over d-bus, so g-s-d never powers off the display.

  At this point, ISTM that the right solution is for unity-greeter to launch gnome-screensaver (with locking turned off so that it doesn't prompt for lightdm's password). However, there must be a reason that it doesn't. And that is why I am investigating the details of 13.04's solution. So that I don't end up coding the wrong solution.

[Sebastien Bacher (seb128)]

The issue there seems to be that the gnome-settings-daemon power plugin relies on gnome-screensaver to turn off the screen, or the screensaver is not running on the greeter... we either need to teach unity-greeter to turn off the screen or to fix u-s-d to work without gnome-screensaver

[Robert Ancell (robert-ancell)]

It will probably be easiest to make unity-greeter implement the required D-Bus interface and do the power off itself.

[tozen (dpaskovskis)]

Ubuntu 14.04 Unity
Problem steel persist even on new lock screen.

[Rocko (rockorequin)]

The new lightdm-style screensaver that just landed in 14.04 also does not turn off the screen. Is the screensaver implemented by lightdm and therefore related to this bug, or is this a new bug?

[Ramil Minnigaliev (thunderamur)]

With new display blocker after Ctrl+Alt+L monitor is not turn off even after some hours of downtime.

After enter the password and show desktop monitor is turn off if do not touch mouse or keyboard for 2 seconds.

If display blocker will be set automatically - monitor turn off normaly.

[Rocko (rockorequin)]

Yes, I can see that it must be the new unity-greeter screen-locker that is blocking the screen power-down. As minnigaliev-r says, if you lock the screen with ctrl-alt-L or super-L, the screen locks but never powers off, but as soon as you enter your password to unlock it the screen powers off and then immediately powers back on again (so it looks briefly like the computer has crashed). But if you let the screen power off with a timeout and then lock itself automatically, it does actually power off.

[Mateusz Stachowski (stachowski-mateusz)]

The new lock screen is implemented on top of Unity and it only looks like the login screen.

I reported the lock screen not turning off monitor.

https://bugs.launchpad.net/unity/+bug/1292041

[Robert Ancell (robert-ancell)]

In fixing bug 1255558 I noticed that gnome-screensaver is only running sometimes (when it did run the focus bug would occur). So that is probably a factor here.

[Robert Ancell (robert-ancell)]

Rocko, this new locker is implemented by unity and is a new bug. The greeter does not use this method.

[Robert Ancell (robert-ancell)]

Fixed in lp:~robert-ancell/unity-greeter/screensaver. The default screensaver timeout is 300s but this can be changed by editing the "idle-timeout" gsettings key for unity-greeter.

i.e. for testing create /usr/share/glib-2.0/schemas/10_unity-settings-daemon.gschema.override:
[com.canonical.unity-greeter]
idle-timeout=5
then run "sudo glib-compile-schemas /usr/share/glib-2.0" and you can test with a 5 second timeout.

[Launchpad Janitor (janitor)]

This bug was fixed in the package unity-greeter - 14.04.9-0ubuntu1

---------------
unity-greeter (14.04.9-0ubuntu1) trusty; urgency=medium

  * New upstream release:
    - Correctly handle SIGTERM and quit cleanly. We were previously not stopping
      the signal and so not cleaning up on exit. This left an upstart process
      for each greeter remaining.
    - If a user has an invalid session, then use the system default session
      (LP: #1303725)
    - Correctly handle sessions not starting
 -- Robert Ancell <email address hidden> Tue, 08 Apr 2014 15:57:59 +1200

[Eugene Crosser (crosser)]

Confirming fixed in mainstream trusty

[danmb (danmbox)]

This seems to have been fixed in unity-greeter, but not lightdm-gtk-greeter. And in any case, how can the unity-greeter inactivity timeout be tuned? gsettings under the lightdm account?