Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#3694 - ACPI's LID events only work when you close the lid and not when you open it

Attached to Project: Arch Linux
Opened by Eugenia Loli-Queru (Eugenia) - Tuesday, 03 January 2006, 07:43 GMT
Last edited by Roman Kyrylych (Romashka) - Wednesday, 04 April 2007, 19:13 GMT
Task Type Bug Report
Category System
Status Closed
Assigned To Judd Vinet (judd)
Architecture not specified
Severity Medium
Priority Normal
Reported Version 0.7 Wombat
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I have the following /etc/acpi/actions/lid.sh which is called from /etc/acpi/events/lid.conf which tries to put the laptop to sleep (suspend to ram):


#!/bin/sh
# Acts on lid open/close events
# Load config
if [ -f /etc/acpi/actions/functions ]; then
. /etc/acpi/actions/functions
else
exit 1
fi

# Take action
if lid_open ; then
screen_power on
hdparm -a1024 -c3 -d1 -m16 /dev/hda
echo "Back from sleep at `date`"
##Restore the state of the Video
echo "* restore vbestate"
/bin/cat /etc/acpi/vbestate | /usr/sbin/vbetool vbestate restore
##Lets restore the clock
echo "* restore clock"
/sbin/hwclock --hctosys
##Lets get back to Xorg (Ctrl+Alt+1)
echo "* chvt 7"
/usr/bin/chvt 7

else # lid closed
if ! ac_online; then
screen_power off
fi

echo "Going to sleep at `date`"
##Let's go to Terminal 1 (Ctrl+Alt+1)
echo "* chvt 1"
/usr/bin/chvt 1
#Save Video State
echo "* save vbestate"
/usr/sbin/vbetool vbestate save > /etc/acpi/vbestate
echo "* writing to /sys"
hdparm -y /dev/hda
echo -n "mem" > /sys/power/state
fi

So, the problem is that the commands when you close the lid work, but when you open the lid the commands (at the beginning of the file) do NOT run. Why is that? It doesn't make any sense...
This task depends upon

Closed by  Aaron Griffin (phrakture)
Wednesday, 04 April 2007, 21:19 GMT
Reason for closing:  Not a bug
Comment by Judd Vinet (judd) - Monday, 13 February 2006, 04:40 GMT
I don't know if acpi will properly receive the lid-open event if it's just waking up from a sleep.

What I do is put all the commands into one script, the ones for going INTO sleep and then the ones for coming OUT OF sleep. Then you can bind this script to any acpi event you want: closing the lid, pressing the suspend button, pressing the power button, etc.

/etc/acpi/sleep.sh:

#!/bin/sh
# save system time
hwclock --systohc

# drop out of X, turn off the screen
chvt 1
radeontool light off

# go to sleep
echo -n mem >/sys/power/state

# turn the screen back on, head back into X
radeontool light on
chvt 7

# restore system time
hwclock --hctosys
Comment by Eugenia Loli-Queru (Eugenia) - Monday, 13 February 2006, 06:56 GMT
How do you bind it for closing and opening the lid exactly? That's one of the hard parts of the whole thing... :)
Comment by Judd Vinet (judd) - Tuesday, 14 February 2006, 17:55 GMT
I use the /etc/acpi/handler.sh to bind to events. When acpid is running, this script gets called for all events, and from there it decides what to do.

So for my laptop, I've used the "button/sleep" event. Whenever I push the Suspend button on my thinkpad (FN-F4, I think), the "button/sleep" event is triggered, which then calls the the sleep.sh script I posted above.

Here's the relevant excerpt from /etc/acpi/handler.sh:

case "$1" in
button/sleep)
case "$2" in
SLPB) /etc/acpi/sleep.sh ;;
*) logger "ACPI action undefined: $2" ;;
esac
;;
Comment by Judd Vinet (judd) - Tuesday, 14 February 2006, 17:56 GMT
To bind it to lid events, there is a "button/lid" event near the bottom of handler.sh.
Comment by Eugenia Loli-Queru (Eugenia) - Tuesday, 14 February 2006, 19:46 GMT
I tried it. It doesn't work with my laptop. Everything wakes up (cpu fan, hdd etc), except the video. It's all black.
Comment by hans (kryo) - Wednesday, 22 March 2006, 05:52 GMT
Hi!

Eugenia:
Can you please check if you have a LID0 in /proc/acpi/wakeup? I think you need to have LID0 to be able to wakeup your laptop with the lid switch.
Comment by Eugenia Loli-Queru (Eugenia) - Friday, 24 March 2006, 04:30 GMT
No, LID0 is not there. How do you make it to stick there (it goes away when you reboot), and what Sleep State should it be on?
Comment by hans (kryo) - Friday, 24 March 2006, 04:55 GMT
According to: http://rohanpm.net/blog/wake-up-go-back-to-sleep, sleep state 3 = suspend to ram, state 4 = suspend to disk

I would also like to know how to stick LID0 to the wakeup file. According to the blog, it requires hardware support.
Comment by Eugenia Loli-Queru (Eugenia) - Friday, 24 March 2006, 05:00 GMT
Well, if YellowTAB Zeta is able to wake up on this laptop, I certainly expect Linux to be able to. ;)
Comment by Roman Kyrylych (Romashka) - Wednesday, 04 April 2007, 19:01 GMT
http://gentoo-wiki.com/TIP_ACPI_basic_configuration#Lid
http://www.thinkwiki.org/wiki/How_to_configure_acpid
Comment by Roman Kyrylych (Romashka) - Wednesday, 04 April 2007, 19:13 GMT
reopened per this request:
Why did you close this bug? It IS a bug. Everything is setup correctly on my laptop but months later after I created this bug report, I found that the kernel needed a special parameter MANUALLY ENTERED before it would work. So, please reopen the bug and fix your kernel.
Comment by Aaron Griffin (phrakture) - Wednesday, 04 April 2007, 19:14 GMT
How is this an Arch bug?
Comment by Jason Chu (jason) - Wednesday, 04 April 2007, 19:15 GMT
what kernel parameter are we talking about here? Where's the information that should have been added to this bug?
Comment by Eugenia Loli-Queru (Eugenia) - Wednesday, 04 April 2007, 20:31 GMT
The kernel parameter is: acpi_sleep=s3_bios
Without it, my laptop does not wake up the ATi graphics card. And I don't care if it's the kernel's bug and not Arch's. I am not going to have 100 bugzilla accounts out there. It is YOUR job to make YOUR distro work. This is the job of a distro.
Comment by Jason Chu (jason) - Wednesday, 04 April 2007, 21:15 GMT
We would be very pleased if you would help us fix this problem by becoming the official Developer-In-Charge-Of-Crappy-ACPI. As your first order of business, I would suggest working very closely with the linux-acpi developers because even *they* can't get it to work for everyone.

It is our job to make a reasonable effort to make our distro work. It is not our job to perform miracles.

This is an upstream bug, known, and will be fixed by them. Unless there's anything else constructive to say on this topic, I'm inclined to close it.
Comment by Eugenia Loli-Queru (Eugenia) - Wednesday, 04 April 2007, 21:17 GMT
Here's a constructive comment: get kernel developers who know their sh*t to work on Arch Linux. Ubuntu is today respectable with over 30% of the linux market because they FIX bugs as they come in instead of simply marking them "upstream". It is the job of the distro to CONTRIBUTE in FIXING bugs, not merely FINDING bugs.

If your distro doesn't have competed kernel engineers who can actually fix bugs, that's your problem, not mine.

Loading...