Re: LID button Event ACPI malfunction
It seems I sent the email too early. I discovered new things.
While ACID is shut down, I cat-ed for /proc/acpi/event and I saw that between
the event of closing and opening, there isn't any difference. There is only a
counter that counts upwards every event counting as one. So when I close the
lid, it is 001 when I open it is 002 etc. That isn't very good. Also, if I
close the lid and open very fast, there will be only one event recognized.
Another thing is that when ACPID runs, and I do a suspend and then resume, the
resume (opening lid) might count toward another suspend. But it just gets
stored in some cache, and when I stop the machine, it does the suspend again
as it finds the wandering suspend event?
It is really over my knowledge, so I am just throwing ideas out. Can you help?
On Wednesday 22 December 2004 01:52 pm, Benedek Frank wrote:
> Hi Derek
> Thanks for picking up this subject with me.
> > Subject: Re: LID button Event ACPI malfunction
> > Date: Wednesday 22 December 2004 04:50 am
> > From: Derek Broughton <email@example.com>
> > To: firstname.lastname@example.org
> > On Tuesday 21 December 2004 19:27, Benedek Frank wrote:
> > > /proc/acpi/button/lid/LID0/state
> > >
> > > it says
> > >
> > > state: closed
> > >
> > > It is clearly not closed, as I am looking at the screen. :)
> > No surprise to me. The actual event posted by ACPI (at least on my
> > Inspiron - it may well differ machine to machine) is merely a counter of
> > the number of times the lid has been opened _or_ closed. Mine is
> > currently showing the correct value in /proc/acpi/button/lid/LID/state,
> > but I shouldn't think it's hard to confuse it.
> Mine shows open when it boots. When I suspend it once by closing the lid,
> and reopen it, it resumes, but it will keep showing the status as closed
> from here on, until reboot.
> > > I have an ACPI event that gets triggered when I REALLY close the lid,
> > > and that works.
> > >
> > > Here is the event
> > >
> > > /etc/acpi/event/lidbtn
> > >
> > > event=button/lid
> > > action=/etc/acpi/lidbtn.sh
> > >
> > > And here is the script
> > >
> > > /etc/acpi/lidbtn.sh
> > >
> > > #!/bin/sh
> > > /sbin/sleep
> > So what happens when you _open_ the lid? While there may be different
> > events for opening and closing, you're triggering sleep for _any_ lid
> > event.
> When I open the lid, the computer resumes. When I close it, it suspends.
> Everything is just perfect except that when I shut down the computer, it
> triggers a suspend twice in a row.
> > It looks like it's working as designed :-) My guess from your
> > description is that you issued a shutdown, closed the lid (triggered one
> > sleep), opened the lid (triggered another sleep) and then let it finish
> > its job.
> Yes, that would make sense, but it isn't what I did. I just shut down the
> machine and it does it by itself. i dont close the lit by any chance. Also,
> It does it repetitively, not only once. Every time I reboot, it is the same
> > Turn off acpid, cat /proc/acpi/event and watch what happens as you open
> > and close the lid. If the event really differentiates between open and
> > closed, change the event/lidbtn event to catch just the _close_ event.
> > Otherwise, you'll have to rely on the contents of
> > /proc/acpi/button/lid/LID0/state and test for it.
> Hi. Can you explain how to do this? by the way, when I stop ACPID and cat
> for the event, it does show everything correctly. That puzzles. me.
> > Then you also need something for shutdown that prevents the lid event
> > triggering your sleep script if you close the lid before shutdown is
> > complete. It's probably simplest just to make sure that the very first
> > thing you do during shutdown is kill acpid.
> > --
> Even with ACPID off, the shutdown will trigger the suspends. Any clues? For
> me it looks very messed up.
> To UNSUBSCRIBE, email to debian-laptop-REQUEST@lists.debian.org
> > with a subject of "unsubscribe". Trouble? Contact
> > email@example.com
> > -------------------------------------------------------