site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Hi Andrew, On Jan 1, 2008, at 10:38 PM, Andrew James wrote: -Dave _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... 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... This email sent to site_archiver@lists.apple.com