[HOWTO] Run scripts for laptop lid open/close and dock/undock events

[lunatico]

What this little tutorial shows is:
1. How to catch the lid open and close events.
2. How to catch the laptop dock and undock events.
3. How to run a script for each of those events.

I will show a specific example which consist in:
- When the lid closes -> play a "closing" sound and set my Pidgin status to away with a message saying "My laptop lid is closed..."
- When the lid is opened -> play an "opening" sound and set my Pidgin status to available with a message saying "I am here..."
- When I undock my laptop from the docking station -> play a "undock" sound
- When I dock my laptop into the docking station -> play a "docked" sound

NOTES:
- This was tested on a Lenovo Thinkpad T61 and a T61p both running Ubuntu 8.10. Things might slightly change depending on the laptop or linux distribution. But the main idea will be the same. This tutorial is just to point people towards the right solution.
- 20/07/09: I just tested this on a T61p with Ubuntu 9.04 and it work fine, there is one minor thing to look, stated below.
- Make sure throughout the tutorial you change your_user with your actual user on the scripts and also feel free to save scripts on different paths updating the paths on the scripts of course.
- ***I am not responsible if you mess things up, please be careful!***

It is important to understand that these events will be catched by processes owned by root. So we need to do a little hack so that root can run commands on our user's X environment. Many thanks to Earl Ruby for pointing me on how to do this http://earlruby.org/2008/08/update-pidgin-status-using-cron/

In order to make the environment variables available for root:

gedit ~/export_x_info

and paste the following in:

#!/bin/bash
# Export the dbus session address on startup so it can be used by any other environment
sleep 5
touch $HOME/.Xdbus
chmod 600 $HOME/.Xdbus
env | grep DBUS_SESSION_BUS_ADDRESS > $HOME/.Xdbus
echo 'export DBUS_SESSION_BUS_ADDRESS' >> $HOME/.Xdbus
# Export XAUTHORITY value on startup so it can be used by cron
env | grep XAUTHORITY >> $HOME/.Xdbus
echo 'export XAUTHORITY' >> $HOME/.Xdbus

Save and close. Then make it executable:

chmod 700 ~/export_x_info

Now put it on your startup scripts. System -> Preferences -> Sessions and click Add.

Name: X Environment Variables
Command: /home/your_user/export_x_info

Click Add and close.

This will execute every time you start your computer and the call to source ~/.Xdbus loads the DBUS_SESSION_BUS_ADDRESS and XAUTHORITY environment variables before executing the purple-remote command for Pidgin.

Ubuntu makes it easy to catch the laptop lid open and close events. There is a file /etc/acpi/lid.sh which runs every time your lid open or closes. So run:

gksudo gedit /etc/acpi/lid.sh

and right after line #!/bin/bash paste /home/your_user/lid_event

Save and close.

Now create the file that will call different scripts according to open or close events.

gedit ~/lid_event

and paste the following into the file:

#!/bin/bash
grep -q closed /proc/acpi/button/lid/LID/state
if [ $? = 0 ]
then
/home/your_user/close;
else
/home/your_user/open;
fi

Save and close and make it executable.

chmod +x ~/lid_event

And finally lets create the files open and close.

gedit ~/open

and paste the following into the file:

#!/bin/bash
#This runs so that root can run the following command under the user's environment
source /home/your_user/.Xdbus
#play a open sound
DISPLAY=:0.0 su your_user -c "aplay /usr/lib/openoffice/basis3.0/share/gallery/sounds/sparcle.wav"
#change Pidgin status
DISPLAY=:0.0 su your_user -c "purple-remote 'setstatus?status=available&message=I am here...'"

Save and close. Make it executable:

chmod +x ~/open

Now the close file:

gedit ~/close

and paste the following into the file:

#!/bin/bash
#This runs so that root can run the following command under the user's environment
source /home/your_user/.Xdbus
#play a close sound
DISPLAY=:0.0 su your_user -c "aplay /usr/lib/openoffice/basis3.0/share/gallery/sounds/falling.wav"
#change Pidgin status
DISPLAY=:0.0 su your_user -c "purple-remote 'setstatus?status=away&message=My laptop lid is closed...'"

Save and close. Make it executable:

chmod +x ~/close

Now you need to restart ACPI. Run:

sudo /etc/init.d/acpid restart

Now you can test that it works by opening and closing your laptop lid.
Notes:
- Make sure that the gnome power management option for laptop lid closed is set to do nothing.
- The sounds used are from OpenOffice 3.0, the path changes for previous versions.
- Make sure you have libpurple-bin installed -- sudo apt-get install libpurple-bin

Now lets catch the docking event. Thanks to Steven King on pointing me how to go about this http://www.nabble.com/How-does-a-uevent-work-for-dock-undock-on-thinkpads--tt21898641.html#a21898641
This is done by using a udev event.

gksudo gedit /etc/udev/rules.d/80-thinkpad-T61.rules

and paste the following:

KERNEL=="dock.0", ATTR{docked}=="1", RUN+="/etc/thinkpad/dock.sh 1"
KERNEL=="dock.0", ATTR{docked}=="0", RUN+="/etc/thinkpad/dock.sh 0"

Save and close.

sudo mkdir /etc/thinkpad

gksudo gedit /etc/thinkpad/dock.sh

and paste the following:

#!/bin/sh
# wait for the dock state to change
sleep 1
DOCKED=$(cat /sys/devices/platform/dock.0/docked)
case "$DOCKED" in
"0")
#undocked event
/home/your_user/undocked
;;
"1")
#docked event
/home/your_user/docked
;;
esac
exit 0

Save and close. Make it executable:

sudo chmod -x /etc/thinkpad/dock.sh

NOTE: For some reason on Ubuntu 9.04 the above command will not work, the file will not be made executable. The workaround is to become root and execute the chmod command.

Now lets create the undocked file:

gedit ~/undocked

and paste the following:

#!/bin/bash
#This runs so that root can run the following command under the user's environment
source /home/your_user/.Xdbus
#play a sound
DISPLAY=:0.0 su your_user -c "aplay /usr/lib/openoffice/basis3.0/share/gallery/sounds/falling.wav"

Save and close. Make it executable:

chmod +x ~/undocked

then the docked file:

gedit ~/docked

and paste the following:

#!/bin/bash
#This runs so that root can run the following command under the user's environment
source /home/your_user/.Xdbus
#play a sound
DISPLAY=:0.0 su your_user -c "aplay /usr/lib/openoffice/basis3.0/share/gallery/sounds/sparcle.wav"

Save and close. Make it executable:

chmod +x ~/docked

Now finally we need to restart hal:

sudo /etc/init.d/hal restart

That's it, you should be able to dock and undock and hear a sound each time you do. From here the options for you are endless, you can basically do anything you want.

:D

[e64462]

Hey, thanks for the guide, honestly i think this is what i was looking for, it just didnt work for me.

A brief outline of my problem...

i have a thinkpad x61 tablet who's screen i would like to rotate when i rotate my lid. I have a button on my laptop screen that executes a program I wrote to rotate the screen. If i rotate the screen using this method, all is fine... its just inconvenient... I'd like acpi to do it for me....

I used acpi_listen to find the rotate event, created a file in /etc/acpi/events/ called "ibm-clockwise.sh". Then I made this file executable and had it call a script in /etc/acpi called "ibm-clockwise". This file is also executable. If i just put "rotate" (the name of my program) in "ibm-clockwise", compiz crashes on rotation.

So I did some testing and found that when I execute rotate as root, the same behavior is observed, i assume this is the problem, since the scripts in /etc/acpi are executed as root.

I screwed around with "su nick -c rotate" for a while, both while logged in as root, using "sudo su", and placing this command in the /etc/acpi/ibm-clockwise file. That was fun, all time wasting aside.

Everytime compiz crashes, I lose half of my workspaces... All of my special keys are unbound, and obviously desktop effects are gone... I have to go to the fusion-icon and do "reload window manager" ...

it seems this problem could be fixed by having acpi execute rotate as my user (nick). This brings me to your guide.

I followed parts of it, but i didnt really want my home directory cluttered with a bunch of scripts.

I created ~/export_x_info and pasted your info in directly. Then i made it executable. I also added it to my startup using your method, but I didnt feel like restarting for it to take effect, so i executed it with a ./export_x_info ...

I skipped all the linking and just went directly to pasting the source ~/.Xdbus stuff into the action script since i only need it to do one thing... my /etc/acpi/ibm-clockwise file looks like

#!/bin/bash
source /home/nick/.Xdbus
DISPLAY=:0.0 su nick -c "rotate"

Though im not even sure if the "DISPLAY=:0.0" is necessary, i tried removing it and things still didnt work.

i restarted acpi and tested, and compiz still crashes, i assume because the file is still not being executed as my user (nick).

Any help would be so great, i appreciate it...

[lunatico]

Any help would be so great, i appreciate it...

Right... let's see what we can do.

First, for troubleshooting purposes I recommend running stuff yourself as root. This way you will determine when, where and why it is not working. The idea is something like:

"su -" and:

env | grep DBUS_SESSION_BUS_ADDRESS
env | grep XAUTHORITY

Probably this didn't returned anything. That's fine. If you run your "rotate" script now it will most likely crash as you described. Try and see. You probably will see where it is failing.

Now:

source /home/daniel/.Xdbus

And again:

env | grep DBUS_SESSION_BUS_ADDRESS
env | grep XAUTHORITY

This time you should get your session's values. So now you should be able to start running stuff from root as your user on your current session.
What I suspect is happening is that there is a lot of stuff inside your rotate script that is still just been run as root. See, what happens is that when you do "source /home/nick/.Xdbus" the env variables are been imported just to that environment, if you run a script from there you are creating a new bash environment just for that script.
You should call "source /home/nick/.Xdbus" again within your rotate script and stuff that you do there that uses your session's env variables should be run as DISPLAY=:0.0 su nick -c "etc....."
Do you see my point?

I hope this helps.... let me know how you get on.

[e64462]

hey, thanks for the reply!

so im not sure i fully understand what's happening... do you want me to run

env | grep DBUS_SESSION_BUS_ADDRESS
env | grep XAUTHORITY

as root? like.. type "sudo su" and then enter those?

When I do that, i get

nick@notebook:~$ sudo su
root@notebook:/home/nick# cd
root@notebook:~# env | grep DBUS_SESSION_BUS_ADDRESS
root@notebook:~# env | grep XAUTHORITY
XAUTHORITY=/home/nick/.Xauthority

Then i source /home/nick/.Xdbus and rerun those env commands

root@notebook:~# source /home/nick/.Xdbus
root@notebook:~# env | grep DBUS_SESSION_BUS_ADDRESS
root@notebook:~# env | grep XAUTHORITY
XAUTHORITY=/home/nick/.Xauthority

the output is the same both times, the first returns nothing, the second returns ~/.Xauthority

I tried rotating the screen before and after both of those blocks... compiz crashed all 4 times... the output of my rotate program was pretty much the same in each case... the only instruction that really returns anything is the

system("compiz --replace");

which returns

nick@notebook:~$ sudo rotate
Checking for Xgl: not present.
Detected PCI ID for VGA:
Checking for texture_from_pixmap: not present.
Trying again with indirect rendering:
Checking for texture_from_pixmap: present.
Checking for non power of two support: present.
Checking for Composite extension: present.
Comparing resolution (1024x768) to maximum 3D texture size (2048): Passed.
Checking for Software Rasterizer: Not present.
Checking for nVidia: not present.
Checking for FBConfig: present.
Checking for Xgl: not present.
/usr/bin/compiz.real (video) - Warn: No 8 bit GLX pixmap format, disabling YV12 image format

I dont see too much of interest there...

In regards to your final comment about adding

source /home/nick/.Xdbus

to my rotate program and then executing anything that uses the env variables using su nick -c <do-stuff> ... I don't know which statements pertain to the env variables... how do i identify them (im lost needless to say)

[e64462]

hmm... perhaps you should mostly ignore my last post. I did some searching in hopes of gaining a better understanding of what your scripts were doing.

Playing with the sample export_x_info file you provided, i realized that it wasn't placing the output of

env | grep DBUS_SESSION_BUS_ADDRESS

in /home/nick/.Xdbus

is the line in your sample file supposed to read:

env | grep DBUS_SESSION_BUS_ADDRESS >> $HOME/.Xdbus

i made that correction, then did


nick@notebook:~$ rm -f .Xdbus
nick@notebook:~$ ./export_x_info
nick@notebook:~$ cat .Xdbus

DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-YX3A7vUW9N,guid=b59d1b4c84bf031c1e65c1a549aecaa7
export DBUS_SESSION_BUS_ADDRESS
XAUTHORITY=/home/nick/.Xauthority
export XAUTHORITY



then logged in as root using "sudo su"


root@notebook:~# env | grep DBUS_SESSION_BUS_ADDRESS
root@notebook:~# env | grep XAUTHORITY
XAUTHORITY=/home/nick/.Xauthority


DBUS_SESSION_BUS_ADDRESS is still empty anyways... so i:


root@notebook:~# source /home/nick/.Xdbus
root@notebook:~# env | grep DBUS_SESSION_BUS_ADDRESS
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-YX3A7vUW9N,guid=b59d1b4c84bf031c1e65c1a549aecaa7
root@notebook:~# env | grep XAUTHORITY
XAUTHORITY=/home/nick/.Xauthority


which i think is what you expected...

at this point i think I've narrowed down the segment of code in my program that is causing all the problems. when i comment out this line, the screen rotates just fine, but the keys that i need reassigned after rotation aren't recognized (which is why it's there). But this is the troublesome line.

system(compiz --replace);

So i need to somehow give root the ability to restart compiz... playing with this idea, i started issuing compiz --replace every odd way i could think of (after assigning the environment variables) which didnt work =(

any ideas?

[lunatico]

then logged in as root using "sudo su"

Well, first thing is just to say that "sudo su" it's not the same as "su -". They both make you root alright but with the first you are still on your user's home directory, whereas the second makes you root and places you on root's home directory. That's why you are getting something for your xauthority value but not for your bdus session value.
When running scripts as root it is on root's home directory. So if you just call your "rotate" script root is not even able to find it. Probably the first problem you have in the line. You should use the full path of your script.

But this is the troublesome line.

system(compiz --replace);
any ideas?

It sure is a troublesome line. I just tried
DISPLAY=:0.0 su user -c "compiz --replace"
And it crashed....
Compiz is a very complicated piece... you may want to ask on their forums to see what you need to do to restart it as root but for your users session. Sorry I can't be of more help.

[e64462]

its all good... stupid compiz... thanks for the help though! atleast i learned something!

[lunatico]

stupid compiz...

I agree! But we can't live without it can we? It's so beautiful...
Anyway, I hope you sort this out, post back if you do.
Cheers!

[binbash]

Good howto, i will try this in an hour ;)

[DougEdey]

Firstly, let me say a big thankyou for this! It makes my life far easier at work when moving between my desk and our test floor.

I was wondering if there's some way to link this into emesene (or amsn) to change my status? emesene has a dbus plugin so i thought it should be ok!

[lunatico]

Firstly, let me say a big thankyou for this! It makes my life far easier at work when moving between my desk and our test floor.

Your welcome. Sound like we have similar jobs... ;)

I was wondering if there's some way to link this into emesene (or amsn) to change my status? emesene has a dbus plugin so i thought it should be ok!

To be honest I have never used amsn, but if you say it has a dbus interface then you should be fine. May be the same rules for running stuff as root or as the user would apply but it's a matter of figuring out what the commands are and how they work.

[DougEdey]

To be honest I have never used amsn, but if you say it has a dbus interface then you should be fine. May be the same rules for running stuff as root or as the user would apply but it's a matter of figuring out what the commands are and how they work.

The problem is that I can't find anywhere that documents the DBUS interface :(

[lunatico]

The problem is that I can't find anywhere that documents the DBUS interface :(

Same happened to me with Pidgin so I joined their mailing list and started asking questions until a developer gave me the answers. Try that.

[BoBaH32]

Awesome howto, thank you! I'll try it on my dell laptop.

[nhmtnbkr]

Hey, thanks for the tutorial. I implemented it and it worked just fine ... until I went to log out.

When I shut down, the computer went through it's normal shutdown screens, the screen went blank, then stayed power up. I waited 5 mins and nothing. I had to hold down the power button for seven seconds to turn it all the way off. Then the next time I went to power up and log in, instead of the normal 30-45 seconds or so that it takes to get to the login screen, it took over 5 minutes. Once in, I did a little poking around in the forums about these problems, starting with the shutdown problem. I found this thread:

http://ubuntuforums.org/showthread.php?t=1198992

Talking about udev events and such, and I remembered going through your tutorial and entering the 80-thinkpad-T61.rules file. As an experiment, I moved the file out of /etc/udev/rules.d up one level, and what do you know, shutdown and power were back to normal. I repeated several times and sure enough, everything is fine and repeatable now.

So, my question is, what is magical about this file that is causing my powerup/shutdown issues. Looking at the README in /etc/udev/rules.d, there is something about that number at the beginning of the file name, but by their description, 80 seems fine.

Any ideas or tips you can offer?

Thanks,
Jim

[lunatico]

So, my question is, what is magical about this file that is causing my powerup/shutdown issues. Looking at the README in /etc/udev/rules.d, there is something about that number at the beginning of the file name, but by their description, 80 seems fine.

Any ideas or tips you can offer?


Well as you could see 80 should be fine, the definition says:

80 rules that run programs (but do not load modules)

But I have just checked on the computer I am at the moment (Thinkpad T61) and I have it down as /etc/udev/rules.d/60-thinkpad-T61.rules

I can't remember from when I wrote the tutorial if the 80 was a mistake or what, but again, from that README file 80 seems ok.

I'm assuming you are doing this on a Thinkpad right... not too sure what the behavior would be on other hardware.

Hope this helps, sorry I don't have a more specific answer...

[nhmtnbkr]

Hey there, I'm running this on a T61p. I just changed the file name from an 80 to a 60 and the results are the same, slow boots and incomplete shutdowns.

I'll do some research and if I find a solution, I'll post it here on the thread.

Thanks for our help.

[lunatico]

I'll do some research and if I find a solution, I'll post it here on the thread.


Me too! Lets make this a contest, the one who finds the solution first wins!!! HAHA

Anyway, I just tried this on a T61p and same story... :( So something changed from Ubuntu 8.10 to 9.04 because it was working fine on the T61p on 8.10.

Do not despair, we shall fix this!

[nhmtnbkr]

Well, I've played around with this a little bit. I turned off the splash screen during bootup so I could see where things get hung up. I booted into 3 different kernels from grub:

2.6.28-15 (default)
2.6.28-14
2.6.27-11

For all three, the boot hung for several minutes at the following lines:

[26.xxxxxx] IBM TrackPoint firmware: 0x0e, buttons: 3/3
[26.xxxxxx] input: TPPS/2 IBM TrackPoint as /devices/platform/i8042/serio1/serio2/input/input12

Without the 80- (or 60-) rule file in place in /etc/udev/rules.d, the boot up sequence moves through this step with no problem.

That's as much as I've had time to do, just putting it out there to see if it sparks any ideas.

[lunatico]

Found the solution to the startup delay! :P

Delete the file 80-thinkpad-T61.rules by:

sudo rm /etc/udev/rules.d/80-thinkpad-T61.rules

And instead of that we will catch the dock/undock with the following udev rule by:

gksudo gedit /lib/udev/rules.d/85-thinkpad-T61.rules

And paste the following:

KERNEL=="dock.0", ACTION=="change", RUN+="/etc/thinkpad/dock.sh"

The rest should be the same as we are still calling the dock.sh script.

Restart hal to immediately see the changes.

[nhmtnbkr]

Thanks man, that worked perfectly!

A couple of things. First, would you mind shooting me an explanation as to why this works and the previous incarnation did not (or was slow).

Second, I've run into another problem. Just curious, but while you're docked, do you have an external monitor setup? If so, is it configured in Xinerama mode? I just set this up, and when I do lid open/close or dock/undock, my computer locks up tight. No access whatsoever. I have to hold down the power button for 7 secs to turn it off then power on. Just for grins, I went back and tried it with the old rule (80-...) and it did the same thing. I've done a cursory search and it seems folks run some scripts to change enabled screens, etc. when docking and undocking, I was just wondering if you've run into this before I dive deeper.

Thanks again.

[lunatico]

Thanks man, that worked perfectly!

You're very welcome.

... First, would you mind shooting me an explanation as to why this works and the previous incarnation did not (or was slow)...

Don't you think I did it by myself, I had some help. Have a look at this thread. (http://www.nabble.com/A-new-udev-rule-gives-me-3min-startup-delay-tt25131831.html)

That lead me to read more about how udev works and stuff.

You should join that mailing list, people is very helpful and they know a lot.

... I've run into another problem. Just curious, but while you're docked, do you have an external monitor setup? If so, is it configured in Xinerama mode? ....

I do have an external monitor...

Not familiar with xinerama sorry... My video card is an Nvidia, and the way I have it configured is that my external monitor is a clone of my laptop screen, and for the lid event I have it to do nothing from Power Management options. I use clone and not extended desktop because I already have 4 workspaces which is virtually 4 desktops.

Wish I could help more....

[SlickRick]

I'm trying to make sounds play when opening/closing and i can't get this to work. I've tried this guide as well as http://ubuntuforums.org/showthread.php?t=563687
are there some commands that can detect problems?
i tried running cat /proc/acpi/button/lid/LID/state and it detects the lid state as open.

[lunatico]

are there some commands that can detect problems?

Well the easiest way is to try each part separately. You can also put some output with echo on your scripts so that when you run them you can see where they are failing. Are you getting errors?

If you run your ~/open and ~/close scripts do they work?
If yes, then is your ~/lid_event script running properly and calling them?

[SlickRick]

I tried running each script separately and I always get the sound playing with no errors, although I do have to put my password in to run them.
I tried echo after each line in the scripts and it seems the lid_event script is wrong since it made the closing sound play when I ran it

[lunatico]

I tried running each script separately and I always get the sound playing with no errors, although I do have to put my password in to run them.
Yes because they are meant to be run by root. The lid events are generated by kernel event owned by root. Try running them as root and they should work fine without even asking for password.

I tried echo after each line in the scripts and it seems the lid_event script is wrong since it made the closing sound play when I ran it[/QUOTE]

Mmm what hardware are you on?

[SlickRick]

Still get asked the password if i run them as root and still the lid gets detected as closed

I've got a Toshiba satellite L300-18E
Here are the full specs (http://uk.computers.toshiba-europe.com/innovation/jsp/SUPPORTSECTION/discontinuedProductPage.do?service=UK&toshibaShop=false&com.broadvision.session.new=Yes&PRODUCT_ID=1056299)

[lunatico]

I've got a Toshiba satellite L300-18E

This was written for Thinkpads (T61 and T61p)...
You will have to find out what's going under the hood on your toshiba, I don't have one, sorry I can't help you.

[SlickRick]

maybe theres a way i can periodically run cat /proc/acpi/button/lid/LID/state and then open and close the lid and see if the computer is detecting the change?
also, what do you mean 'find out what's going under the hood on your toshiba'? I posted a link to my specs if that's what you mean, although I hardly see how my hardware would make any difference.

btw, BUMP

[lunatico]

also, what do you mean 'find out what's going under the hood on your toshiba'?
Hardware and hardware events are exposed to the OS in many different ways...

I posted a link to my specs if that's what you mean,
Well but that's something you'll have to do by yourself. I don't have such hardware to test on... nor the time.

although I hardly see how my hardware would make any difference.
It will be different. When you install an OS it is installed to match your hardware, the best way possible...


Are you sure you have the /etc/acpi/lid.sh script? Was it there already? Is it running each time you open and close your lid?

Try:

touch test

gksudo gedit /etc/acpi/lid.sh

and right after line #!/bin/bash put this

echo 1 >> test

Save and close.

Open and close your lid, for each time you do it it should be adding a 1 to the test file. If 1s are been added then you did something wrong when following the steps in this tutorial, if not then Ubuntu uses a different way to capture your lid event.

[SlickRick]

the test file just remains blank
If alter the permissions for the lid.sh file to not allow it to run, the screen is still blanked which leads me to believe that closing the screen doesn't run the lid.sh file, like you said. However, it was there, I didn't just create it myself.

I've managed to make my laptop play a sound when I click the power button by editing the powerbtn.sh file in the same folder as lid.sh