I had the same problems with an Acer Aspire 5336, and the above solution mostly worked for me.
At first, I thought this was a driver (Nvidia or Intel) problem, and did not even know about backlights or that they could be turned off...
I agree with glococo that 'nomodeset' was not a good solution - I found that the screen resolution was well off, impossible to put right, and rendered many programs unusable.
Putting "setpci -s 00:02.0 F4.B-0" in rc.local got the backlight on at boot, but whenever the screen shut off after inactivity, I had to enter the code in a terminal again - in the dark, reading the screen with a torch.
My workaround was to create the following bashcript:
I then created a keyboard shortcut for the file (I did this in Fluxbox).
sudo setpci -s 00:02.0 F4.B-0
However, the script has to be run as root (or sudo), so I then had to edit the sudoers file (/etc/sudoers), using 'sudo visudo' (this is the ONLY way you should edit the file).
Under the part that reads "# Allow member of the group sudo to execute any command", I added this line:
Replace '%usergroup' with your own group name.
%usergroup ALL=(ALL) NOPASSWD: ALL
The only problem with this is that now all member of the group are able to execute ALL sudo commands without entering a password. Not a problem for me, as I'm the only one using the laptop, but it can cause problems with other programs that need/use sudo or gksudo.
Supposedly, I should have been able to put the line
into 'sudoers', but it just wouldn't work for me - sudeors would not accept it, no matter how I changed the syntax.
%username ALL=(ALL) NOPASSWD: /path/to/bashscript/
Be VERY careful when editing sudoers - any mistakes will mean you can't use sudo AT ALL unless you log into a recovery session as root and edit the file through nano or vi... I found, while making sure sudoers worked, that it was best to have a file manager (Thunar, in my case) open with gksudo - that way, I was able to go back to /etc/sudoers and return it to its normal state.
To check if the sudoers file is OK, just run 'sudo visudo', which will either return an error or allow you to edit the file (which means everything is OK). If all you get is an error, then, if you are already logged into a file manager as root/sudo or have the file open in a text editor as root/sudo, then you need to put it back to how it was.
I hope this helps someone - it is an annoying workaround for a ridiculously irritating problem. I suspect it is something in the latest kernel, as it's never happened before. Hope this helps someone else, and I hope this gets fixed in the next kernel!