Getting Suspend and Hibernate to work with compiz fusion and the NVIDIA binary driver on a Dell E1505N

I spent several hours hacking this today, and I finally have a surefire (if somewhat hacky) way of getting suspend and resume to work on my Inspiron E1505N.

Because of a bug in the NVIDIA Binary (which supposedly is going to be fixed this september), compiz-fusion crashes pretty much everything on resume.

First: So the first thing you’ll need to do is update your /etx/X11/xorg.conf and add an

“Option “NvAGP” “1″ line in the “Section “Device”"“

Section "Device"          ...          Option           "NvAGP"          "1" EndSection...

Second: Disable warm-booting and vbe post/save options on resume by editing your /etc/default/acpi-support:

...

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

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

...

Third: Create a file called 25-compiz-kill.sh in your /etc/acpi/resume.d/ After creating it, type in terminal: sudo chmod 711 /etc/acpi/resume.d/25-compiz-kill.sh

#!/bin/bash#/etc/acpi/resume.d/25-compiz-kill.shkillalll compiz.real

Fourth: Create a file in /etc/acpi/resume.d called 99-compiz-resume.sh
            Then type: sudo chmod 711 99-compiz-resume.sh

Edit this file to have the following

#!/bin/bash#/etc/acpi/resume.d/99-compiz-resume.sh

export DISPLAY=:0.0sudo -H -b -u your_user_id compiz --replace &

And lastly, go into compiz-config settings, under General Options, and Display settings, and uncheck v-sync to blank.

And that’s it =) Now it’s important to note that this only works for 1 user. Which is generally fine for a laptop, I wasn’t able to get it to work with the $USER wildcard. If anyone has improvements to this, please let me know. I’m not very good at scripting so there’s obviously a better solution, but this is a very very simple and direct way to do it, so if your more advanced scripts fail, this is pretty much guaranteed to work.

Edit: Thanks to Andy in comments.

Bashisms and a call for a new posix standard

##EDIT##
A friend of mine just advised me of the folly of this, so I retract it. Essentially it seems that *Linux* is the culprit, that when bash is invoked as /bin/sh it should not allow non-posix compliant commands, but does.
##/EDIT##

The prevalence of bash shows that mere codification of an open standard does not in itself mean that anyone will actually follow it, and in fact this might be particularly apt when it comes to open source.

While bash of course does have a posix mode, since bash is so common as the default shell, its very uncommon to use it, and its very common to use bashisms (That is, bash specific behavior that does not conform to POSIX sh). The segue in Ubuntu from bash to dash, and the numerous broken scripts that ensued is a bit of a testament to this.

In open source in particular, because the code is available, often the superior choice is readily apparent, whatever the standard might be. This can actually provide a wide impetus for open source coders to move away from the standard because of it, creating a new de-facto standard. While with a proprietary de-facto standard there is more impetus to move toward an open standard because of the unavailability of the code, and inability to make easy (or easier) transitions from one implementation to the next.

With specific regards to the shell, the particular problem with it is the ambiguity as to what /bin/sh really means. And the unique solution actually does rely in having an open standards: create a new POSIX standard to remove the ambiguity of /bin/sh.

We allready have the Shebang, and the fairly common editor encoding line afterwards which is frequently implemented in more and more editors.

Why not create a new comment line which simply defines what /bin/sh means in the context of the script? The shell can read that line before executing the script and simulate or redirect the script to that environment. Therefore, all that would be required to transition your scripts to a new default shell is to add the comment line to the script? Versions of a particular shell that predate this implementation would simply ignore it as a comment, and you could hack the script as is done now. However it certainly makes your scripts more portable among different distros which use different default environments to have this behavior.

So that is, in short, my call for a new posix standard for shell environments.