Re: Cancel Sleep
Re: Cancel Sleep
- Subject: Re: Cancel Sleep
- From: David Elliott <email@hidden>
- Date: Tue, 1 Jan 2008 23:20:57 -0500
Hi Andrew,
On Jan 1, 2008, at 10:38 PM, Andrew James wrote:
Ok everyone calm down, yes this may not be something everyone will
agree on, the people that use this KNOW the risks!
[...]
How does one get a notification of the lid state changing (When the
lid closes, nothing to do with sleep) that does not also mix up with
the power state changing, you will notice i dont mention a single
thing about forcing the system to stay awake or anything here, so
please can we drop the debate and stop flooding the mailing list
with the debate that will never end and just get to the point. which
just as safe measure ill say once again... How does one get a
notification of the lid state changing (When the lid closes, nothing
to do with sleep) that does not also mix up with the power state
changing
This is just a preliminary guess but I think your best bet is to make
an IOKit driver that matches on the lid hardware nub. Just look at
the Info.plist for AppleACPIButtons.kext, specifically the entry for
the AppleACPILid class.
I think it should be possible to match on that nub with a non-default
match category so that AppleACPILid still attaches. Do whatever it
does (disassemble it to find out if you have to) to receive the ACPI
events.
From there I assume you already know how you can prevent the system
from going to sleep due to AppleACPILid signaling it. By that point
you'll have received the lid close event yourself and you can decide
whether or not to abort sleep based on your own conditions.
Of course, I suppose you could also just write a driver for the ACPI
device that matched without using a match category and a higher probe
score. That will prevent AppleACPILid from matching at all in which
case I would assume closing and opening the lid won't even be noticed
by the OS.
If you just need a quick hack, that should do it for you. There's
basically nothing Apple can do short of special-casing matching for
certain hardware devices to keep you from taking over the default
match category on the provider nub.
If you finish this and come up with a kext that fixes my problem I'll
be very grateful. To recap, I _want_ the machine to sleep on lid close
like it normally does except when AC power is applied in which case I
want it to stay on. This behavior makes the most sense to me and
probably to everyone else who isn't drinking the Kool-Aid at the Apple
cafeteria. I'd write the damn thing myself but 1) I really think
Apple should already do it this way, and 2) I'm not annoyed enough
(yet) to spend the time to do it.
Another interesting hack would be to check if say "Option" is being
held down when the lid is closed. In that case the user obviously has
an external keyboard (it's physically impossible to accomplish this
feat with an internal one) and the user most definitely wants the
machine to stay awake. Best of both worlds.
Of course, come to think of it, that's probably possible already. You
get the sleep message (whether it was caused by lid close or not is
irrelevant) and check the keyboard status. If set, you cancel the
sleep. Hmm...
-Dave
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden