ACPI

On Thu, 2002-05-23 at 11:41, Stefan Bellon wrote:
> Hi!
> 
> I've just notices something weird (as I think). If I have acpid not
> running and cat /proc/acpi/event then ...
> 
> vici:/home/sbellon# cat /proc/acpi/event
> button/lid LID 00000080 1
> button/lid LID 00000080 2
> button/power PWRF 00000080 1
> button/power PWRF 00000080 2

> Then I had a look into /var/log/acpid and indeed, the events appear in
> this order:
> 
> lid
> power button
> lid
> power button
> 
> So, the lid event when the lid was opened was queued till after the
> power button actually has been pressed.
> 
> Is *this* correct behaviour? If it is, is it guaranteed to work like
> this? Then I'd have to react only on every second lid event.

Shouldn't you be looking at the button state, i.e. that last number
which appears in the event output? It looks like 1 == pressed, 2 ==
released. Though I haven't tried this, I would expect that you would
want to initiate sleep on lid=1, and ignore any events until you see
lid=2. You might also need to ignore the next event as well. I'm using
ospmd instead of acpid, so I don't know this is do-able within those
frameworks.

-- 
Andy Dustman         PGP: 0x930B8AB6
    @       .net     http://dustman.net/andy
"Cognito, ergo sum." -- Rene Descartes
"I yam what I yam and that's all that I yam." -- Popeye

On Thu, 2002-05-23 at 12:37, Andy Dustman wrote:

> Shouldn't you be looking at the button state, i.e. that last number
> which appears in the event output? It looks like 1 == pressed, 2 ==
> released.

Nope, that's a counter, never mind. (I had to kill ospmd to find this
out...)

-- 
Andy Dustman         PGP: 0x930B8AB6
    @       .net     http://dustman.net/andy
"Cognito, ergo sum." -- Rene Descartes
"I yam what I yam and that's all that I yam." -- Popeye

From: "Andy Dustman" <andy@...>

> On Thu, 2002-05-23 at 11:41, Stefan Bellon wrote:
> >
> > I've just notices something weird (as I think). If I have acpid not
> > running and cat /proc/acpi/event then ...
> >
> > vici:/home/sbellon# cat /proc/acpi/event
> > button/lid LID 00000080 1
> > button/lid LID 00000080 2
> > button/power PWRF 00000080 1
> > button/power PWRF 00000080 2
>
> > Then I had a look into /var/log/acpid and indeed, the events appear in
> > this order:
> >
> > lid
> > power button
> > lid
> > power button
> >
> > So, the lid event when the lid was opened was queued till after the
> > power button actually has been pressed.
> >
> > Is *this* correct behaviour? If it is, is it guaranteed to work like
> > this? Then I'd have to react only on every second lid event.
>
> Shouldn't you be looking at the button state, i.e. that last number
> which appears in the event output? It looks like 1 == pressed, 2 ==

It is, as you've realized, a counter. So you can still use (n mod 2) as a
state, but that's not the issue.  I've seen this problem too - and thought
it was an ACPI issue - but it seems from Stefan's experiment that the
problem must be in acpid.  If /proc/acpi/event has things in one order, but
acpid processes them in another, then acpid has to be the one that's wrong.
--
derek

Derek Broughton wrote:
> From: "Andy Dustman" <andy@...>
> > On Thu, 2002-05-23 at 11:41, Stefan Bellon wrote:

[snip]

> > > vici:/home/sbellon# cat /proc/acpi/event
> > > button/lid LID 00000080 1
> > > button/lid LID 00000080 2
> > > button/power PWRF 00000080 1
> > > button/power PWRF 00000080 2

[snip]

> I've seen this problem too - and thought it was an ACPI issue - but
> it seems from Stefan's experiment that the problem must be in acpid. 
> If /proc/acpi/event has things in one order, but acpid processes them
> in another, then acpid has to be the one that's wrong. -- derek

Ah, I'm not so sure about that. The tests when acpid was not running
didn't put the notebook in S1 obviously. And therefore it's clear that
when opening the lid again, the second lid event occurs. But when acpid
is running, the notebook goes to S1 when the first lid event occurs.
When you open the lid again, the second event /should/ occur, but the
notebook is sleeping. Then you press the power button and /that/ event
is recognised. Perhaps the lid opening is then "remembered" and
inserted into the event queue.

I don't think you can draw the conclusion you did from what we
experience.

Greetings,

Stefan.

-- 
 Stefan Bellon * <mailto:sbellon@...> * <http://www.sbellon.de/>
 PGP 2 and OpenPGP keys available from my home page

 1/1=1.089089789701234132  :  It's close enough. (Intel 1994)

From: "Stefan Bellon" <sbellon@...>

> Derek Broughton wrote:
> > From: "Andy Dustman" <andy@...>
> > > On Thu, 2002-05-23 at 11:41, Stefan Bellon wrote:
>
> [snip]
>
> > > > vici:/home/sbellon# cat /proc/acpi/event
> > > > button/lid LID 00000080 1
> > > > button/lid LID 00000080 2
> > > > button/power PWRF 00000080 1
> > > > button/power PWRF 00000080 2
>
> [snip]
>
> > I've seen this problem too - and thought it was an ACPI issue - but
> > it seems from Stefan's experiment that the problem must be in acpid.
> > If /proc/acpi/event has things in one order, but acpid processes them
> > in another, then acpid has to be the one that's wrong. -- derek
>
> Ah, I'm not so sure about that. The tests when acpid was not running
> didn't put the notebook in S1 obviously. And therefore it's clear that
> when opening the lid again, the second lid event occurs. But when acpid
> is running, the notebook goes to S1 when the first lid event occurs.
> When you open the lid again, the second event /should/ occur, but the
> notebook is sleeping. Then you press the power button and /that/ event
> is recognised. Perhaps the lid opening is then "remembered" and
> inserted into the event queue.

Nothing you did _should_ have put the notebook in S1.  acpid had to have
done that. So I still say acpid is processing things in the wrong order.
However, it seems we both may be making an invalid assumption - that is, you
simply can't ever recognize any button push except the power button when you
are in S1.  That's a real bitch...
--
derek

Derek Broughton wrote:
> From: "Stefan Bellon" <sbellon@...>

[snip]

> > Ah, I'm not so sure about that. The tests when acpid was not
> > running didn't put the notebook in S1 obviously. And therefore it's
> > clear that when opening the lid again, the second lid event occurs.
> > But when acpid is running, the notebook goes to S1 when the first
> > lid event occurs. When you open the lid again, the second event
> > /should/ occur, but the notebook is sleeping. Then you press the
> > power button and /that/ event is recognised. Perhaps the lid
> > opening is then "remembered" and inserted into the event queue.

> Nothing you did _should_ have put the notebook in S1.  acpid had to
> have done that.

Sorry, that's what I meant with "when acpid is running ...". Yes, when
acpid is running and has the lid button script recognised, /then/ acpid
puts the notebook into S1 if the lid is closed. That's what I meant to
say.

> So I still say acpid is processing things in the wrong order.

But how should acpid get the lid event before the power button event?

> However, it seems we both may be making an invalid assumption - that
> is, you simply can't ever recognize any button push except the power
> button when you are in S1.  That's a real bitch... 

Yes, exactly. Either every event that occurred during S1 mode has to be
ignored when waking up, or they should be raised in the correct order.

Greetings,

Stefan.

-- 
 Stefan Bellon * <mailto:sbellon@...> * <http://www.sbellon.de/>
 PGP 2 and OpenPGP keys available from my home page

 If the answer is Microsoft, the question must have been quite stupid.