Jump to content

HP DVx ACPI 3.x/4.x Battery Driver (10.6/10.7)


  • Please log in to reply
227 replies to this topic

#161
gsly

gsly

    InsanelyMac Geek

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

Sorry if I 'push' things, a simple upload here will do just fine.
I was hopping to take a look before I will trash this laptop...

Thanks.

Sorry about that THe KiNG, been busy. I figured out the setup for github and uploaded the source code there and updated the original post with the link.

#162
THe KiNG

THe KiNG

    InsanelyMac Legend

  • Retired Developers
  • 791 posts
  • Gender:Male

Sorry about that THe KiNG, been busy. I figured out the setup for github and uploaded the source code there and updated the original post with the link.

Thanks!

#163
BugsB

BugsB

    InsanelyMac Deity

  • Members
  • PipPipPipPipPipPipPipPipPipPip
  • 1,513 posts
  • Gender:Male
  • Location:Kauai, Hawai'i
why not include patches known to be required for Hackbooks into Apple's PowerManagement Sources as has been done before (last time I know of in Leopard) instead of all this complicated DSDT stuff, which in addition is different for each Laptop .. ?? The modded PM.bundle worked so well back then in all sorts of mobile PCs ..

#164
gsly

gsly

    InsanelyMac Geek

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

why not include patches known to be required for Hackbooks into Apple's PowerManagement Sources as has been done before (last time I know of in Leopard) instead of all this complicated DSDT stuff, which in addition is different for each Laptop .. ?? The modded PM.bundle worked so well back then in all sorts of mobile PCs ..

Each laptop's interface to it's battery subsystem will be different so there is no way to support every laptop without system specific code, in this case at the DSDT level. This is what the DSDT is all about. The ACPI standard provides a way to return that manufacturer specific hardware data and this driver then passes that information to the PM system. In fact, the battery driver here replaces a portion of the PM bundle (AppleSmartBatteryDriver) so we are in fact doing what you mention.

#165
apramorbis

apramorbis

    InsanelyMac Protégé

  • Members
  • Pip
  • 3 posts
Could be useful to some: When just the _BIF method is used the empty ManufacturerData that's set by the kext seems to be what causes the System Profiler's Power section to fail. Commenting out that line fixed it for me.

#166
gsly

gsly

    InsanelyMac Geek

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

Could be useful to some: When just the _BIF method is used the empty ManufacturerData that's set by the kext seems to be what causes the System Profiler's Power section to fail. Commenting out that line fixed it for me.

Thanks for the detail, it sounds like a bug that should be fixable and something I hadn't tested (in a while). What OSX version was this?

#167
alianyn

alianyn

    InsanelyMac Protégé

  • Members
  • Pip
  • 20 posts
  • Gender:Male
  • Location:Israel
First and foremost, thanks @gsly for this really wonderful and informative work, and all the time you've dedicated to this.

Thanks also goes to Jingu & 18seven for adapting this to Asus laptops (which i am also an owner of).

I'm encountering a very strange problem - which no one else has reported, so i'm assuming it's something i'm doing wrong.
No matter how i play with the info.plist inside the kext - i can't get it to use _BIF, only _BIX
I always get this in the kernel log:

Jun 13 15:52:04 localhost kernel[0]: AppleSmartBattery: Using ACPI extended battery information method _BIX


I've tried setting UseExtendedBatteryInformationMethod & UseExtraBatteryInformationMethod to false (both as booleans and as strings), but the result is always the same.

Since no one else is reporting this - i'm assuming it's some stupid mistake i'm making, but i'll take my chances and post the kext i'm using (i put it in S/L/E - replacing the original) - can anyone help?

Attached Files



#168
apramorbis

apramorbis

    InsanelyMac Protégé

  • Members
  • Pip
  • 3 posts

Thanks for the detail, it sounds like a bug that should be fixable and something I hadn't tested (in a while). What OSX version was this?


It was 10.7.4
Also fixed up the kext for watt mode somewhat.
Works pretty well with my thinkpad using mostly original DSDT battery code (as far as the actual battery values). Do have some ugly hacks in place for the strings though.

Posted Image


Thanks for making this and releasing the source :)

Attached Files



#169
apramorbis

apramorbis

    InsanelyMac Protégé

  • Members
  • Pip
  • 3 posts

...

Since no one else is reporting this - i'm assuming it's some stupid mistake i'm making, but i'll take my chances and post the kext i'm using (i put it in S/L/E - replacing the original) - can anyone help?


You appear to have redeclared the keys. You can find the ones being used under the IOKitPersonalities. Both are set to true.
Deleting the ones you added and setting those to false should do it.

#170
alianyn

alianyn

    InsanelyMac Protégé

  • Members
  • Pip
  • 20 posts
  • Gender:Male
  • Location:Israel

You appear to have redeclared the keys. You can find the ones being used under the IOKitPersonalities. Both are set to true.
Deleting the ones you added and setting those to false should do it.

Thanks @apramobis - that's so embaracing... was going nuts here, though what i ended up doing was open the source code and hard code it to work with _BIF.

#171
gsly

gsly

    InsanelyMac Geek

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

It was 10.7.4
Also fixed up the kext for watt mode somewhat.
Works pretty well with my thinkpad using mostly original DSDT battery code (as far as the actual battery values). Do have some ugly hacks in place for the strings though.

Thanks for making this and releasing the source :)

Thanks aprmorbis for revising the watts related code, when I get some time I'll integrate your changes into the code base as well as fix that bug with the manufacturer data. The original code I used as a base had the watts code commented out, but I really can't test it on my laptop (uses amps) but it should be included as the ACPI standard supports and allows it. I should be able to test the manufacturer data bug though as I've updated to 10.7.4 recently but I haven't reinstalled this battery kext yet as I wanted to play around with my next idea for getting the native Apple battery driver to work via DSDT changes only. :moil:

#172
alianyn

alianyn

    InsanelyMac Protégé

  • Members
  • Pip
  • 20 posts
  • Gender:Male
  • Location:Israel
Reverted back to using the gsly's kexts (changed the correct parameters) and made the changes to the dsdt.
Now i have both percentage AND estimated times showing correctly (yay)

BUT when i go to the "about this mac" power descriptor - i get "there was an error while gathering this information".

Attached File  Screen Shot 2012-06-14 at 17.27.04 .png   131.63KB   17 downloads


kernel log:
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryManager: Version 2011.0802 starting
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryManager: Battery Supported Count(s) 1.
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice: Using ACPI regular battery information method _BIF
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice::clearBatteryState: do_update = false
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryManager::setPowerState: which = 0x1
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice::rebuildLegacyIOBatteryInfo called
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice::pollBatteryState: path = 0x2
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice::pollBatteryState: path = 0x1
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryManager::getBatterySTA called
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice::setBatterySTA: battery_status = 0x1f
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryManager::getBatteryBIF called
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice::setBatteryBIF: acpibat_bif size = 13
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryManager::getBatteryBST called
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice::setBatteryBST: acpibat_bst size = 4
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice::setBatteryBST: fPowerUnit	   = 0x1
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice::setBatteryBST: currentStatus    = 0x1
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice::setBatteryBST: fCurrentRate	 = 0x758
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice::setBatteryBST: fCurrentCapacity = 0x981
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice::setBatteryBST: fCurrentVoltage  = 0x37b2
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice::setBatteryBST: fAverageRate = 0x758
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice: Battery is discharging.
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice::constructAppleSerialNumber called
14/06/12 5:07:00.000 PM kernel: AppleACPIBatteryDevice::rebuildLegacyIOBatteryInfo called


#173
gsly

gsly

    InsanelyMac Geek

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

Reverted back to using the gsly's kexts (changed the correct parameters) and made the changes to the dsdt.
Now i have both percentage AND estimated times showing correctly (yay)

BUT when i go to the "about this mac" power descriptor - i get "there was an error while gathering this information".

This sounds like the bug with Manufacturer data being blank that apramorbis reported. I've added this to the issues list on github and I might be able to look into this on the weekend.

#174
alianyn

alianyn

    InsanelyMac Protégé

  • Members
  • Pip
  • 20 posts
  • Gender:Male
  • Location:Israel

This sounds like the bug with Manufacturer data being blank that apramorbis reported. I've added this to the issues list on github and I might be able to look into this on the weekend.

How can i find out which data is missing? is it something in the _BIF package? i'd like to try and fix it in the dsdt.

[EDIT:] i just noticed it's something in the driver. just to check, i switched back to the default appleacpibattery kext - and it happens there as well - so i'm guessing it's something that's in the code of the original driver as well? or is it something i can add to the _BIF method? or another method?

[EDIT #2:]can anyone also explain the difference between AppleAcpiBatteryManager(AAPM) & AppleSmartBatteryManager(ASBM)? is ASBM the older one? or is the one being loaded dependent on some dsdt naming convention? or is dependent on smbus/ec? i could not find any details on this anywhere.

Edited by alianyn, 15 June 2012 - 01:52 AM.


#175
gsly

gsly

    InsanelyMac Geek

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

How can i find out which data is missing? is it something in the _BIF package? i'd like to try and fix it in the dsdt.

[EDIT:] i just noticed it's something in the driver. just to check, i switched back to the default appleacpibattery kext - and it happens there as well - so i'm guessing it's something that's in the code of the original driver as well? or is it something i can add to the _BIF method? or another method?

[EDIT #2:]can anyone also explain the difference between AppleAcpiBatteryManager(AAPM) & AppleSmartBatteryManager(ASBM)? is ASBM the older one? or is the one being loaded dependent on some dsdt naming convention? or is dependent on smbus/ec? i could not find any details on this anywhere.

I have confirmed that the issue in 10.7.4 is an issue with the driver when using the ACPI standard _BIF and _BIX standard. When using these, the driver sets the Manufacturer data to an empty array as its not part of the ACPI standard and it looks like 10.7.4 doesn't like this (I believe it was fine previously). As the manufacturer data is highly dependent on the battery controller used in the battery, I think the best solution is to remove the setting of this attribute. Although my current battery returns some data from this API call, I don't really know what it means as I haven't been able to find a datasheet for it. Also, whatever controller(s) Apple is using returns specific information that System Profiler uses for the Pack Lot Code, PCB Lot Code, Firmware Revision, Hardware Revision and Cell Revision fields. Other controllers would likely not return the same information.

In terms of this driver, the original code base was AppleACPIBatteryManager. There are several 3rd party battery related applications that expect to find the battery data under the AppleSmartBatteryManager I/O registry entry as that is where the vanilla Apple driver places it. I simply renamed all of the classes/references to match the Apple driver and magically, all (ones I've tested) of the 3rd party applications now work with this driver. Search this thread for more details.

#176
alianyn

alianyn

    InsanelyMac Protégé

  • Members
  • Pip
  • 20 posts
  • Gender:Male
  • Location:Israel
Thanks @gsly, from what i can see in the code for the driver, this is not something fixable by dsdt. i can see that these 2 lines are both in the _BIF and _BIX methods of the driver:
fManufacturerData = OSData::withCapacity(10);
setManufacturerData((uint8_t *)fManufacturerData, fManufacturerData->getLength());

do you know in the original apple code - which method is being used? and if so what kind of package does it return? perhaps it would be easier to return a similar package with some of the data having generic non-descript values?

on the matter of the kexts - i apologize but i did not understand, or failed to communicate my question:
1. is the applesmartbattery the newer standard?
2. how does osx determine which of the drivers is being loaded? or are they both loaded? if i use both your kexts i only see messages from appleacpibatterymanager, but if i delete that kext, i can see messages from applesmartbattery. just trying to figure out how stuff works... sorry if i am still not clear...

#177
gsly

gsly

    InsanelyMac Geek

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

Thanks @gsly, from what i can see in the code for the driver, this is not something fixable by dsdt. i can see that these 2 lines are both in the _BIF and _BIX methods of the driver:

fManufacturerData = OSData::withCapacity(10);
setManufacturerData((uint8_t *)fManufacturerData, fManufacturerData-&--#62;getLength());

do you know in the original apple code - which method is being used? and if so what kind of package does it return? perhaps it would be easier to return a similar package with some of the data having generic non-descript values?

Yes, those are the lines causing the issue. As the ACPI standard doesn't include this data, I'm (incorrectly) setting this attribute to an empty array which you can see if you look in the IO registry:


$ ioreg -w0 -n AppleSmartBattery -r AppleSmartBattery
+-o AppleSmartBattery  &--#60;class AppleSmartBattery, id 0x1000001e1, registered, matched, active, busy 0 (0 ms), retain 5&--#62;
    {
      "ExternalConnected" = Yes
      "TimeRemaining" = 65535
      "InstantTimeToEmpty" = 65535
      "ExternalChargeCapable" = Yes
      "CellVoltage" = (4142,4142,4142,4144)
      "PermanentFailureStatus" = 0
      "BatteryInvalidWakeSeconds" = 30
      "AdapterInfo" = 0
      "MaxCapacity" = 6524
      "Voltage" = 16570
      "Quick Poll" = No
      "Manufacturer" = "SMP-SS26"
      "Location" = 0
      "CurrentCapacity" = 6524
      "LegacyBatteryInfo" = {"Amperage"=0,"Flags"=5,"Capacity"=6524,"Current"=6524,"Voltage"=16570,"Cycle Count"=5}
      "FirmwareSerialNumber" = 210177
      "BatteryInstalled" = Yes
      "CycleCount" = 5
      "AvgTimeToFull" = 65535
      "DesignCapacity" = 6600
      "ManufactureDate" = 0
      "BatteryType" = "LION"
      "BatterySerialNumber" = "ALIEN-33501"
      "InstantTimeToFull" = 65535
      "PostDischargeWaitSeconds" = 120
      "Temperature" = 0
      "InstantAmperage" = 0
      "ManufacturerData" = &--#60;&--#62;
      "MaxErr" = 12288
      "FullyCharged" = Yes
      "DeviceName" = "ALIEN"
      "IOGeneralInterest" = "IOCommand is not serializable"
      "Amperage" = 0
      "IsCharging" = No
      "PostChargeWaitSeconds" = 120
      "AvgTimeToEmpty" = 65535
    }

The problem is that Apple must have added some length checks to System Profiler in 10.7.4 that is now causing it to fail when it sees the the empty ManufacturerData field. You can see the current Apple code here http://opensource.ap...martBattery.cpp

Look at kBManufactureDataCmd and you can see there is no defined "package" returned as in ACPI, its just a bunch of bytes.

on the matter of the kexts - i apologize but i did not understand, or failed to communicate my question:
1. is the applesmartbattery the newer standard?
2. how does osx determine which of the drivers is being loaded? or are they both loaded? if i use both your kexts i only see messages from appleacpibatterymanager, but if i delete that kext, i can see messages from applesmartbattery. just trying to figure out how stuff works... sorry if i am still not clear...

Although this is before my time in the Hackintosh community, I believe Apple originally used the ACPI method and later switched to the Smart Battery method (see above link). The ACPI standard hides the low-level hardware interface methods to the battery information from the operating system whereas the newer Apple Smart method is talking directly to the SMBus to get battery information. ACPI also provides interfaces to the SMBus so IMHO, Apple is doing it incorrectly.

In the case of Apple's current driver, it talks to the SMBus to query the battery using the SBS standard. In the case of this driver (ACPI or Smart), it uses the Plug and Play (PNP) ID configured in the Info.plist, in this case PNP0C0A, to attach to the correct device in ACPI which is usually Device BAT0 but can the device can be named anything as its the PNP ID that is unique.

I suspect you have both versions of THIS driver installed and yes, they would both tie themselves to the ACPI battery device. Use the "kextstat" command in terminal to see what drivers are loaded.

#178
wadalada

wadalada

    InsanelyMac Protégé

  • Members
  • Pip
  • 3 posts
gsly,

I am very interested in porting this to HP Probook 6560b and SONY VPCSE laptops. Using your kext, the battery is detected less than 40% of time during boot up. I don't know what's causing the battery not to be detected the rest of the time. All I changed was the 16 to 8 bit DSDT mod. Any suggestion would be greatly appreciated. I will post the original battery codes if you have time to quickly glance at them for me.

Thanks,

wadalada

#179
gsly

gsly

    InsanelyMac Geek

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

gsly,

I am very interested in porting this to HP Probook 6560b and SONY VPCSE laptops. Using your kext, the battery is detected less than 40% of time during boot up. I don't know what's causing the battery not to be detected the rest of the time. All I changed was the 16 to 8 bit DSDT mod. Any suggestion would be greatly appreciated. I will post the original battery codes if you have time to quickly glance at them for me.

Thanks,

wadalada

That sounds weird. There is probably some other DSDT related item that causing this, perhaps a 16-bit reference that is only called occasionally? Post the original and modified DSDT and I'll have a look, but no promises on a solution as I can only guess without the actual hardware.

#180
wadalada

wadalada

    InsanelyMac Protégé

  • Members
  • Pip
  • 3 posts
gsly,

It is great that you have offered to review my DSDTs. That is all I can hope for. Please see the attached zip file.

Thanks again,

wadalada

Attached File  battery_for_gsly.zip   133.15KB   10 downloads





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