LCD stays off on lid open

[Moshe Jacobson]

For maybe around a week now, my laptop's does not turn back on when I open
the lid.  I can be logged in or at the gdm screen, but closing the laptop
lid permanently blanks my screen.  I have set all my gnome-power-manager
options never to shut off the screen or perform any action on a lid close.

I have a Dell Latitude D610 with an Intel 915GM/GMS/910GML (according to
lspci), which uses the i810 video driver.

FWIW, using the xset dpms force off does blank the screen, but it
successfully turns back on when I move the mouse.

Any ideas?

Thanks,
Moshe

[e-mail] wrote on 11/26/2006 11:11:26 PM:
> For maybe around a week now, my laptop's does not turn back on when
> I open the lid.  I can be logged in or at the gdm screen, but
> closing the laptop lid permanently blanks my screen.  I have set all
> my gnome-power-manager options never to shut off the screen or
> perform any action on a lid close.
>
> I have a Dell Latitude D610 with an Intel 915GM/GMS/910GML
> (according to lspci), which uses the i810 video driver.
>
> FWIW, using the xset dpms force off does blank the screen, but it
> successfully turns back on when I move the mouse.
>
> Any ideas?

Yes.  I think I have the same issue with my Dell Inspiron 6400 (aka 1505?)
I googled the world and found someone (at U of T) with a solution that
worked for me. (sorry, I can't rememeber the url and I didn'w write it
down, but here it is from my notes:

a) you need an ACPI events file to capture the lidswitch activity,
 b) a script to run when triggered to turn the light back on.

(Don't forget to mark lidswitch.sh as executable.)

1/ Add the file:  /etc/acpi/events/lidswitch

# /etc/acpi/events/lidswitch
# This is called when the lid is closed or opened and calls
# /etc/acpi/lidswitch.sh for further processing.

event=button[ /]lid
action=/etc/acpi/lidswitch.sh

2/ Add the file /etc/acpi/lidswitch.sh

#!/bin/sh
# /etc/acpi/lidswitch.sh
# Re-activates the screen when the lid is opened again

LID_STATE="/proc/acpi/button/lid/LID/state"
LCD_STATE="/proc/acpi/video/VID/LCD/state"
VT_NR=/tmp/lid_sh

if [ -e /tmp/acpi_sleep ]; then
      rm /tmp/acpi_sleep
      exit
fi

grep -q open "$LID_STATE"
if [ $? -eq 0 ]; then               # open the lid
      vbetool dpms on

if [ -e "$VT_NR" ]; then      # we closed the lid in X
            chvt $(cat $VT_NR)
            rm -f "$VT_NR"
      fi
else                                # closing the lid
      echo $(fgconsole) > $VT_NR    # remember the current vt
      chvt 1
fi

This document is strictly confidential and intended only for use by the addressee unless otherwise stated.  If you are not the intended recipient, please notify the sender immediately and delete it from your system.

[Moshe Jacobson]

Thanks for the response.  It seems like this is a bug that shoud be
addressed.  But I just today tried setting it to "blank screen" when I
closed the lid, and now when I close and open it, it does successfully reset
the display.

Moshe

On 11/27/06, [e-mail]  wrote:
> [e-mail] wrote on 11/26/2006 11:11:26 PM:
> > For maybe around a week now, my laptop's does not turn back on when
> > I open the lid.  I can be logged in or at the gdm screen, but
> > closing the laptop lid permanently blanks my screen.  I have set all
> > my gnome-power-manager options never to shut off the screen or
> > perform any action on a lid close.
> >
> > I have a Dell Latitude D610 with an Intel 915GM/GMS/910GML
> > (according to lspci), which uses the i810 video driver.
> >
> > FWIW, using the xset dpms force off does blank the screen, but it
> > successfully turns back on when I move the mouse.
> >
> > Any ideas?
>
> Yes.  I think I have the same issue with my Dell Inspiron 6400 (aka 1505?)
> I googled the world and found someone (at U of T) with a solution that
> worked for me. (sorry, I can't rememeber the url and I didn'w write it
> down, but here it is from my notes:
>
> a) you need an ACPI events file to capture the lidswitch activity,
> b) a script to run when triggered to turn the light back on.
>
> (Don't forget to mark lidswitch.sh as executable.)
>
> 1/ Add the file:  /etc/acpi/events/lidswitch
>
> # /etc/acpi/events/lidswitch
> # This is called when the lid is closed or opened and calls
> # /etc/acpi/lidswitch.sh for further processing.
>
> event=button[ /]lid
> action=/etc/acpi/lidswitch.sh
>
> 2/ Add the file /etc/acpi/lidswitch.sh
>
> #!/bin/sh
> # /etc/acpi/lidswitch.sh
> # Re-activates the screen when the lid is opened again
>
> LID_STATE="/proc/acpi/button/lid/LID/state"
> LCD_STATE="/proc/acpi/video/VID/LCD/state"
> VT_NR=/tmp/lid_sh
>
> if [ -e /tmp/acpi_sleep ]; then
>       rm /tmp/acpi_sleep
>       exit
> fi
>
> grep -q open "$LID_STATE"
> if [ $? -eq 0 ]; then               # open the lid
>       vbetool dpms on
>   if [ -e "$VT_NR" ]; then      # we closed the lid in X
>         chvt $(cat $VT_NR)
>         rm -f "$VT_NR"
>   fi
>
> else                                # closing the lid
>       echo $(fgconsole) > $VT_NR    # remember the current vt
>       chvt 1
> fi
>
> This document is strictly confidential and intended only for use by the
> addressee unless otherwise stated.  If you are not the intended recipient,
> please notify the sender immediately and delete it from your system.
>
> --
> fedora-test-list mailing list
> [e-mail]
> To unsubscribe:
> https://www.redhat.com/mailman/listinfo/fedora-test-list

"Moshe Jacobson"  wrote on 11/27/2006 10:07:53 AM:
> Thanks for the response.  It seems like this is a bug that shoud be
> addressed.

I agree.  Although I am currently using FC5,
I have the same issue with FC6.
> But I just today tried setting it to "blank screen" when
> I closed the lid, and now when I close and open it, it does
> successfully reset the display.

But on my FC5 machine (after an RPM update about a month ago, I find
that (no matter what screen saver you have configured)(I normally
use a blank screen) that something within the 'system' doesn't
behave properly.

What I've seen/found-out is that using the following sample
configuration timeouts in KDE Control Center:

Appearances->Screen saver->Start after:                  5 min
Display->power control->Enable Display Power management: On
Display->power control->Standby:                         6 min
Display->power control->Suspend After:                   7 min
Display->power control->Power Off after:                 7 min

What I see is that the screen saver _does_ kick in at 5 minutes, _but_
at 6 minutes, I get either a blank screen or worse,
I see a 'big X' (ie. X Window 'X') on the screen and the screen is
now not-blank, and the display doesn't ever power down.

And I'm pretty sure that even when I get the blank screen,
the backlight still never gets turned off.
The only way to get the backlight off is to close the lid.
> On 11/27/06, [e-mail] <[e-mail] > wrote:
>
> [e-mail] wrote on 11/26/2006 11:11:26 PM:
> > For maybe around a week now, my laptop's does not turn back on when
> > I open the lid.  I can be logged in or at the gdm screen, but
> > closing the laptop lid permanently blanks my screen.  I have set all
> > my gnome-power-manager options never to shut off the screen or
> > perform any action on a lid close.
> >
> > I have a Dell Latitude D610 with an Intel 915GM/GMS/910GML
> > (according to lspci), which uses the i810 video driver.
> >
> > FWIW, using the xset dpms force off does blank the screen, but it
> > successfully turns back on when I move the mouse.
> >
> > Any ideas?
>
> Yes.  I think I have the same issue with my Dell Inspiron 6400 (aka

1505?)
> I googled the world and found someone (at U of T) with a solution that
> worked for me. (sorry, I can't rememeber the url and I didn'w write it
> down, but here it is from my notes:
>
> a) you need an ACPI events file to capture the lidswitch activity,
> b) a script to run when triggered to turn the light back on.
>
> (Don't forget to mark lidswitch.sh as executable.)
>
> 1/ Add the file:  /etc/acpi/events/lidswitch
>
> # /etc/acpi/events/lidswitch
> # This is called when the lid is closed or opened and calls
> # /etc/acpi/lidswitch.sh for further processing.
>
> event=button[ /]lid
> action=/etc/acpi/lidswitch.sh
>
> 2/ Add the file /etc/acpi/lidswitch.sh
>
> #!/bin/sh
> # /etc/acpi/lidswitch.sh
> # Re-activates the screen when the lid is opened again
>
> LID_STATE="/proc/acpi/button/lid/LID/state"
> LCD_STATE="/proc/acpi/video/VID/LCD/state"
> VT_NR=/tmp/lid_sh
>
> if [ -e /tmp/acpi_sleep ]; then
>       rm /tmp/acpi_sleep
>       exit
> fi
>
> grep -q open "$LID_STATE"
> if [ $? -eq 0 ]; then               # open the lid
>       vbetool dpms on
>   if [ -e "$VT_NR" ]; then      # we closed the lid in X
>         chvt $(cat $VT_NR)
>         rm -f "$VT_NR"
>   fi
>
> else                                # closing the lid
>       echo $(fgconsole) > $VT_NR    # remember the current vt
>       chvt 1
> fi

This document is strictly confidential and intended only for use by the addressee unless otherwise stated.  If you are not the intended recipient, please notify the sender immediately and delete it from your system.

[Michal Jaegermann]

On Mon, Nov 27, 2006 at 08:44:41AM -0500, [e-mail] wrote:

Eh?
> #!/bin/sh
> # /etc/acpi/lidswitch.sh
> # Re-activates the screen when the lid is opened again
>
> LID_STATE="/proc/acpi/button/lid/LID/state"
> LCD_STATE="/proc/acpi/video/VID/LCD/state"
> VT_NR=/tmp/lid_sh
>
> if [ -e /tmp/acpi_sleep ]; then
>       rm /tmp/acpi_sleep
>       exit
> fi
>
> grep -q open "$LID_STATE"
> if [ $? -eq 0 ]; then               # open the lid

if grep -q open "$LID_STATE"; then  # lid opened
>   vbetool dpms on
>
>   if [ -e "$VT_NR" ]; then      # we closed the lid in X
>         chvt $(cat $VT_NR)

chvt $(<$VT_NR)
>         rm -f "$VT_NR"
>   fi
>
> else                                # closing the lid
>       echo $(fgconsole) > $VT_NR    # remember the current vt

Really weird.  Why not simply 'fgconsole >$VT_NR' ?
>   chvt 1
>
> fi

M.

[n0dalus]

On 11/28/06, Michal Jaegermann  wrote:
> >   echo $(fgconsole) > $VT_NR    # remember the current vt
>
> Really weird.  Why not simply 'fgconsole >$VT_NR' ?

echo $(fgconsole) > ... will put all the output on a single line,
which might be important.

n0dalus.

[Michal Jaegermann]

On Wed, Nov 29, 2006 at 12:05:37AM +1030, n0dalus wrote:
> On 11/28/06, Michal Jaegermann  wrote:
> > >   echo $(fgconsole) > $VT_NR    # remember the current vt
> >
> > Really weird.  Why not simply 'fgconsole >$VT_NR' ?
>
> echo $(fgconsole) > ... will put all the output on a single line,
> which might be important.

Are there really any circumstances when 'fgconsole' outputs more
than a single number?  'man fgconsole' seems to suggest otherwise.
What is more, you are using that later as $(<$VT_NR) which will
be a single line no matter what (unless you quote).

Even when this would be not the case then how do you propose
to employ later a content of "other lines"?

Whatever.  A detail straight from Rube Goldberg but still a detail.

Michal

[Justin Conover]

On 11/28/06, Michal Jaegermann  wrote:
> On Wed, Nov 29, 2006 at 12:05:37AM +1030, n0dalus wrote:
> > On 11/28/06, Michal Jaegermann  wrote:
> > > >   echo $(fgconsole) > $VT_NR    # remember the current vt
> > >
> > > Really weird.  Why not simply 'fgconsole >$VT_NR' ?
> >
> > echo $(fgconsole) > ... will put all the output on a single line,
> > which might be important.
>
> Are there really any circumstances when 'fgconsole' outputs more
> than a single number?  'man fgconsole' seems to suggest otherwise.
> What is more, you are using that later as $(<$VT_NR) which will
> be a single line no matter what (unless you quote).
>
> Even when this would be not the case then how do you propose
> to employ later a content of "other lines"?
>
> Whatever.  A detail straight from Rube Goldberg but still a detail.
>
> Michal
>
> --
> fedora-test-list mailing list
> [e-mail]
> To unsubscribe:
> https://www.redhat.com/mailman/listinfo/fedora-test-list

Not sure if this helps, but I run x64 on my Dell E1505 and use this in my
kernel line in grub

ec_intr=0 notsc

When I added the ec_intr=0  my  suspend works good, I left it suspend for
two days and still had batter and got my screen back :)

notsc keeps my keyboard from logging 40 strokes to 1....

if only ipw3945 and  nm-applet worked better together, currently nm doesn't
see it after suspend, currently I have to run a script to get wireless going
again but nm doesn't have a clue its there.  But its a blob and I know thats
my fault and blah blah blah ;)

Michal Jaegermann   asked on 11/27/2006 10:34:38 PM:
> On Mon, Nov 27, 2006 at 08:44:41AM -0500, [e-mail] wrote:
>
> Eh?
> > #!/bin/sh
> > # /etc/acpi/lidswitch.sh
> > # Re-activates the screen when the lid is opened again
> >
> > LID_STATE="/proc/acpi/button/lid/LID/state"
> > LCD_STATE="/proc/acpi/video/VID/LCD/state"
> > VT_NR=/tmp/lid_sh
> >
> > if [ -e /tmp/acpi_sleep ]; then
> >       rm /tmp/acpi_sleep
> >       exit
> > fi
> >
> > grep -q open "$LID_STATE"
> > if [ $? -eq 0 ]; then               # open the lid
>
> if grep -q open "$LID_STATE"; then  # lid opened
> >   vbetool dpms on
> >
> >   if [ -e "$VT_NR" ]; then      # we closed the lid in X
> >         chvt $(cat $VT_NR)
>           chvt $(<$VT_NR)
>
> >         rm -f "$VT_NR"
> >   fi
> >
> > else                                # closing the lid
> >       echo $(fgconsole) > $VT_NR    # remember the current vt
>
> Really weird.  Why not simply 'fgconsole >$VT_NR' ?
> >   chvt 1
> >
> > fi

I don't know why most of the code is there.
An abbreviated version would probably work too.

I fetched this solution from somebody's web site
(http://individual.utoronto.ca/jaelle_kitty/inspiron6400)
and it worked for me, so I'm just passing it along.
I suspect there might be extra code (to go along with
other stuff) to support something like suspend.

This document is strictly confidential and intended only for use by the addressee unless otherwise stated.  If you are not the intended recipient, please notify the sender immediately and delete it from your system.

[Jesse Keating]

On Tuesday 28 November 2006 08:45, [e-mail] wrote:
> This document is strictly confidential and intended only for use by the
> addressee unless otherwise stated.  If you are not the intended recipient,
> please notify the sender immediately and delete it from your system.

Given that you didn't send your email directly to me, and I read it from a 
public mailing list (with public archives), I'm afraid I have to inform you 
about this, and then delete the mail from my system.  However I can't delete 
it from the public web archives...

Stupid corporate message trailers

Jesse Keating   wrote on 11/28/2006 08:58:27 AM:
> On Tuesday 28 November 2006 08:45, [e-mail] wrote:
> > This document is strictly confidential and intended only for use by the
> > addressee unless otherwise stated.  If you are not the intended

recipient,
> > please notify the sender immediately and delete it from your system.
>
> Given that you didn't send your email directly to me, and I read it from

a
> public mailing list (with public archives), I'm afraid I have to inform

you
> about this, and then delete the mail from my system.  However I can't

delete
> it from the public web archives...

Yes, I know :-(

I've already commented on the list before, about that _damn_ corporate
trailer I can't get rid of.  Sorry for the "apparent" stupidity.

I hope the following 'personal' pre-trailer, makes up for it.  :-)

This document is strictly confidential and intended only for use by the addressee unless otherwise stated.  If you are not the intended recipient, please notify the sender immediately and delete it from your system.

Stupid corporate message trailers

[Jesse Keating]

On Tuesday 28 November 2006 09:23, [e-mail] wrote:
> I've already commented on the list before, about that _damn_ corporate
> trailer I can't get rid of.  Sorry for the "apparent" stupidity.
>
> I hope the following 'personal' pre-trailer, makes up for it.

How about you get a personal account and use that, such as gmail.  Abusing 
your corporate email system is probably not the best of practices.

Stupid corporate message trailers

[Jeffrey Ollie]

On Tue, 2006-11-28 at 09:26 -0500, Jesse Keating wrote:
> On Tuesday 28 November 2006 09:23, [e-mail] wrote:
> > I've already commented on the list before, about that _damn_ corporate
> > trailer I can't get rid of.  Sorry for the "apparent" stupidity.
> >
> > I hope the following 'personal' pre-trailer, makes up for it.
>
> How about you get a personal account and use that, such as gmail.  Abusing 
> your corporate email system is probably not the best of practices.

And send the message from home... A company that forces disclaimers like
these probably prohibits access to webmail too.

Jeff

Stupid corporate message trailers

I apologize in advance for any absurd message trailer that follows.

[e-mail] wrote on 11/28/2006 09:23:46 AM:
> Jesse Keating   wrote on 11/28/2006 08:58:27 AM:
> > On Tuesday 28 November 2006 08:45, [e-mail] wrote:
> > > This document is strictly confidential and intended only for use by

the
> > > addressee unless otherwise stated.  If you are not the intended
>
> recipient,
> > > please notify the sender immediately and delete it from your system.
> >
> > Given that you didn't send your email directly to me, and I read it

from
> a
> > public mailing list (with public archives), I'm afraid I have to inform
>
> you
> > about this, and then delete the mail from my system.  However I can't
>
> delete
> > it from the public web archives...
>
> Yes, I know :-(
>
> I've already commented on the list before, about that _damn_ corporate
> trailer I can't get rid of.  Sorry for the "apparent" stupidity.
>
> I hope the following 'personal' pre-trailer, makes up for it.  :-)

I HATE LOTUS NOTES!
The system decided not to include my personal trailer, that appologizes
in advance for the corporate trailer.  I guess the readers will have to
put up with our corporate stupidity and arrogance.  :-(
> This document is strictly confidential and intended only for use by the
> addressee unless otherwise stated.  If you are not the intended

recipient,
> please notify the sender immediately and delete it from your system.

This document is strictly confidential and intended only for use by the addressee unless otherwise stated.  If you are not the intended recipient, please notify the sender immediately and delete it from your system.

> I don't know why most of the code is there.
> An abbreviated version would probably work too.

I've reduced the application down to this minimized version:

#!/bin/sh
# /etc/acpi/lidswitch.sh
# Re-activates the screen when the lid is opened again

LID_STATE="/proc/acpi/button/lid/LID/state"
VT_NR=/tmp/lid_sh

if grep -q open "$LID_STATE"; then
      vbetool dpms on
      chvt `cat $VT_NR`
      rm -f "$VT_NR"
else
      fgconsole > $VT_NR
fi

This document is strictly confidential and intended only for use by the addressee unless otherwise stated.  If you are not the intended recipient, please notify the sender immediately and delete it from your system.