Jump to content

viking1304

Members
  • Content Count

    143
  • Joined

  • Last visited

  • Days Won

    4

viking1304 last won the day on November 25

viking1304 had the most liked content!

Community Reputation

14 Good

About viking1304

  • Rank
    Staff Sergeant

Profile Information

  • Gender
    Male

Recent Profile Visitors

297 profile views
  1. viking1304

    DW5809e: how can i use the WWAN?

    @Darius1984 there is no need to change anything in kext that works in High Sierra to make it work in Mojave. 1. You need to change USBCOMP mode to 6, 8 or 14 to make it work in MacOS. If you are using dual boot with Windows use USBCOMP 14. I did that from persistent Ubuntu USB using perl script. 2. Since I saw in another thread that you have same card as me, you can use this kext vkgLegacySierraQMI.kext.zip 3. Be sure that your system can access your card properly. I had problems with this in the beginning. Check USB / USB Device Tree and Network / WWAN in System Information. You can use AT commands from your terminal like this.
  2. Since I was getting RAW values with VirtualSMC and didn't with FakeSMC I jumped to conclusion that you are using FakeSMC. Are you just replacing AML files in patched folder and config or you also replacing some kexts when switching from hot-patched to static config?
  3. You don't see those values because you are using FakeSMC.kext and ACPIBatteryManager.kext, but that is not an issue here. Values that you are getting from command line are same as those from Coconut. I made a test with ACPIBatteryManager. First I checked Coconut: And few seconds later I checked ioreg from terminal: dragon:~ viking$ ioreg -w0 -l | grep "Capacity" | | | "Configuration" = {"Correct16bitSignedCurrentRate"=Yes,"UseDesignVoltageForDesignCapacity"=Yes,"EstimateCycleCountDivisor"=6,"UseExtraBatteryInformationMethod"=Yes,"UseDesignVoltageForMaxCapacity"=Yes,"UseExtendedBatteryInformationMethod"=Yes,"CorrectCorruptCapacities"=Yes,"StartupDelay"=0,"FirstPollDelay"=4000,"CurrentDischargeRateMax"=20000,"UseDesignVoltageForCurrentCapacity"=Yes} | | "MaxCapacity" = 5527 | | "CurrentCapacity" = 3341 | | "LegacyBatteryInfo" = {"Amperage"=18446744073709550173,"Flags"=4,"Capacity"=5527,"Current"=3341,"Voltage"=7601,"Cycle Count"=188} | | "DesignCapacity" = 6660 dragon:~ viking$ And that is perfectly fine since there was a few seconds difference. 3353 is 60.66582232676% of 5527. 3341 is 60.448706350642% of 5527. So, Coconut and ioreg are in sync. So everything looks fine, but... iStatMenus showed this: And same (wrong) percentage was displayed by OS: Since those values are higher than real ones, there are only two potential reasons: 1. one of two values (or even both) used for calculation that system gets are wrong - but this is almost impossible since ioreg values are correct 2. system gets result with delay - is even more problematic to comprehend the possible reason for this @Jake Lo I am totally confused now, since you wrote that you noticed this difference even with VirtualSMC. I will revert VirtualSMC and repeat those tests again.
  4. I don't see this issue on my system (E7450 + VirtualSMC + SMCBatteryManager). dragon:~ viking$ ioreg -w0 -l | grep "Capacity" | "AppleRawCurrentCapacity" = 1194 | "AppleRawMaxCapacity" = 5456 | "MaxCapacity" = 5456 | "CurrentCapacity" = 1194 | "LegacyBatteryInfo" = {"Amperage"=18446744073709549617,"Flags"=4,"Capacity"=5456,"Current"=1194,"Voltage"=7366,"Cycle Count"=0} | "DesignCapacity" = 6660 | "BatteryData" = {"StateOfCharge"=5376,"Voltage"=7366,"QmaxCell1"=0,"ResScale"=0,"QmaxCell2"=0,"QmaxCell0"=0,"CycleCount"=0,"DesignCapacity"=6660} As you can see MaxCapacity is same as AppleRawMaxCapacity and CurrentCapacity is same as AppleRawCurrentCapacity. Since there is no difference, it's expected to get same results whatever value is used. There might be slight difference because of different number rounding rules. In this example 1194 is 21.8841642228739 percent of 5456. CoconutBattery: iStatMenus: macOS: Looks like Cycle Count and Battery Temperature are always 0 with virtualSMC. Coconut wrongly displays absolute zero when it reads 0 value for temperature.
  5. viking1304

    E7240-Mojave Installation Guide Needed

    Yes, you can modify EFI partition form Linux or Windows (but be careful). Windows saved me from bricked macOS few times while doing some crazy experiments with my config and kexts. Try with this EFI folder. Completely remove CLOVER, APPLE and BOOT folders from your EFI partition and use those. You should be able to see your APFS partition and probably to boot your system. I replaced your Clover files and removed some things that you probably don't need from drivers64UEFI folder. I also replaced your config and kexts with those that Jake sent you. EFI_theeama_jakes_conf.zip I haven't checked your config, but if you were using config that Jake posted to you with kext that you had, that was doomed from start. Jake posted correct kexts needed by his config, so you need both of those. EDIT: Almost forgot, please update your signature with your system specs in order to get better support in the future.
  6. viking1304

    DW5630 (EVDO-HSPA) Mobile Broadband Mini-Card

    You modified 3 files from /S/L/E and 1 modem script to accomplish something that you probably cold done with just one additional codeless kext in /L/E (without any modification of system files). I modified my kext for another Sierra model to mach your ID. I also modified InterfaceMapping to mach the one you posted. vkgDellWireless5630_dim.kext.zip If you want, restore original files that you modified and try to connect with this kext in /L/E instead.
  7. viking1304

    E7450 macOS 10.14.1: battery and wake issue

    You need to disable hibernation or you can try HibernationFixup. Easiest way to reenable hibernation is to use Restore Defaults button in Energy Saver in System Preferences.
  8. You need VirtualSMC.kext and SMCBatteryManager.kext. You can install other SMC* kexts if you want. They are not essential but will make your sensors available to monitoring apps. Just do not use Rehabman's HWMonitor.app with VirtualSMC. Use HWMonitorSMC2.app instead. Same apply for FakeSMC.kext and ACPIBatteryManager.kext. Those two are needed, others are optional. You do not need DisableTurboBoostBattery.kext on EFI partition. It works just fine from /L/E. Just do not forget to fix permissions and rebuild cache.
  9. viking1304

    E7450 macOS 10.14.1: battery and wake issue

    Install VoodooPS2Controller-R6Bronxteck.kext.zip and find your ALPS version with log show | grep ALPS You will have much better idea what to do then. If you have v7 or newer you will probably need to use ApplePS2Controller.kext, since VoodooPS2Controller can't properly handle them. Cursor movement is jumpy and sluggish. Gestures are mixed and not working as expected. ApplePS2Controller works much better with v7 then VoodooPS2Controller. Cursor movement is much faster with this one. Scrolling with two fingers works fine, but it's slightly jumpy. This can be a lot smoother if you install MOS. Based on comments, older ALPS versions should work very good with VoodooPS2Controller, including gestures. Jake should have much better overview, since he have few different Dell laptops with different touch pads.
  10. You can easily modify VRAM size from your config. Just change or remove framebuffer-unifiedmem in Devices Properties section as it suites you. For example "000000a0" will give you 2560MB. If you remove it completely you will get default of 1536MB. I haven't properly tested headphone jack on macOS, since I am using BT headphones. If I remember correctly when you plug the cable in Windows, there is a popup to choose type of headphones and there you need to select headphones with microphone to make that work. Headphones without microphone is the default option.
  11. This is fixed version of DisableTurboBoostBattery.kext that should work with both SMCBatteryManager and ACPIBatteryManager. DisableTurboBoostBattery_2.3.zip I performed tests on battery and on charger with SMCBatterManager and looks like everything finally works as expected. Please test properly with ACPIBatteryManager since I only did brief test on battery to see if TurboBoost is disabled or not, but I didn't done any tests on charger. Please let me know if there is any problem so I could fix this.
  12. DisableTurboBoostBatery.kext doesn't work with VirtualSMC.kext and SMCBatteryManager.kext. Problem is here: void DisableTurboBoostBattery::actOnChangedPowerState() { if (pPowerSource && isOnAC != pPowerSource->externalChargeCapable() && pPowerSource->batteryInstalled()) { if ((isOnAC = pPowerSource->externalChargeCapable())) enable_tb(); else disable_tb(); } } Reason is simple - externalChargeCapable returns different values with VirtualSMC.kext and SMCBatteryManager.kext than with FakeSMC.kext and ACPIBatteryManager.kext. ExternalChargeCapable property has same value as ExternalConnected in case of FakeSMC.kext and ACPIBatteryManager.kext. On battery both values are false, on charger both values are true. With VirtualSMC.kext and SMCBatteryManager.kext only ExternalConnected property change value. It's true on charger and false on battery. ExternalChargeCapable is always true. This is the reason why disable_tb() is never called with VirtualSMC.kext and SMCBatteryManager.kext and Turbo Boost remains active. Fix should be simple as this: void DisableTurboBoostBattery::actOnChangedPowerState() { if (pPowerSource && isOnAC != pPowerSource->externalConnected() && pPowerSource->batteryInstalled()) { if ((isOnAC = pPowerSource->externalConnected())) enable_tb(); else disable_tb(); } } This should work in both usage cases - VirtualSMC.kext with SMCBatteryManager.kext and FakeSMC.kext with ACPIBatteryManager.kext. VirtualSMC implementation of ExternalChargeCapable looks proper based on documentation: ExternalConnected Type: bool IORegistry Key: kIOPMPSExternalConnectedKey True if computer is drawing external power ExternalChargeCapable Type: bool IORegistry Key: kIOPMPSExternalChargeCapableKey True if external power is capable of charging internal battery
  13. Turbo Boost Switcher use same approach (with almost identical code) to enable/disable Turbo Boost as DisableTurboBoostBattery.kext, but for some reason this one works and DisableTurboBoostBattery do not. Unfortunately, Turbo Boost Switcher can't detect power source change, so you need to manually enable/disable Turbo Boost if you want to disable it only when you are on battery power. You can also permanently disable Turbo Boost if you do not need it and do not want to play with enable/disable every time. Just extract DisableTurboBoost.64bits.kext from Turbo Boost Switcher.app. Since code that enables/disables Turbo Boost works in Turbo Boost Switcher and DisableTurboBoostBattery.kext is properly loaded I can only assume that there is a problem with detecting power source change for some reason. Looks like that there is also an issue if you boot your laptop on battery. It is possible that similar problem occurs if you use VirtualSMC. I will test this with FakeSMC.kext and ACPIBatteryManager.kext right away, while booting on charger. EDIT: As I suspected DisableTurboBoostBatery.kext works fine if you are using FakeSMC.kext and ACPIBatteryManager.kext, but it doesn't work if you are using VirtualSMC.kext and SMCBatteryManager.kext. I didn't notice mentioned issue. It works fine even if I boot on battery. I will try to figure out why it doesn't work with SMCBatteryManager.kext EDIT 2: I found the reason why it doesn't work.
  14. viking1304

    Where can i find the latest bootpacks (E7440)

    As far as I know VirtualSMC.efi if needed only if FileVault 2 is used.
  15. viking1304

    Does Facetime or iMessage Work?

    Few days ago i reinstalled everything from scratch and I decided to try to make new config with completely new set of serials. For almost a year I used cloned values from real unused Mac. Finally I am able to use iMessage with generated values. Everything works perfectly. Do not try to use your account with too many different serials in short period of time in desperate need to make iMessage work. This will probably just make things worse. It's better to change all your serials than just one or two values. This way it will look like a completely new machine. If it doesn't work, do not try again for at least 2-3 days. Then try with new serials. This is to avoid possible flagging of your account as "problematic" one. If you want serials that are close to real ones and that will probably work, you can take this approach. Select your model, and click on both Generate New buttons few times. Check Trust. Check you new serial with macserial app. dragon:Downloads viking$ ./macserial -i C02Q90RFH1DP Country: C02 - China (Quanta Computer) Year: Q - 2015 Week: 9 - 35 (27.08.2015-02.09.2015) Line: 0RF - 865 (copy 1) Model: H1DP - MacBookPro12,1 Valid: Possibly Lookup your model on EveryMac. Find into and disc dates (March 9, 2015 and June 5, 2017 in this case). Date decoded from your serial must be between those. Looks good. Check if your serial is used by real mac here. You need to get an error here! We’re sorry, but this serial number isn’t valid. Please check your information and try again. If you get anything else, do not use that serial. Generate new set of serials instead. Generate new ROM value, but do not use generate button from Clover. It might work, but it's totally wrong. On every real Mac that I checked ROM value is in MAC address format, that start with OUI (vendor) info that always belongs to Apple, but it doesn't match any real networking device. Also, it is not related to SmUUID. For some strange reason Clover takes last 6 numbers of SmUUID and add them to 6 randomly generated numbers. Proper way would be to use any Apple OUI and to add 6 random numbers at the end. Take any of those, for example 4098AD and add 6 random valid HEX numbers (0-9 and A-F). You might use first 6 that Clover generated, for example 8A9C14. In this case new ROM value would be 4098AD8A9C15. Do not generate Custom UUID, just select Inject System ID. For installation I used same config that I am using now (with same model and serials). People usually install OS with one set of serials and then use another later. Sometimes even with different model. I did this earlier. If you are doing this, do not log to iCloud nor try to use iMessage nor Facetime before changing serials to final ones.
×