LOCK_SCREEN= seems to be inoperative in /etc/default/acpi-support

Asked by Richard Elkins

LOCK_SCREEN=false in /etc/default/acpi-support (or just commenting out the original LOCK_SCREEN=true) doesn't seem to work.
It still locks the screen no matter what the LOCK_SCREEN condition is when I resume from suspend.
I did reboot after editing that parameter although I think that restarting acpid and acpi-support in /etc/init.d would have sufficed.

Am I overlooking something?

Thanks ... Richard

My /etc/default/acpid file:

# Specify options for acpid startup, Debian default is to enable the
# use of sockets at a non-default position
OPTIONS="-s /var/run/acpid.socket"

# Specify modules to load on acpid's startup
# MODULES may be uncommented to load "none", contain the string "all"
# to load all acpi related modules or simply a space seperated list
# of modules to be probed.
#MODULES="battery ac processor button fan thermal"
# using all allows us to drop extra modules in drivers/acpi and have them
# be autoloaded.
MODULES="all"

My /etc/default/acpi-support file:

# Comment the next line to disable ACPI suspend to RAM
ACPI_SLEEP=true

# Comment the next line to disable suspend to disk
ACPI_HIBERNATE=true

# Change the following to "standby" to use ACPI S1 sleep, rather than S3.
# This will save less power, but may work on more machines
ACPI_SLEEP_MODE=mem

# Add modules to this list to have them removed before suspend and reloaded
# on resume. An example would be MODULES="em8300 yenta_socket"
#
# Note that network cards and USB controllers will automatically be unloaded
# unless they're listed in MODULES_WHITELIST
MODULES="fglrx"

# Add modules to this list to leave them in the kernel over suspend/resume
MODULES_WHITELIST=""

# Should we save and restore state using the VESA BIOS Extensions?
SAVE_VBE_STATE=true

# The file that we use to save the vbestate
VBESTATE=/var/lib/acpi-support/vbestate

# Should we attempt to warm-boot the video hardware on resume?
POST_VIDEO=true

# Save and restore video state?
#SAVE_VIDEO_PCI_STATE=true

# Should we switch the screen off with DPMS on suspend?
USE_DPMS=true

# Use Radeontool to switch the screen off? Seems to be needed on some machines
# RADEON_LIGHT=true

# Uncomment the next line to switch away from X and back again after resume.
# This is needed for some hardware, but should be unnecessary on most.
# DOUBLE_CONSOLE_SWITCH=true

# Set the following to "platform" if you want to use ACPI to shut down
# your machine on hibernation
HIBERNATE_MODE=shutdown

# Comment this out to disable screen locking on resume
LOCK_SCREEN=false

# Uncomment this line to have DMA disabled before suspend and reenabled
# afterwards
# DISABLE_DMA=true

# Uncomment this line to attempt to reset the drive on resume. This seems
# to be needed for some Sonys
# RESET_DRIVE=true

# Add services to this list to stop them before suspend and restart them in
# the resume process.
STOP_SERVICES=""

# Restart Infra Red services on resume - off by default as it crashes some
# machines
RESTART_IRDA=false

# Switch to laptop-mode on battery power - off by default as it causes odd
# hangs on some machines
ENABLE_LAPTOP_MODE=false

# Spindown time on battery
SPINDOWN_TIME=12

Question information

Language:
English Edit question
Status:
Solved
For:
acpi-support Edit question
Assignee:
No assignee Edit question
Solved by:
Richard Elkins
Solved:
Last query:
Last reply:
Revision history for this message
Richard Elkins (texadactyl) said :
#1

More info:

I just noticed that this happens only when I *manually* suspend ACPI with the Gnome applet: Power Manager 2.22.1.
When I just walk away, come back, and resume, then LOCK_SCREEN=false in /etc/default/acpi-support seems to do what I had intended.

-Richard

Revision history for this message
Richard Elkins (texadactyl) said :
#2

I looked in the gnome-power-manager section of gconf-editor again and what did I find?
The lock screen boxes were now all checked!
I unchecked the box for Suspend and then tried manual suspend.

Problem solved.

But why oh why do we have "lock screen" settings at different levels? It was challenging enough with one place to find by googling.
History, I guess.

The desktop folks need a better human interface to take care of both the desktop level and the ACPI level to ensure consistency.

-Richard