# Dell laptop lid switch not working

## mpc

I have a Dell Inspiron 5100 running with the 2.6 kernal and the screen does not blank when I close the lid.

I  noticed a mention of the lid switch on boot, and dmegs had this to say:

```
ACPI: Lid Switch [LID]
```

Has anyone else run into this problem?

Any Ideas?

Thank you

----------

## Earthwings

You've got to either enable it in your BIOS or emerge acpid and configure it to react on the LID switch.

----------

## mpc

I have acpid emerged but I can't find a config file for it?

----------

## Earthwings

By default /etc/acpi/default.sh is called for every event.

Here's a little more extended one. Replace ACTION with what you like.

```

#!/bin/sh

set $*

group=${1/\/*/}

action=${1/*\//}

case "$group" in

   button)

      case "$action" in

         power)   ACTION

            ;;

            

         sleep)  ACTION

            ;;

         

         lid)   ACTION

            ;;

         *)   logger "ACPI group button / action $action is not defined"

            ;;

      esac

      ;;

   battery)

      case "$action" in

         battery) ACTION 

             ;;

         *)    logger "ACPI group battery / action $action is not defined"

             ;;

      esac

      ;;

            

   ac_adapter)

      case "$action" in

         ac_adapter) ACTION

                ;;

         *)       logger "ACPI group ac_adapter / action $action is not defined"

                ;;

      esac

      ;;

   *)

      logger "ACPI group $group / action $action is not defined"

      ;;

esac

```

See [1] for an example on how to use for Power Management.

[1] http://www.stud.uni-karlsruhe.de/~uxhz/gentoo/power-management

----------

## mpc

Thanks for your help.  Sory about the late reply. Work called and all of that.

Sorry if I'm asking stupid questions but I can't seam to find a way to get the screen to blank. So therefor I can not modify the default.sh script

I tried: 

```
setterm -powersave powerdown
```

but all I got was: 

```
cannot (un)set powersave mode
```

I know I'm missing somthing realy simple.   Sorry.

Thanks for all of your help

----------

## Earthwings

Try

```
xset dpms force off
```

. Replace off with suspend or standby if you like.

----------

## mpc

tried

 *Quote:*   

> xset dpms force off

 

the system takes the command but nothing happens

----------

## Earthwings

Do you have 

```
Option  "DPMS"  "true"
```

in the Monitor section in /etc/X11/XF86Config?

----------

## mpc

AHHH!!!  Wonderfull.  By adding:

```
Option  "DPMS"  "true"
```

 I was able to get the screen to blank.  But...

1) The screen blanks but it looks like the backlight is still on.  Any Idea how to kill this?

2) And second, I added the lid line to /etc/aspci/default.sh as follows with no result.

```

case "$action" in

         power)   /sbin/init 0

            ;;

         lid)   /usr/X11R6/bin/xset dpms force off

            ;;

         *)   logger "ACPI action $action is not defined"

            ;;

      esac
```

Thank you very much for all of your help.

----------

## Earthwings

You can use app-laptop radeontool if you have an ATI Radeon mobility graphics card to turn the backlight off.

For the script: Very likely there's a syntax error inside that causes the script to fail. Try running it by hand and look for useful error messages.

----------

## zerocool_australia

Dell Inspiron 1100 and 5100 series laptops' BIOS does not work with the Linux ACPI implementation currently, the biggest problem is the /proc/acpi/events does not generate any events (from what I can see) ever. I have had both an 1100 and a 5100 and neither will do this. You can get the status of everything from /proc/acpi/[device] but no realtime event generation.

DPMS in X will blank the screen and or power down the backlight also when you have DPMS on. If it is not turning off the backlight it probably isn't actually DPMS doing it. Mess with the xset dpms command sometime. I put an xset dpms 300 300 300 in my flux rc file to turn off the screen totally after 5 minutes and it works. All those acpid scripts you can throw out the window, acpid is dependant on /proc/acpi/events working

David

----------

## mpc

 *Quote:*   

> All those acpid scripts you can throw out the window, acpid is dependant on /proc/acpi/events working 

 

That explains a lot

However seeing as 

```
xset dpms force off
```

still only blanks the screen and does not kill the backlight.  I looks as if dpms is enabled implicity when dpms force off is entered.  Testing dpms with  

```
xset dpms 10 10 10
```

 just put the screen blank but did not kill the backlight.  I must me missing somthing

radeontool kills the backlight but I had to turn it back on headless (not somthing I want to do all the time)

----------

## zerocool_australia

Very interesting, for me, xset dpms force off turns off the backlight.

Here is my xset -q, paste yours too please possibly there's another setting I forgot that I set.

bash-2.05b$ xset q

Keyboard Control:

  auto repeat:  on    key click percent:  0    LED mask:  00000000

  auto repeat delay:  660    repeat rate:  25

  auto repeating keys:  00ffffffdffffbbf

                        fadfffdfffdfe5ef

                        ffffffffffffffff

                        ffffffffffffffff

  bell percent:  50    bell pitch:  400    bell duration:  100

Pointer Control:

  acceleration:  2/1    threshold:  4

Screen Saver:

  prefer blanking:  yes    allow exposures:  yes

  timeout:  600    cycle:  600

Colors:

  default colormap:  0x20    BlackPixel:  0    WhitePixel:  16777215

Font Path:

  /usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X1  1/fonts/100dpi/

Bug Mode: compatibility mode is disabled

DPMS (Energy Star):

  Standby: 300   Suspend: 300    Off: 300

  DPMS is Enabled

  Monitor is On

Font cache:

  hi-mark (KB): 5120  low-mark (KB): 3840  balance (%): 70

File paths:

  Config file:  /etc/X11/XF86Config

  Modules path: /usr/X11R6/lib/modules

  Log file:     /var/log/XFree86.0.log

----------

## mpc

Here you go

```
Keyboard Control:

  auto repeat:  on    key click percent:  0    LED mask:  00000000

  auto repeat delay:  660    repeat rate:  25

  auto repeating keys:  00ffffffdffffbbf

                        fadfffffffdffdff

                        ffffffffffffffff

                        ffffffffffffffff

  bell percent:  50    bell pitch:  400    bell duration:  100

Pointer Control:

  acceleration:  2/1    threshold:  4

Screen Saver:

  prefer blanking:  yes    allow exposures:  yes

  timeout:  0    cycle:  0

Colors:

  default colormap:  0x20    BlackPixel:  0    WhitePixel:  16777215

Font Path:

  /usr/X11R6/lib/X11/fonts/local/,/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/75dpi/:unscaled,/usr/X11R6/lib/X11/fonts/100dpi/:unscaled,/usr/X11R6/lib/X11/fonts/Speedo/,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/

Bug Mode: compatibility mode is disabled

DPMS (Energy Star):

  Standby: 7200    Suspend: 7200    Off: 14400

  DPMS is Enabled

  Monitor is On

Font cache:

  hi-mark (KB): 5120  low-mark (KB): 3840  balance (%): 70

File paths:

  Config file:  /etc/X11/XF86Config

  Modules path: /usr/X11R6/lib/modules

  Log file:     /var/log/XFree86.0.log
```

I did notice that dpms was not enabled when I turned my computer back on, but I enabled it and xset dpms force off still will not kill the backlight

Thanks

----------

## kongit

 *Quote:*   

> Dell Inspiron 1100 and 5100 series laptops' BIOS does not work with the Linux ACPI implementation currently, the biggest problem is the /proc/acpi/events does not generate any events (from what I can see) ever. I have had both an 1100 and a 5100 and neither will do this. You can get the status of everything from /proc/acpi/[device] but no realtime event generation.
> 
> DPMS in X will blank the screen and or power down the backlight also when you have DPMS on. If it is not turning off the backlight it probably isn't actually DPMS doing it. Mess with the xset dpms command sometime. I put an xset dpms 300 300 300 in my flux rc file to turn off the screen totally after 5 minutes and it works. All those acpid scripts you can throw out the window, acpid is dependant on /proc/acpi/events working
> 
> 

 

not entirely true.  I have a dell inspiron 5100 and I know that the lids states are changed in the file.  It might be because your bios isn't a newer one.  I had to upgrade mine to at least a23 to get acpi to work.  However I have not been able to get the screen to turn off when shutting the lid but that is most likely due to some error on my part.

----------

## trapperjohn

I have an Inspiron 8600 and lid etc. works. I've read somewhere, that newer nVidia Drivers don't work with DPMS - maybe there is a problem with your drivers, too. ATM I have to restart acpid after login, else "xset" doesn't work - still have to investigate this problem.

Another thing is replacing your DSDT with a corrected one - look at http://acpi.sf.net (there's a HowTo in this forum, too).

Good Luck.

----------

## zerocool_australia

 *Quote:*   

> not entirely true. I have a dell inspiron 5100 and I know that the lids states are changed in the file. It might be because your bios isn't a newer one. I had to upgrade mine to at least a23 to get acpi to work. However I have not been able to get the screen to turn off when shutting the lid but that is most likely due to some error on my part.

 

Yes, sigh, I knew that, my point is that the /proc/acpi/event interface does not work and you will not get realtime events. If you want to do anything with the status of the lid, you would have to have a daemon poll the lid state file. I never said this didn't work. 

By the way, the newer BIOSes are the reasons this don't work. For lucky people with A02 and other early BIOSes more ACPI seems to work.

Also....as someone else mentioned new DSDTs...there is no new DSDT to fix the event interface and I don't have enough time to write one.

----------

## g3n

I have bios a23, is there anything that i can do? i cant understand this

----------

## _DaMaGe_

Hey guys, I had a similar problem

I just bought a dell inspiron 1150 and the lid switch wasn't working

i don't think any of the events were working

I'm pretty sure the ACPID daemon just isn't compatible with these dells

however, querying the states of the devices seemed to be working fine, as my battery monitor works fine

so i created a perl script to run as a daemon to monitor the lid switch and turn it off with the xset dpms force off command 

here is the script, it may work for you too

<CODE>

#!/usr/bin/perl -w                                                                              

$pid = fork();

if($pid) { exit; }

$last = 1;

while(1) {

        sleep 3;

        @data = `cat /proc/acpi/button/lid/LID/state`;

        $state = $data[0];

        if($state =~ /open/ && $last == 0) {

                `xset dpms force on`;

                $last = 1;

        } elsif ($state =~ /closed/ && $last == 1) {

                `xset dpms force off`;

                $last = 0;

        }

}

</CODE>

----------

## DaMaGe

Get your own name.  Stop copying other people

Had this name for 7 years on the net.  And slowly I start seeing other people using the SAME way of me spelling it.

----------

## _DaMaGe_

to be truly honest, I never even noticed your nickname

I've been nicknamed damage for most my life because it rhymes with my last name

sorry about that!

i've been trying to think of a new nickname anyways  :Razz:  obviously its a decent nickname for my friends to call me , but not on the net where we are running out of 'unique' handles.

----------

## _DaMaGe_

well, anyways

i'll use this nickname for now

can't go wrong with japanese...

----------

## _DaMaGe_

I tried to change it... doesn't seem to work

sorry!

----------

## DaMaGe

lol, not everyday you come face to face with yourself!!!!!

----------

## Voltago

Had the same issue with the lid some time ago. 

What bugged me was that you seem to need a running X to use the xset tool to control monitor states, also trying it in terminals other than vc 7 where X was running didn't work. 

So I figured out how X was doing it and hacked up a tool that does exactly the same directly. Actually, I just altered the 'vbetest' tool a bit, see code comment. OK, here goes:

```
/*

Change the dpms mode of your graphics controller.

Version: 0.1 

Date: 12.06.2004

This program is derived from the public domain 

code of 'vbetest.c' from the 'lrmi' package 

available at http://sourceforge.net/projects/lrmi 

and is also in the public domain.

Furthermore, this program comes with no warranty for

fitness for any purpose whatsoever and if it reduces

your computer to a smoldering heap I shall not be

held responsible.

To build it, you'll need said lrmi package.

I used version 0.8, the environment is Linux,

the machine is a Dell 510m laptop with Intel's

82852/855GM graphics bloody controller.

Andreas Eckstein, 2004

*/

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <unistd.h>

#include <sys/ioctl.h>

#if defined(__linux__)

#include <sys/io.h>

#include <sys/kd.h>

#include <sys/stat.h>

#elif defined(__NetBSD__)

#include <time.h>

#include <dev/wscons/wsconsio.h>

#include <machine/sysarch.h>

#elif defined(__FreeBSD__)

#include <machine/console.h>

#include <machine/sysarch.h>

#endif

#include <lrmi.h>

#include <vbe.h>

#define DPMS_ON      ((unsigned int)0x00000000)

#define DPMS_STANDBY   ((unsigned int)0x00000100)

#define DPMS_SUSPEND   ((unsigned int)0x00000200)

#define DPMS_OFF   ((unsigned int)0x00000400)

#define VESA_DPMS ((unsigned int)0x00004F10)

#define DPMS_SET_MODE ((unsigned int)0x00000001)

#define DPMS_GET_MODE ((unsigned int)0x00000002)

#define MASK_LBYTE ((unsigned int)0x000000FF)

#define MASK_HBYTE ((unsigned int)0x0000FF00)

struct {

   struct vbe_info_block *info;

   struct vbe_mode_info_block *mode;

   char *win;    /* this doesn't point directly at the window, see update_window() */

   int win_low, win_high;

} vbe;

void

usage_and_quit(int error)

{

   fputs("Usage: dpmsctl {on|standby|suspend|off|status}\n",

    error ? stderr : stdout);

   exit(error);

}

int

main(int argc, char *argv[])

{

   int retval=0;

   struct LRMI_regs r;

#if defined(__NetBSD__)

   unsigned long iomap[32];

#endif

   unsigned int dpms_mode=-1;

   unsigned int dpms_action=DPMS_SET_MODE;

      

   if(argc>1) {

      if (strcmp(argv[1], "on") == 0) {

         dpms_mode=DPMS_ON;

      } else if (strcmp(argv[1], "standby") == 0) {

         dpms_mode=DPMS_STANDBY;

      } else if (strcmp(argv[1], "suspend") == 0) {

         dpms_mode=DPMS_SUSPEND;

      } else if (strcmp(argv[1], "off") == 0) {

         dpms_mode=DPMS_OFF;

      } else if (strcmp(argv[1], "status") == 0) {

         dpms_action=DPMS_GET_MODE;

         dpms_mode=0;

      } else {

         usage_and_quit(1);

      } 

   }

   

   if(dpms_mode==-1)

      usage_and_quit(1);

   //printf("dpms_mode: %d\n", dpms_mode);

   

   if (!LRMI_init()){

      fprintf(stderr, "Can't initialize LRMI environment\n");

      return 1;

   }

   

   vbe.info = LRMI_alloc_real(sizeof(struct vbe_info_block)

    + sizeof(struct vbe_mode_info_block));

   if (vbe.info == NULL) {

      fprintf(stderr, "Can't alloc real mode memory\n");

      return 1;

   }

   vbe.mode = (struct vbe_mode_info_block *)(vbe.info + 1);

#if 0

   /*

    Allow read/write to video IO ports

   */

   ioperm(0x2b0, 0x2df - 0x2b0, 1);

   ioperm(0x3b0, 0x3df - 0x3b0, 1);

#else

   /*

    Allow read/write to ALL io ports

   */

#if defined(__linux__)

   ioperm(0, 1024, 1);

   iopl(3);

#elif defined(__NetBSD__)

   memset(&iomap[0], 0xff, sizeof(iomap));

   i386_set_ioperm(iomap);

   i386_iopl(3);

#elif defined(__FreeBSD__)

   i386_set_ioperm(0, 0x10000, 1);

#endif

#endif

   memset(&r, 0, sizeof(r));

   r.eax = 0x4f00;

   r.es = (unsigned int)vbe.info >> 4;

   r.edi = 0;

   memcpy(vbe.info->vbe_signature, "VBE2", 4);

   if (!LRMI_int(0x10, &r)) {

      fprintf(stderr, "Can't get VESA info (vm86 failure)\n");

      return 1;

   }

   if ((r.eax & 0xffff) != 0x4f || strncmp(vbe.info->vbe_signature, "VESA", 4) != 0) {

      fprintf(stderr, "No VESA bios\n");

      return 1;

   }

   

   r.eax=VESA_DPMS;

   r.ebx= dpms_action | dpms_mode;

   LRMI_int(0x10, &r);

   

   if(dpms_action==DPMS_SET_MODE)

   {

      

   }

   

   if(dpms_action==DPMS_GET_MODE)

   {

      dpms_mode = (r.ebx & MASK_HBYTE);

      

      printf("active dpms mode: ");

      switch(dpms_mode)

      {

         case DPMS_ON:

            printf("on\n");

            break;

         case DPMS_STANDBY: 

            printf("standby\n");

            break;

         case DPMS_SUSPEND:

            printf("suspend\n");

            break;

         case DPMS_OFF:

            printf("off\n");

            break;

         default:

            printf("error: received non VESA-compliant DPMS state\n");

            printf("but if you can read this, DPMS state should be 'on'\n");

            retval = 1;

      }      

   }

   

   int dpms_return = (r.eax & MASK_HBYTE) >> 8;

   

   if(dpms_return!=0)

      printf("error code: %d\n", dpms_return);

   

   LRMI_free_real(vbe.info);

   return retval;

}
```

To build the code, save it as e. g. 'dpmsctl.c', emerge 'lrmi' and type

```
gcc -o dpmsctl dpmsctl.c -llrmi
```

Oh yes, lrmi-0.8 is not in portage, but you can just rename the 0.7 ebuild.

This should make the perfect tool for use with powermanagement scripts and for driving people mad with mysterious monitor 'malfunctions' you can control per ssh... 

Questions, comments and constructive criticism are most welcome!

P. S.: Look, ma, my first piece of OSS!

----------

## kwenspc

I was looking for LID problem on my Dell and I found this topic.

I've tried the given command "xset dpms force off" and suprize : now (after moving my mouse) when I close screen and reopen it : LID works!

so I've put this command on my .xinitrc and now the LID works perfectly!   :Shocked: 

but I don't know which is the strange link between LID (managed by ACPI) and xset command...

----------

## mrfree

The use of 

```
xset dpms force on
```

 in an acpi driven script works only under X!

There is a similar method for console?

----------

## z0ny

Yes, I faced the same problem and found a solution:

```
echo 0x80000001 > /proc/acpi/video/VID/LCD/state
```

This can be used in an ACPI script to automate the screen wakeup.  :Smile: 

----------

## mrfree

Ohhhhh yes!!!   :Very Happy: 

It works like a charm (console and X too) thanks

This is my last /etc/acpi/lid.sh script

```
#!/bin/sh

grep -r close /proc/acpi/button/lid/LID/state

if [ $? -eq 1 ]; then

        echo 0x80000001 > /proc/acpi/video/VID/LCD/state

fi
```

----------

## dambacher

Holy S**T

I was the one wo made the dell inspiron 5100 dsdt for a working acpi.

Now my laptop had to be repaired last week. 

And these guys from dell changed fans and flushed the bios with the newes version   :Crying or Very sad: 

Now Battery and lid works without dsdt-modifications  but button  events do not - And I am angry!

But Hope is on its way, I just found my old acpi development environment burried in a configuration subdirectory.

I'll try a new patch and post it here if I'm successful.

UPDATE:

I found out, that if you follow this page[url]http://cabibbo.physics.wm.edu/~bryan/computer/inspiron5100.html

[/url] you can get the buttons to work if you run xorg and have the graphical display activated, e.g. not on text console

I just decompiled the dsdt and yes: the dsdt code looks for the operating system and acts differently

and no: they don't test for linux   :Evil or Very Mad: 

let's look if I can change that...

----------

## Quinny

I've got a problem with a Dell 510m and the lid:

It used to remain black when I opened the screen, after the command was put in the lid script for acpi as said by mrfree the screen comes back to life.

The problem here is that the screen is al messed up, horizontal lines all over the screen, like the lines of pixels aren't lines up correctly anymore.

Switching to a vc and then back to xorg (ctrl+alt+f1 and then alt+f7) fixes this but it isn't ideal... Is there a way to reset the screen like this from the acpi script?

----------

## saintpa

I just played with the lid-open issue a little bit and I think I've found the solution for screen not coming on after lid openning:

1. If you haven't read this: [url]]http://gentoo-wiki.com/HOWTO_Automatically_turn_off_your_monitor[/url], read it first.

2. emerge laptop_mode with acpi enabled, leave apm disabled:

```
USE="acpi -apm" emerge -av laptop-mode-tools
```

3. edit /etc/acpi/actions/lm_lid.sh:

```
#!/bin/bash

test -f /usr/sbin/laptop_mode || exit 0

# lid button pressed/released event handler

/usr/sbin/laptop_mode auto

grep -q open /proc/acpi/button/lid/LID/state

if [ $? -eq 0 ]

then

       XAUTHORITY=`ls /etc/X11/xdm/authdir/authfiles/*:0*` /usr/bin/xset -display :0.0 dpms force on

else

       XAUTHORITY=`ls /etc/X11/xdm/authdir/authfiles/*:0*` /usr/bin/xset -display :0.0 dpms force off

fi

```

Note I added "XAUTHORITY=" before running xset, that's a better hack than the trick suggested by the howto. It works even before you log in!

----------

## dambacher

I got it to work!

inspiron 5100 with new bios: Power button and LID switch work ! 

(for old bios use the dsdt patch!) 

The /proc/event interface does not work because the acpi irq is not delivered.

There are some tricks to enable the interrupt by balancing the irq-table in a way that another device (radeon or usb) shares the irq with acpi, but that's tricky.

better use this kernel command line:

lapic irqpoll acpi_irq_balance pci=assign-busses idebus=66 

the first two are the ones that rock, the rest is just performance improovement. via irqpoll, misrouted irqs get delivered - voilais

(btw. Don't user pmtmr_good. it isn't)

bye

dambacher

----------

## dambacher

I found a new link and got it to work without any irq balance stuff.

just issue 

```

setpci -s 00:1f.0 bb.b=0a 

```

to your /etc/conf.d/local.start

this turns on the irq for the button handling.

found it in http://bugme.osdl.org/show_bug.cgi?id=1752

----------

## KrissN

I've recently bought an Inspirion 9400 and installed 64-bit Gentoo on it. What is not hard to guess the lid switch was not working.

The command:

```
xset dpms force on
```

didn't work for me. The LCD would go blank for a second and immediately go back on. This did the trick for me:

```
echo 0x80000000 > /proc/acpi/video/VID/LCD/state
```

Currently everithing is setup with acpid using the following scripts:

/etc/acpid/events/lid

```
event=button[ /]lid.*

action=/etc/acpi/lid.sh
```

/etc/acpid/lid.sh

```
#!/bin/bash

if [ "`grep open /proc/acpi/button/lid/LID/state`" == "" ]; then

    # Lid closed

    echo 0x80000000 > /proc/acpi/video/VID/LCD/state

else

    # Lid opened

    echo 0x80000001 > /proc/acpi/video/VID/LCD/state

fi
```

Thanks for all your earlier ideas, which helped me to get a working solution.

----------

## thomasa88

Heres mine ^^ (from /etc/acpi/default.sh)

```

                        lid)    lidstate="$(cat /proc/acpi/button/lid/LID/state | awk '{print $2}')" 

                                case "$lidstate" in 

                                        open)   vbetool dpms on

                                                logger "LCD panel is $lidstate" 

                                                ;; 

                                        closed) vbetool dpms off

                                                logger "LCD panel is $lidstate" 

                                                ;; 

                                esac 

                                ;;

```

but I hate that the monitor is turned when I kill a X thats been running on the svideo so I patched vbetool to also output status of dpms, but know I figured it would be better with some event or even someway to force the monitor to stay off until I tell it to get turned on.

http://tux.servegame.org/~mrt/gentoo/vbetool-0.7-dpms-status.tar.bz2

extract it in /usr/local/portage and run emerge (ie sudo tar -xjvf vbetool-0.7-dpms-status.tar.bz2 -C /usr/local/portage/ and emerge -av vbetool)

----------

