I purged both xfce4-screensaver and light-locker packages, restarted
lightdm and tested with x-p-m set to suspend on lid-close for battery
(and AC as I've had the battery exhaust several times due to the length
of these tests!)

In this case there is no password challenge dialog on resume.

It failed on 1st suspend-resume cycle. GUI TTY blanked, but console TTYs
are fine.

I was thinking back to the tests I did when this first hit 18.04 (when I
reported this bug originally) and seem to recall that adding debug
logging was enough to prevent the failure and led me to hypothesise this
is a race condition.

I'm going to try booting the systems with maxcpus= 1 and 0.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1759950

Title:
  Lid-close suspend: blank screen when switching to user session

Status in Light-Locker:
  New
Status in Xfce4 Power Manager:
  Confirmed
Status in light-locker package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  New
Status in xfce4-power-manager package in Ubuntu:
  Confirmed
Status in xubuntu-default-settings package in Ubuntu:
  New

Bug description:
  I'm currently testing Xubuntu 18.04 after a do-release-upgrade from
  16.04.

  I discovered a very weird issue. When doing S3 sleep via closing the
  lid, on resume the lock screen appears, I authenticate, but as soon as
  it switches to the user session the screen goes blank - not even a
  backlight.

  Switching to other ttys works and they display correctly but the GUI
  user session remains blank.

  If the system is manually suspended (not using the lid), then resumed
  either by opening the lid or pressing the power button, the GUI user
  session is fine.

  I narrowed it down to xfce4-power-manager and discovered disabling the
  lock-screen cured the issue.

  I cloned the repository and reviewed commits between 1.7 and 1.8.
  Fortunately there aren't many. Looking at 6365683 "Proper exit status
  for light-locker-command" I suspected the change in the SetActive
  return value, and reverted it.

  After a build/install cycle I've found the system now behaves
  correctly so I think the change should be reverted.

  I've created an issue upstream for this at

  https://github.com/the-cavalry/light-locker/issues/108

To manage notifications about this bug go to:
https://bugs.launchpad.net/light-locker/+bug/1759950/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to