You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Oct 12, 2018. It is now read-only.
Tachometer key names in the Info.plist for ACPISensors.kext are wrong for what the code expects because of the special way tachometers are added as sensors internally. The end result is that if you have any ACPI tachometers (fans), you will get a KP as soon as the menu extra accesses them.
The problem is they are in the Info.plist as FANx, where 'x' is hex digit. But the code expects them to be FxAc, where 'x' is hex digit. This means the look up in the dictionary KPs when ACPISensors::getSensorValue is called for kFakeSMCTachometerSensor.
The fix I implemented in my fork is to change the Info.plist key values to match what the code is expecting, for example for first fan, F0Ac. Location of fork: https://github.com/RehabMan/HWSensors
The text was updated successfully, but these errors were encountered:
Also to figure out... is how this addTachometer thing works when you have tachs being added from PTIDSensors object and from the ACPISensors object.
I've found that my system (HP 4530s) will not make it to the login screen if using Kernel Cache and if PTIDSensors is enabled in ACPISensors.kext/Contents/Info.plist. So, if I set IONameMatch for PTID Device Monitoring Plugin to "xPTID" it disables that object from starting and I'm able to boot with or without Kernel Cache. I have a feeling that there is some order dependency here, and that the order gets reversed in the case of Kernel Cache... at least on my laptop. Booting with "-f" also works. Either that, or there is a race condition (are calls to ::start guaranteed to be serialized?)
For the HP 4530s it doesn't make much sense to include the PTIDSensor because it duplicates tachometers already available from DSDT code as part of the normal ACPISensors "Sensors Configuration/Default"
Fixed It, try latest rev. I made some changes - you can't now use SMC keys directly but you can use unified sensor names like in LPCSensors: CPU, System, Northbridge, PCH etc.
Verified fix. I noticed you fixed where the code was using the method name instead of the original key to lookup the fan names (I thought that was a little strange). Thanks!
Tachometer key names in the Info.plist for ACPISensors.kext are wrong for what the code expects because of the special way tachometers are added as sensors internally. The end result is that if you have any ACPI tachometers (fans), you will get a KP as soon as the menu extra accesses them.
The problem is they are in the Info.plist as FANx, where 'x' is hex digit. But the code expects them to be FxAc, where 'x' is hex digit. This means the look up in the dictionary KPs when ACPISensors::getSensorValue is called for kFakeSMCTachometerSensor.
The fix I implemented in my fork is to change the Info.plist key values to match what the code is expecting, for example for first fan, F0Ac. Location of fork: https://github.com/RehabMan/HWSensors
The text was updated successfully, but these errors were encountered: