Thinkpads Forum

Hello,

I have a problem with my T40 running Ubuntu Linux 6.10: Everytime I shut the lid and re-open it, my screen is all black and I cannot wake it up again. No mouse movement, no key pressing helps to get by laptop back to X. Switching to a virtual console doesn't work either, but I can log in remote using SSH and restart kdm which brings back the login screen, so it doesn't seem to fall into some kind of suspend or hibernation state.

First of all, I suspected ACPI to push in some events that would be the reason for this. So I disabled any action event from /etc/acpi/events/lidbtn but this didn't help -- neither did disabling ACPI and the boot prompt of GRUB (noacpi switch).

I took a look at the ACPI events being broadcasted during lid opening and closing using acpi_listen:
Also, I thought I could solve the riddle by setting enter suspend when lid is closed (or similar) to no suspend in the BIOS but again it didn't make a difference.

Can anybody help me out on this issue?


Thanks!

I used to have that same problem with older kernal 2.6.8.1 as there was a bug in it. But I cannot say why you are experiencing such problem with newer Ubuntu 6.10 Edgy Eft.

I am copying this info from another site and the sole credit goes to the person who posted this solution there my post ends here and his starts now:

Force Monitor Turn On When You Open the Lid

--------------------------------------------------------------------------------

Compatibility: I run Ubuntu 6.10 Edgy, but this howto is likely to work with any sane ACPI setup.

For the trivial fix, skip to the PROCEDURE section. If you want to understand what's going on, read on.

RATIONALE: If you run Ubuntu on a laptop, and your monitor turns off when you close the lid but doesn't turn back on when you open it, this is for you (skip to the next paragraph). If you have the opposite problem (viz. monitor fails to turn off on closed lid), a slight modification of the script might help you. If you don't have either problem, this guide still might be useful for you. It is likely that gnome-power-manager does the unblanking for you. If there is a problem with it, or if you happen not to be logged in, or if you're at a virtual terminal instead of in X when you open the lid, your monitor might fail to turn on. This howto makes the monitor always turn on when the lid opens, as long as the ACPI daemon is running (which, in general, it should be). No dependence on gnome-power-manager or any other tool.

BACKGROUND: First, we have to understand a little about what happens when the computer detects that the lid has been opened or closed. Basically, the configuration of the ACPI daemon tell is to execute the file /etc/acpi/lid.sh. This is a bash script that does the following, in order:
Executes the file /etc/acpi/local/lid.sh.pre if it exists and is executable.
Checks if a policy manager (that would be gnome-power-manager, or whatever the KDE tool is). If it detects one, it exits and goes no further.
Checks if the lid was opened or closed.
Takes the appropriate actions, depending on whether the lid was opened or closed.
Executes the file /etc/acpi/local/lid.sh.post if it exists and is executable.

PROBLEM: Ok, that sounds good. But there is a problem, at least for me, and apparently for many other Dell laptop owners, and maybe others. The problem is that in addition to this, something, I'm not sure what, always blanks the screen, even if the ACPI daemon is not running! But this something does not unblank the screen. So the screen is always guaranteed to be blanked, even if neither ACPI nor gnome-power-manager nor anything else tells it to blank, but it will not be unblanked unless it is explicitly instructed to. (And obviously, moving the mouse, typing, restarting X, etc. have no effect, or else it wouldn't be a problem.)

SOLUTION: So, the solution? If the screen always insists on blanking when it's closed, then we have to always insist that it unblanks when it opens. As you can see from the list above, the only place we can put something to always have it execute on lid open is in the file /etc/acpi/local/lid.sh.pre. After that, if gnome-power-manager is running, the script will exit, so things after that are not guaranteed to always run. So...

PROCEDURE:
Install vbetool:

Code:
sudo apt-get install vbetool # should already be installed, but just in case

Make the script:

Code:
sudo mkdir -p /etc/acpi/local/
sudo gedit /etc/acpi/local/lid.sh.pre

Put this in /etc/acpi/local/lid.sh.pre:

Code:
#!/bin/sh
grep -q open /proc/acpi/button/lid/*/state
if [ $? = 0 ]
then
# lid is open; turn the screen on
vbetool dpms on
fi

If you have the opposite problem, put this in /etc/acpi/local/lid.sh.pre:
Note, I haven't tested this, since I don't have this problem. The only difference is the else clause, though.

Code:
#!/bin/sh
# always turn on screen on open lid, regardless of policy or anything
grep -q open /proc/acpi/button/lid/*/state
if [ $? = 0 ]
then
# lid is open; turn the screen on
vbetool dpms on
else
# lid is closed; turn the screen off
vbetool dpms off
fi


And finally, make it executable:

Code:
sudo chmod +x /etc/acpi/local/lid.sh.pre

And that should do it. Whether your're logged in, logged out, on a console, whetever, as long as the ACPI daemon is running, the screen should turn on when the lid opens.

TROUBLESHOOTING: I learned all of this by logging into my laptop from another computer via ssh and watching various logfiles, trying various commands, etc. This was very helpful, as I didn't have to deal with the laptop's own monitor deactivating. If you have ssh set up, using it like this is very useful for sorting out all manner of power-management issues. Running "vbetool dpms [on/off]" over ssh should work, so this also gives you a way to manually unblank the monitor if it gets stuck blank.

Thanks for the quote, ryengineer.

Unfortunately, it didn't solve my problem. Neither does calling vbetool directly over ssh.

Could you post the original link please? I'd like to look for follow-up posts (maybe the solution didn't help someone else either).



EDIT: did you get it from here?

Yes I took the article from there. I also suggest you post this issue over ubuntu forum.

As I said I used to have same problem in 2004 with ubuntu's 2.6.81 kernal but that was just due to a bug. Reverting back to previous version of available kernal at that time solved my issue. I am looking for a solution for you, when I come up with something I'll post again.

P.S. Can you please post which graphics card do you have on your T40?

I just found a fix to my problem: This is one of the situations where fixing an issue is way easier than finding the solution.

By doing some more googling I found this forum posting (complete thread) which suggests to switch to virtual terminal 1 prior to using vbetool and later return to X by another call to chvt.

What I needed to do was just switch to VT1 and then back to VT7. Note that I did not need to call vbetool at all.

So for everyone else with the identical problem: Add this to /etc/acpi/local/lid.sh.pre (create the directory if non-existant; /etc/acpi/lid.sh parses for the file by default):

And for the sake of completeness: My T40 comes with a Radeon Mobility 7500 (M7) graphic adapter which is run by Xorg's ati driver (no need to run fglrx as it doesn't support this chipset).

I am glad things worked out.