HP DVx AppleACPIBatteryManager Driver

JBraddock · February 18, 2011

I tried the driver and it seems to work fine.

Just a quick note. I don't know if any of you HP users have this problem but my laptop has a weird battery problem and it is not related to OSX and it exists from the very first day of my purchase.

If I use the laptop on battery until the battery goes below %20* and then plug in the power cord, the fan goes haywire and work almost at full speed. A cool reboot fix the problem. I think this is HP's fault and they didn't fix this problem in the past two years.

* I can't remember the exact number but overall the problem is as described above.

Anyway, looking forward to the next version of this driver.

Really appreciated.

gsly · February 18, 2011

I tried the driver and it seems to work fine.

Just a quick note. I don't know if any of you HP users have this problem but my laptop has a weird battery problem and it is not related to OSX and it exists from the very first day of my purchase.

If I use the laptop on battery until the battery goes below %20* and then plug in the power cord, the fan goes haywire and work almost at full speed. A cool reboot fix the problem. I think this is HP's fault and they didn't fix this problem in the past two years.

* I can't remember the exact number but overall the problem is as described above.

Anyway, looking forward to the next version of this driver.

Really appreciated.

You might want to check the logic related to the fan/AC in your DSDT. In the process of investigation for this driver, I realized that whomever programmed some of the DSDT functionality at HP really didn't know what they were doing :thumbsup_anim: I wouldn't be surprised if there is a bug in there causing your issue...

JBraddock · February 18, 2011

You might want to check the logic related to the fan/AC in your DSDT. In the process of investigation for this driver, I realized that whomever programmed some of the DSDT functionality at HP really didn't know what they were doing I wouldn't be surprised if there is a bug in there causing your issue...

Yes I think you are right. There is definitely something wrong with the DSDT section of Fan and/or Battery. For example, I just used my laptop on battery for a while and then plug the power, the the fan was being kicked immediately. If I unplug the power again, the fan stops just like that.

If I shutdown the HDX and wait a little and restart it will be fine. Also, when the charging is finished, it also stops. Weird ha

I don't know how to fix this as I am not a DSDT geek but at least I have something to be mad at HP

manmal · February 27, 2011

hi glsy!

do you think it may be possible to have system going automatically to sleep when battery is low, like in real macbooks ?

And to have system going to autosleep natively without using external scripts ? I tried autosleep script but it doesn't work.

May you give us a solution to such problem ? System should go automatically to sleep when battery is low and system should go to sleep like set in power managements options in system preferences.

Thanks!

Mal

gsly · February 27, 2011

hi glsy!
do you think it may be possible to have system going automatically to sleep when battery is low, like in real macbooks ?

And to have system going to autosleep natively without using external scripts ? I tried autosleep script but it doesn't work.

May you give us a solution to such problem ? System should go automatically to sleep when battery is low and system should go to sleep like set in power managements options in system preferences.

Thanks!

Mal

Manmal, I *just* got my system to properly sleep this week so I haven't been able to test this aspect previously. I did this test last night and while I did get the dialog mentioning I was on reserve power and the system would sleep in a few minutes, it did not and the system just died eventually.

I was just working on getting the next release ready for posting, but I think I will look into this issue before I make a release. I suspect there is something missing that needs to let the power management layer know its time to close up shop. It's interesting that the PM layer does seem to know its on low battery (hence the dialog) but it doesn't handle the sleep...

Time to dive back into the documentation and headers

Pasa Yildirim · February 27, 2011

@valv, few bugs encountered in this version:

1. If I boot Mac w/o battery, kext does not load.

2. If I plug battery when Mac is booted, it shows "no battery", but power source is still Battery, not Power Adapter.

manmal · February 28, 2011

Manmal, I *just* got my system to properly sleep this week so I haven't been able to test this aspect previously. I did this test last night and while I did get the dialog mentioning I was on reserve power and the system would sleep in a few minutes, it did not and the system just died eventually.

I was just working on getting the next release ready for posting, but I think I will look into this issue before I make a release. I suspect there is something missing that needs to let the power management layer know its time to close up shop. It's interesting that the PM layer does seem to know its on low battery (hence the dialog) but it doesn't handle the sleep...

Time to dive back into the documentation and headers

Thanks for replying glsy and for trying to handle such problem of system not going to sleep when battery is over.

I also tried this : when battery is low, if i close lid in my dv8 (almost the same model as yours, same cpu, same chipset, same hds, same graphics etc) , system goes to sleep of course. When battery is over in such state, it powers off and when i connect the ac-power again. it resumes from hibernate correctly. The only strange thing is that usb ports are no more working after resuming from hibernate. Sometimes i cannot see any dvd in my bluray unit, and i have to reboot.

Do you know why it happens? I guess it may depend on dsdt (but i think i have it correctly patched for usb) or it may depend on appleacpibattery... or something i don't know.

Have you got any clue about such problem?

And do you think the fact that system that doesn't read the correct time set in power options under systempreferences is due to the same problem you are investigating, with zero-battery?

Thanks for your time and your knowledge, glsy!

Mal

gsly · March 1, 2011

@valv, few bugs encountered in this version:

1. If I boot Mac w/o battery, kext does not load.

2. If I plug battery when Mac is booted, it shows "no battery", but power source is still Battery, not Power Adapter.

Thanks for the feedback! #1 is surely a bug and I never tested that situation, only removing/inserting the battery *after* boot (works). I'm sure this is because the original author of AppleACPIBatteryManager removed all of the logic that stops polling the battery on certain conditions vs. AppleSmartBatteryManger. I noticed this when investigating the no-sleep issue on low battery. Anyway, I think this can be fixed but its lower on the priority list than fixing sleep on low battery.

Is #2 a continuation of #1? I need more details on how to reproduce.

Pasa Yildirim · March 1, 2011

#2: simply unplug battery while on AC (after successful boot with battery, kext loaded of course). Then, you can see in battery menu:

Batteries: None (ok, detected )

Power source: Battery ?!

(I discovered this after I launched some setup, and it said "need to be on AC to continue").

#2: simply unplug battery while on AC (after successful boot with battery, kext loaded of course). Then, you can see in battery menu:

Batteries: None (ok, detected )

Power source: Battery ?!

(I discovered this after I launched some setup, and it said "need to be on AC to continue").

gsly · March 1, 2011

Thanks for replying glsy and for trying to handle such problem of system not going to sleep when battery is over.
I also tried this : when battery is low, if i close lid in my dv8 (almost the same model as yours, same cpu, same chipset, same hds, same graphics etc) , system goes to sleep of course. When battery is over in such state, it powers off and when i connect the ac-power again. it resumes from hibernate correctly. The only strange thing is that usb ports are no more working after resuming from hibernate. Sometimes i cannot see any dvd in my bluray unit, and i have to reboot.

Do you know why it happens? I guess it may depend on dsdt (but i think i have it correctly patched for usb) or it may depend on appleacpibattery... or something i don't know.

Have you got any clue about such problem?

And do you think the fact that system that doesn't read the correct time set in power options under systempreferences is due to the same problem you are investigating, with zero-battery?

Thanks for your time and your knowledge, glsy!

Mal

I'll try to test that scenario above as so far I've only tested sleep on my DV8 now that I've got it working. The issue it likely DSDT related and if devices are working correctly after sleep, but not hibernate, you'll want to start looking at the _WAK method and the logic used for the different sleep levels passed to _WAK in Arg0.

I'm not sure what you mean by the incorrect time in power options. You mean the time remaining calculation? I think this is working on the latest driver (unreleased). I'll check this.

manmal · March 1, 2011

I'll try to test that scenario above as so far I've only tested sleep on my DV8 now that I've got it working. The issue it likely DSDT related and if devices are working correctly after sleep, but not hibernate, you'll want to start looking at the _WAK method and the logic used for the different sleep levels passed to _WAK in Arg0.

I'm not sure what you mean by the incorrect time in power options. You mean the time remaining calculation? I think this is working on the latest driver (unreleased). I'll check this.

Hi,

thanks for your reply.

With "incorrect time" in power options i mean that if i set that system must go to sleep automatically after 10 minutes, it doesn't go to sleep at all after 10 minutes! I mean that... battery calculation is fixed using your latest release, you are right, but it doesn't solve the proper power management option that system goes to sleep automatically after X minutes set in power options. And it doesn't go to sleep automatically when battery is low... i guess both are due to the same reason... .that i do not know what it is.

USB and DVDROM are not working any more from sleep to hibernate very often when i change the source from ac-power to battery and vice-versa. Related to ACPIBattery too in your opinion?

I am using latest chameleon trunk... and latest taptun kernel for 10.6.6.

And i attach my DV8's dsdt here if you wanna give a look to it...(if you have time).

Thanks!

Mal

dsdtDV8manmal.dsl.zip

gsly · March 2, 2011

#2: simply unplug battery while on AC (after successful boot with battery, kext loaded of course). Then, you can see in battery menu:
Batteries: None (ok, detected )

Power source: Battery ?!

(I discovered this after I launched some setup, and it said "need to be on AC to continue").

#2: simply unplug battery while on AC (after successful boot with battery, kext loaded of course). Then, you can see in battery menu:

Batteries: None (ok, detected )

Power source: Battery ?!

(I discovered this after I launched some setup, and it said "need to be on AC to continue").

Ok thanks. I never noticed that the system still thinks its on battery when I did that test. This is surely a bug I should be able to hunt down and kill.

Hi,
thanks for your reply.

With "incorrect time" in power options i mean that if i set that system must go to sleep automatically after 10 minutes, it doesn't go to sleep at all after 10 minutes! I mean that... battery calculation is fixed using your latest release, you are right, but it doesn't solve the proper power management option that system goes to sleep automatically after X minutes set in power options. And it doesn't go to sleep automatically when battery is low... i guess both are due to the same reason... .that i do not know what it is.

USB and DVDROM are not working any more from sleep to hibernate very often when i change the source from ac-power to battery and vice-versa. Related to ACPIBattery too in your opinion?

I am using latest chameleon trunk... and latest taptun kernel for 10.6.6.

And i attach my DV8's dsdt here if you wanna give a look to it...(if you have time).

Thanks!

Mal

Yes, this is likely all the same issue in that the handle sleep/wake functions were removed from the code base I started with. Hopefully when I get that code put back in, the driver might play nicer with the Power Management layer...

JBraddock · March 2, 2011

Hi,
thanks for your reply.

With "incorrect time" in power options i mean that if i set that system must go to sleep automatically after 10 minutes, it doesn't go to sleep at all after 10 minutes! I mean that... battery calculation is fixed using your latest release, you are right, but it doesn't solve the proper power management option that system goes to sleep automatically after X minutes set in power options. And it doesn't go to sleep automatically when battery is low... i guess both are due to the same reason... .that i do not know what it is.

USB and DVDROM are not working any more from sleep to hibernate very often when i change the source from ac-power to battery and vice-versa. Related to ACPIBattery too in your opinion?

I am using latest chameleon trunk... and latest taptun kernel for 10.6.6.

And i attach my DV8's dsdt here if you wanna give a look to it...(if you have time).

Thanks!

Mal

Manmal, can you please do the following.

- Exit all applications which might prevent auto sleep.

- Delete com.apple.PowerManagement.plist from /Library/Preferences/SystemConfiguration

- Open System Preferences> Energy Saver and set your settings. This will create a new com.apple.PowerManagement.plist. Don't use Smart Sleep! It broke my power management.

- Restart OSX.

- Install "Please Sleep"

- Run the programme and see if it forces your laptop to sleep.

Besides, have tried auto sleep on your HP HDX?

In my case, auto sleep is working. I only once used Please Sleep and it made the laptop sleep. I am not using it anymore and still laptop goes to sleep automatically. So it seems that the recent DSDT changes not only did fix the black screen issue but also the auto sleep.

I haven't tried the low battery case but it wouldn't work I guess.

Yes, this is likely all the same issue in that the handle sleep/wake functions were removed from the code base I started with. Hopefully when I get that code put back in, the driver might play nicer with the Power Management layer...

You might have already fixed it but I am using Hardware Growler to see all kind of hardware notifications and yesterday it was reported that the battery level is 101% just before the charging is finished. It is a small bug I guess.

gsly · March 3, 2011

Hi,
thanks for your reply.

With "incorrect time" in power options i mean that if i set that system must go to sleep automatically after 10 minutes, it doesn't go to sleep at all after 10 minutes! I mean that... battery calculation is fixed using your latest release, you are right, but it doesn't solve the proper power management option that system goes to sleep automatically after X minutes set in power options. And it doesn't go to sleep automatically when battery is low... i guess both are due to the same reason... .that i do not know what it is.

USB and DVDROM are not working any more from sleep to hibernate very often when i change the source from ac-power to battery and vice-versa. Related to ACPIBattery too in your opinion?

I am using latest chameleon trunk... and latest taptun kernel for 10.6.6.

And i attach my DV8's dsdt here if you wanna give a look to it...(if you have time).

Thanks!

Mal

Looks like you need some additional work in your _GPE._L* methods to Notify the PWRB device and anything else you want woken up.

DO NOT COPY AND PASTE THE FOLLOWING as I have highly customized my DSDT, renamed a bunch of things, etc. so just use this as a reference to fix your own:

        // Devices WAKING: POP2, HDAU, POP3, PEGP, RP01, ARPT, RP02, GIGE, RP03, RP04, RP05, RP08, PXSX

       Method (_L09, 0, NotSerialized)
       {
           Notify (\_SB.PCI0.P0P2, 0x02)
           Notify (\_SB.PCI0.P0P2.HDAU, 0x02)
           Notify (\_SB.PCI0.P0P3, 0x02)
           Notify (\_SB.PCI0.P0P3.PEGP, 0x02)
           Notify (\_SB.PCI0.RP01, 0x02)
           Notify (\_SB.PCI0.RP01.ARPT, 0x02)
           Notify (\_SB.PCI0.RP02, 0x02)
           Notify (\_SB.PCI0.RP02.GIGE, 0x02)
           Notify (\_SB.PCI0.RP03, 0x02)
           Notify (\_SB.PCI0.RP04, 0x02)
           Notify (\_SB.PCI0.RP05, 0x02)
           Notify (\_SB.PCI0.RP08, 0x02)
           Notify (\_SB.PCI0.RP08.PXSX, 0x02)
           // Snow Leopard Fix
           Notify (\_SB.PWRB, 0x02)
       }

       // Devices WAKING: PCIB

       Method (_L0B, 0, NotSerialized)
       {
           Notify (\_SB.PCI0.PCIB, 0x02)
       }

       // Devices WAKING: EHC1, EHC2, HDEF

       Method (_L0D, 0, NotSerialized)
       {
           Notify (\_SB.PCI0.EHC1, 0x02)
           Notify (\_SB.PCI0.EHC2, 0x02)
           Notify (\_SB.PCI0.HDEF, 0x02)
           // Snow Leopard Fix
           Notify (\_SB.PWRB, 0x02)
       }

       // Device WAKING: USB1

       Method (_L03, 0, NotSerialized)
       {
           Notify (\_SB.PCI0.USB1, 0x02)
           // Snow Leopard Fix
           Notify (\_SB.PWRB, 0x02)
       }

       // Device WAKING: USB2

       Method (_L04, 0, NotSerialized)
       {
           Notify (\_SB.PCI0.USB2, 0x02)
           // Snow Leopard Fix
           Notify (\_SB.PWRB, 0x02)
       }

       // Device WAKING: USB3

       Method (_L0C, 0, NotSerialized)
       {
           Notify (\_SB.PCI0.USB3, 0x02)
           // Snow Leopard Fix
           Notify (\_SB.PWRB, 0x02)
       }

       // Device WAKING: USB4

       Method (_L0E, 0, NotSerialized)
       {
           Notify (\_SB.PCI0.USB4, 0x02)
           // Snow Leopard Fix
           Notify (\_SB.PWRB, 0x02)
       }

       // Device WAKING: USB5

       Method (_L05, 0, NotSerialized)
       {
           Notify (\_SB.PCI0.USB5, 0x02)
           // Snow Leopard Fix
           Notify (\_SB.PWRB, 0x02)
       }

       // Device WAKING: USB6

       Method (_L20, 0, NotSerialized)
       {
           Notify (\_SB.PCI0.USB6, 0x02)
           // Snow Leopard Fix
           Notify (\_SB.PWRB, 0x02)
       }

       // Device WAKING: USB7

       Method (_L25, 0, NotSerialized)
       {
           Notify (\_SB.PCI0.USB7, 0x02)
           // Snow Leopard Fix
           Notify (\_SB.PWRB, 0x02)
       }

       // Devices WAKING: ADP1, CIR0, PS2M, PS2K, FRWR

       Method (_L18, 0, NotSerialized)
       {
           Notify (\_SB.ADP1, 0x02)
           Notify (\_SB.PCI0.LPCB.CIR0, 0x02)
           Notify (\_SB.PCI0.LPCB.PS2M, 0x02)
           Notify (\_SB.PCI0.LPCB.PS2K, 0x02)
           Notify (\_SB.PCI0.RP05.FRWR, 0x00)
       }

You might have already fixed it but I am using Hardware Growler to see all kind of hardware notifications and yesterday it was reported that the battery level is 101% just before the charging is finished. It is a small bug I guess.

There is an error percentage (+-) returned from the Smart Battery subsystem that should be applied to any other sample data returned by SBS to limit any internal calculations like this, but the code currently doesn't use this because ACPI 3.x standard doesn't return this data.

The ACPI 4.x standard does include this in _BIX and my next release will support this, but alas the code isn't using it because I hadn't seen this situation before (my battery WILL perform differently than yours). Also, I believe the 101% is calculated by another layer of the system and not the battery driver as the driver just feeds data used to do that type of calculation up to the PM layer. However, if the error correction factor was applied to the data fed to PM, it might correctly calculate 100% or more than likely, 99%

Thanks for the Hardware Growler tip, I'll install that this weekend and see if it helps me any.

JBraddock · March 4, 2011

There is an error percentage (+-) returned from the Smart Battery subsystem that should be applied to any other sample data returned by SBS to limit any internal calculations like this, but the code currently doesn't use this because ACPI 3.x standard doesn't return this data.

The ACPI 4.x standard does include this in _BIX and my next release will support this, but alas the code isn't using it because I hadn't seen this situation before (my battery WILL perform differently than yours). Also, I believe the 101% is calculated by another layer of the system and not the battery driver as the driver just feeds data used to do that type of calculation up to the PM layer. However, if the error correction factor was applied to the data fed to PM, it might correctly calculate 100% or more than likely, 99%

Thanks for the Hardware Growler tip, I'll install that this weekend and see if it helps me any.

It looks promising. Thank you for your time again.

BTW, I am a PhD student in Human rights. So..

P.s: Look at this post to hide the dock icon of Hardware Growler.

manmal · March 5, 2011

Looks like you need some additional work in your _GPE._L* methods to Notify the PWRB device and anything else you want woken up.
DO NOT COPY AND PASTE THE FOLLOWING as I have highly customized my DSDT, renamed a bunch of things, etc. so just use this as a reference to fix your own:

[

Hi glsy, thanks for your advice, i will try adding such stuff in my dsdt adapting to my names.

Would you share your dsdt ? It's just for reference... I won't use it by myself but i will give a look if everything else looks like it should.

Another question... which bootloader are you using with dv8 ? and which kind of smbios.plist (MBP51,55,61,62,71)?

Thanks!

Mal

gsly · March 18, 2011

Hi glsy, thanks for your advice, i will try adding such stuff in my dsdt adapting to my names.
Would you share your dsdt ? It's just for reference... I won't use it by myself but i will give a look if everything else looks like it should.

Another question... which bootloader are you using with dv8 ? and which kind of smbios.plist (MBP51,55,61,62,71)?

Thanks!

Mal

Hi Mal. Someday I'll release my DSDT once I fully comment it and I'm happy with it. I've been learning all about DSDT and making all of the modifications myself from scratch (no auto patchers) so I understand how it all works and I'm to the point where I can read and write the stuff :wacko:

I'm using Merklot's Chameleon branch specifically for the kernel auto-patch function to fix the LAPIC BIOS, and I'm using MacBookPro6,2 for smbios.plist as that was the closest to my DV8 at the time, however I plan to look at the newer MBP (7,x and 8,x) models for details/hints/fixes soon.

gsly · March 19, 2011

Question: Does anyone have idle sleep (aka auto sleep) working?

Idle sleep is via the Energy Saver preferences timeouts and is different than forced sleep via the Apple "Sleep" menu. See this technical Q&A note for details:

http://developer.apple.com/library/mac/#qa...340/_index.html

The reason I ask is that I think the issue with auto sleep is not with the battery driver. After much testing and reading, I believe the issue is that some other driver or software on the system is canceling the auto sleep functionality (again, see note above).

The battery driver just reports battery status up to the power management (PM) layer and doesn't send any details telling the system to sleep. Normally a power policy maker, such as the Energy Saver preferences application defines a power policy that the PM layer implements, and its the PM layer that tells the system to sleep/power down. All drivers (kexts) that control a device that might consume power will hook themselves into the PM layer and they will receive messages when the system is about to auto sleep, etc. However, drivers can reply to this message and cancel auto sleep, but they cannot cancel forced sleep.

Its not clear to me yet what happens if a driver *doesn't* properly handle sleep messages but do hook into the PM layer. I suspect this type of driver would prevent the PM layer from sleeping the machine because it wouldn't send either a "yes, sleep the system" nor a "no, cancel sleep" reply to PM layer message and leave and outstanding hook into the PM layer.

Also, my research indicates this issue with auto sleep happens on real Macs too Another possibility might be that the DVD drive is not listed as "Apple Shipping Drive" in system profiler, but rather "Generic" and therefore the system doesn't know how to power it off. I do hear my DVD drive seeking/grinding after the display is turned off when auto sleep should happen, so there might be some merit to this.

Anyway, no solution yet but I've got many paths I can go down at the moment so its just a matter of trying to determine what will be the shortest to the end goal

juanerson · March 20, 2011

Hi gsly, thank you very much for your hard work. About "Apple Shipping Drive" (see this thread courtesy by Andy), but even applied, no luck with autosleep. Maybe you are right... about "how" or when to power it off automatically.

JBraddock · March 20, 2011

Question: Does anyone have idle sleep (aka auto sleep) working?

Idle sleep is via the Energy Saver preferences timeouts and is different than forced sleep via the Apple "Sleep" menu. See this technical Q&A note for details:

http://developer.apple.com/library/mac/#qa...340/_index.html

The reason I ask is that I think the issue with auto sleep is not with the battery driver. After much testing and reading, I believe the issue is that some other driver or software on the system is canceling the auto sleep functionality (again, see note above).

The battery driver just reports battery status up to the power management (PM) layer and doesn't send any details telling the system to sleep. Normally a power policy maker, such as the Energy Saver preferences application defines a power policy that the PM layer implements, and its the PM layer that tells the system to sleep/power down. All drivers (kexts) that control a device that might consume power will hook themselves into the PM layer and they will receive messages when the system is about to auto sleep, etc. However, drivers can reply to this message and cancel auto sleep, but they cannot cancel forced sleep.

Its not clear to me yet what happens if a driver *doesn't* properly handle sleep messages but do hook into the PM layer. I suspect this type of driver would prevent the PM layer from sleeping the machine because it wouldn't send either a "yes, sleep the system" nor a "no, cancel sleep" reply to PM layer message and leave and outstanding hook into the PM layer.

Also, my research indicates this issue with auto sleep happens on real Macs too Another possibility might be that the DVD drive is not listed as "Apple Shipping Drive" in system profiler, but rather "Generic" and therefore the system doesn't know how to power it off. I do hear my DVD drive seeking/grinding after the display is turned off when auto sleep should happen, so there might be some merit to this.

Anyway, no solution yet but I've got many paths I can go down at the moment so its just a matter of trying to determine what will be the shortest to the end goal

I have auto sleep working both on battery and power cord. Today, I used OSX on battery and it gave me the low battery warning at some point. I waited until two minutes was left but it didn't appear to be going into sleep (it wasn't in idle I went on using it) so I put it into sleep manually. I'll test it again and wait till the end :blowup:

It is true that auto sleep is complicated I have only got it working recently when I applied various DSDT fixes that might have affected sleep i.e black screen on wake when sleep mode 3 is used, Sata fixes that prevent HDX from waking up etc. and also started to use some new kexts. But I don't really know what made the trick. Finally, my blue-ray drive is also seen as Generic and yet, it is true that some DVD drives prevent sleep.

This is irrelevant but I started to use 64 bit and at first, OSX felt more snappy but I thought it was just a placebo effect then I ran Geekbench 64 bit and it amazes me that there has been ~400 points difference in GeekBench score in my case. I always thought that it wouldn't make that difference. Lesson learn. It does.

Do let me know if you want me to test anything apart from the one I mentioned above.

P.S: Your last sentence reminded me of the poem of Robert Frost "The Road Not Taken"

manmal · April 2, 2011

hi glsy!

any news on ACPIBattery to behave like real macs (expecially letting system go to sleep when battery is low-level) ?

Plz let us know ...

Thanks!

Mal

3.14r2 · April 28, 2011

Reporting success with HP Pavilion DV1660se notebook. It is the first kext to work properly! I suspect the DSDT edit was very useful too.

Both battery and AC adapter are detected properly (with a slight delay though ~1min). Charge calculations are also shown properly (like in Windows/Linux).

Sleep doesn't work as it did before... Not a big deal though

Thank you very much!!!

JBraddock · May 17, 2011

I don't know if guys also noticed this, iStat Pro doesn't detect battery by default. There is patched version of iStat Pro by Slice, which detects it. I was wondering if does this give a clue about the power loss on battery. May be OS X doesn't detect the battery as the way it should be. It might've stated the obvious

Thank you,

gsly · May 17, 2011

I don't know if guys also noticed this, iStat Pro doesn't detect battery by default. There is patched version of iStat Pro by Slice, which detects it. I was wondering if does this give a clue about the power loss on battery. May be OS X doesn't detect the battery as the way it should be. It might've stated the obvious

Thank you,

I had a look at what Slice changed although it wasn't easy because the latest unchanged version is newer and much different, but I saw what I suspected. It was the same issue I had with coconutBattery.

In the latter case, coconutBattery queries the IO registry for battery information (in this app, by running a script and parsing the output I suspect) using the value AppleSmartBattery. As the driver in this thread is based on an old Apple driver, the same classes are used so the battery information gets put under the AppleACPIBattery tree. Hence, coconutBattery doesn't see a battery in my Hackintosh.

I believe Slice just patched "AppleSmartBattery" to "AppleACPIBattery " (note the latter is smaller by one character) so iStatPro would be able to find the values.

I do recall looking into this by searching for AppleSmartBattery in the Extensions binaries and a few other locations to see in any parts of the system were hardwired like this but perhaps I should revisit this path.

JBraddock · June 8, 2011

I had a look at what Slice changed although it wasn't easy because the latest unchanged version is newer and much different, but I saw what I suspected. It was the same issue I had with coconutBattery.

In the latter case, coconutBattery queries the IO registry for battery information (in this app, by running a script and parsing the output I suspect) using the value AppleSmartBattery. As the driver in this thread is based on an old Apple driver, the same classes are used so the battery information gets put under the AppleACPIBattery tree. Hence, coconutBattery doesn't see a battery in my Hackintosh.

I believe Slice just patched "AppleSmartBattery" to "AppleACPIBattery " (note the latter is smaller by one character) so iStatPro would be able to find the values.

I do recall looking into this by searching for AppleSmartBattery in the Extensions binaries and a few other locations to see in any parts of the system were hardwired like this but perhaps I should revisit this path.

Hello gsly,

Thank you for this detailed response.

Recently, I experienced power loss on low battery and now my battery is being reported as service battery, which is another way of saying that "I am dying" :blink: . I guess it was just trigger as I was already expecting such a thing.

It's been more than two years so it will die eventually.

I know Lion is not out yet but any chance you've tried the kext on Lion?

What is the current situation of the development both on Lion and Snow Leopard?

Thanks,

HP DVx AppleACPIBatteryManager Driver

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites