Jump to content

HP DVx AppleACPIBatteryManager Driver


  • Please log in to reply
73 replies to this topic

#21
JBraddock

JBraddock

    Ph.D (Can) in Human Rights

  • Members
  • PipPipPipPipPipPipPip
  • 549 posts
  • Location:UK

AppleACPIBatteryManager with your DSDT mod works great on my system, thanks for that mate,
have just one issue and wonder if you could help - after unplugging AC adapter I have about 10-15sec delay from system to switch to battery icon and dim the display, when plugging back AC adapter icon change and display lit up is almost instant.
any ideas ?

Slightly off topic but may I ask you what kind of hacks did you use to get the display dimming working?

#22
Pasa Yildirim

Pasa Yildirim

    InsanelyMac Protégé

  • Members
  • Pip
  • 49 posts

Slightly off topic but may I ask you what kind of hacks did you use to get the display dimming working?


You need DSDT injection (Nvidia). Just use GraphicsEnabler and inject missing values, like display-cfg, EDID and powermgmt :( Then you'll get brightness control and dimming as a gratis :blink:

#23
JBraddock

JBraddock

    Ph.D (Can) in Human Rights

  • Members
  • PipPipPipPipPipPipPip
  • 549 posts
  • Location:UK

You need DSDT injection (Nvidia). Just use GraphicsEnabler and inject missing values, like display-cfg, EDID and powermgmt :( Then you'll get brightness control and dimming as a gratis :(

Thans for the reply. I sent you a PM in order not to invade this thread. :blink:

#24
gsly

gsly

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 142 posts
  • Gender:Male
  • Location:The Great White North

Hi 'gsly'

AppleACPIBatteryManager with your DSDT mod works great on my system, thanks for that mate,

have just one issue and wonder if you could help - after unplugging AC adapter I have about 10-15sec delay from system to switch to battery icon and dim the display, when plugging back AC adapter icon change and display lit up is almost instant.

any ideas ?

thanks
s

The driver polls/samples the battery status at a regular interval. It defaults to 30 seconds and 1 second when the battery is low. You can see this if you install the debug version and watch the kernel.log with "tail -f" or Console app.

You can override the polling internal by setting the key "BatteryPollingPeriodOverride" in the info.plist to the number of seconds you want the driver to check the battery.

#25
sw170

sw170

    InsanelyMac Geek

  • Members
  • PipPipPipPip
  • 212 posts
  • Gender:Male
  • Location:UK

The driver polls/samples the battery status at a regular interval. It defaults to 30 seconds and 1 second when the battery is low. You can see this if you install the debug version and watch the kernel.log with "tail -f" or Console app.

You can override the polling internal by setting the key "BatteryPollingPeriodOverride" in the info.plist to the number of seconds you want the driver to check the battery.


that made the trick, thanks a million gsly !

#26
JBraddock

JBraddock

    Ph.D (Can) in Human Rights

  • Members
  • PipPipPipPipPipPipPip
  • 549 posts
  • Location:UK
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.

#27
gsly

gsly

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 142 posts
  • Gender:Male
  • Location:The Great White North

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...

#28
JBraddock

JBraddock

    Ph.D (Can) in Human Rights

  • Members
  • PipPipPipPipPipPipPip
  • 549 posts
  • Location:UK

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 :(

#29
manmal

manmal

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 437 posts
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

#30
gsly

gsly

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 142 posts
  • Gender:Male
  • Location:The Great White North

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 :D

#31
Pasa Yildirim

Pasa Yildirim

    InsanelyMac Protégé

  • Members
  • Pip
  • 49 posts
@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.

#32
manmal

manmal

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 437 posts

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 :gun:


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

#33
gsly

gsly

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 142 posts
  • Gender:Male
  • Location:The Great White North

@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.

#34
Pasa Yildirim

Pasa Yildirim

    InsanelyMac Protégé

  • Members
  • Pip
  • 49 posts
#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").

#35
gsly

gsly

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 142 posts
  • Gender:Male
  • Location:The Great White North

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.

#36
manmal

manmal

    InsanelyMac Sage

  • Members
  • PipPipPipPipPipPip
  • 437 posts

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

Attached Files



#37
gsly

gsly

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 142 posts
  • Gender:Male
  • Location:The Great White North

#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 :D)
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...

#38
JBraddock

JBraddock

    Ph.D (Can) in Human Rights

  • Members
  • PipPipPipPipPipPipPip
  • 549 posts
  • Location:UK

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.

#39
gsly

gsly

    InsanelyMac Geek

  • Members
  • PipPipPip
  • 142 posts
  • Gender:Male
  • Location:The Great White North

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.

#40
JBraddock

JBraddock

    Ph.D (Can) in Human Rights

  • Members
  • PipPipPipPipPipPipPip
  • 549 posts
  • Location:UK

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.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

© 2014 InsanelyMac  |   News  |   Forum  |   Downloads  |   OSx86 Wiki  |   Mac Netbook  |   PHP hosting by CatN  |   Designed by Ed Gain  |   Logo by irfan  |   Privacy Policy