lid.sh should use vbetool instead of xset

There are various systems that break if DPMS calls are made directly. I'll look
into whether or not this is preferable to going via X - it's not going to happen
for Breezy, though.

Is this still an issue for you?
Does "xset dpms force off" work as well as "vbetool dpms off" now with Hardy for you?

I'm no longer using any of the systems involved with this old bug report, I think we can assume the issue is fixed in Hardy for now. I'll reopen if I see this behavior again.

Thanks, Daniel.

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New".

OP implied we should close the bug as well.

Thanks again!

I'm running Hardy on a Dell Inspiron 8100 and still experiencing this issue. Judging by many the many similar reports from others, it also seems to affect many other Dell laptops, but I can't say for certain as I personally have never owned any other Dells.

The solution for me was to follow the advice given here:
http://ubuntuforums.org/showthread.php?t=358432

Please note that there he mentions a different place to place the command "vbetool dpms off" because even if gnome-power-manager is set to "Do Nothing" on lid events, /etc/acpi/lid.sh never gets past the following policy check:

if [ `CheckPolicy` == 0 ]; then exit; fi

Therefore the original suggestion of placing it in the else clause outside the for loop no longer works. However, the whole making-another-file funny business can be avoided by simply placing

grep -q open /proc/acpi/button/lid/*/state
if [ $? = 0 ]
then
    vbetool dpms on
fi

before the policy check.

Also, it seems that it is not necessary to place "vbetool dpms off" anywhere, as for some reason, Dell laptops turn off their screens unconditionally whenever the lid is closed. I have no idea why; the poster in the forum thread I linked to thinks it is a hardware or BIOS soft of deal.

Finally, these bugs seem related:
https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/67231
https://bugs.launchpad.net/ubuntu/+source/acpi/+bug/49521
https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/44393