Jump to content
KNNSpeed

Dell XPS 15 9560: 4K Touch, 1TB SSD, 32GB RAM, 100% AdobeRGB​

354 posts in this topic

Recommended Posts

If it just sits there and hangs (with no errors thrown, as it looks in your image), that's an IGPU problem. CoreDisplayFixup is supposed to fix that. It's possible ig-platform-id may need to be set to an invalid value on first boot in config.plist (try an invalid ig-platform-id as a last resort). Check that your BIOS "video memory" is in fact 64MB. Also, sometimes just trying again works. If this is just the IGPU hang and trying again works, you shouldn't run into this problem after that.

 

Other things to keep in mind:

Make sure /S/L/E is vanilla

/L/E is vaniila

You're on BIOS 1.3.3

The config.plist is the one I provided

You have no other patches or fixes besides the ones in the included zip

That you have valid serial numbers (I've never actually tried booting with just "AAAAAAAA").

 

Other things to try:

In config.plist, booterconfig set to 0x28 and csractiveconfig set to 0x67 (they only work together).

Not entirely sure what I did to manage to get it booting. But it's booting. I did fill in the serial numbers yesterday but today I just copied over my whole SMBIOS form my own clover config instead, maybe that was it?

It definitely boots quite a bit faster than my previous build.

 

Somehow though it's made my eGPU really flakey. It will only get recognised maybe <1 in 10 restarts now, and I'm not entirely sure why. I reverted back to my Clover folder and the same behaviour occurs now too, which is annoying.

Some notes on getting it to work (however flakey):

  • Enabling the two thunderbolt pre-boot options (I never had these enabled with my build) in the BIOS means that although the 1060 is recognised in macOS it does not get initialised and simply displays as a "NVIDIA Chip Model" in system report. (Still works fine in windows, so not sure what's up with that.)
  • GPUSensors.kext kernel panics with my eGPU plugged in. (So I deleted it.)

There has been another kernel panic on booting I haven't been able to capture as it restarts too quickly and proceeds to boot fine.

 

Edit: On boots where it doesn't get recognised (i.e appear in system report at all) putting the system to sleep makes it appear in system report as NVIDIA Chip Model again. hmm...

Share this post


Link to post
Share on other sites
Advertisement

I have re-entered my data again, and now I hang on somewhere else.

 

 

Gesendet von iPhone mit Tapatalk

 

Your data is still wrong.

 

In Clover ==> Config.plist:

 

SerialNumber

BoardSerialNumber

smUUID

 

Must all be valid for MacBookPro13,3.

 

Google "How To Get iMessage Working on Yosemite and El Capitan"

 

 

VT-d is just something a normal user never needs (neither on windows nor mac), but it's something that the kernel really dislikes to disable on the fly. sometimes this can result in a KP. I prefer the clean solution with one OS with higher stability and compatibility (easier) but harder for multi OS setup. Thats true. May be because i bought the Dell as a replacement for my MBP and never use windows in the first place ;-)

 

The problem with the serial numbers is, that everyone refers to clover configurator - and if you dont have a mac in hand it can be a lil bit tricky to get a running OSX to start the application. Thats why most people offer "semi-real" serials to boot the system and change them afterward. This is not something for your tutorial, but as you can see: most people dont read carefully and you'll get a lot of "this doesnt work" messages (both public and private ;-) )

 

The lowest should be 0,8Ghz. this is what my reference system is running at on lowest. May i ask why you need to manually enable HWP with the script? this worked for me without any modification.

 

I didnt upgrade the files to the latest EFI version, thats true. Simply because i had to decide to update either the 9550 or the 9560 tutorial. But backlight control, brightness saving and USB-C worked on my test system. Didnt even have one ticket on github regarding this issue. I'm a lil bit confused now. May i ask what you changed to make it work on your system? Is it possible there is a secondary 9560 revision?

 

May i ask you to test FileVault2? Would be a charm if it works with your files. :-)

 

If you don't have a Mac you shouldn't be building a hackintosh. That's piracy. At the very least, you can potentially get into much more trouble than if you had a real Mac (in the US). I have 3. That's also why I'm not including serial numbers.

 

HWP did work without enabling it in Clover with the BIOS setting, but I just wanted to make sure all flags were set so that Clover and the OS both were aware that HWP was enabled. If you don't tell the OS that HWP is enabled, how would it know? The whole point of HWP is that it is hardware-controlled. It will work even if the OS doesn't know about it (that's the beauty of hardware). If the OS knows about it, it can configure itself to work properly with it.

You can check for yourself: HWP is not properly enabled if you can boot without the 0xE2 MSR patch enabled.

 

EDIT: I think Kaby Lake i7-7700HQ idles at 1.3GHz. The cores are using like no power. That's incredible. (I see that Skylake i7-6700HQ idles at 800MHz.)

 

At some point between BIOS revisions, Dell added some code into the Type-C initialization function in the DSDT, which breaks USB-C with your patches (This is what SSDT-YTBT and a DSDT patch in config.plist fix. The RP15 _RMV patch works with SSDT-TYPC to enable USB-C hotplug). The backlight you never had working correctly. Just because you can change the backlight level does not mean you had proper brightness levels. If you use SSDT-PNLF correctly, you also need SSDT-BRT6 (for the XPS), AppleBacklightInjector from RehabMan's ProBook repo, and a kext patch. And that's just for  brightness control. To actually save brightness between reboots, you need SSDT-ALS0 (something me and RehabMan worked out at tonymacx86) to fake an ambient light sensor and "Automatically adjust brightness" enabled in SysPrefs --> Displays.

 

FileVault 2 won't work with PS/2 keyboards (like the XPS). I leave the files there because every time you update Clover they come back.

 

Thanks

 

But When i'm changing the mouse setting nothing is working lol 

for exemple for the movment of the mouse when i want to accelerate I have to change trackpade settings lol

 

Do you know why ? Should I disable something ?

 

Thanks for your time

It's a combination of both settings. I think it has to do with VoodooPS2Controller--I think it emulates a mouse for some things and a trackpad for others, but I'm not 100% sure. Once you set the various gestures as "keyboard shortcuts" in SysPrefs, it'll feel like a proper trackpad, though.

Eventually I'm just going to get an Apple Magic Trackpad, though, since  that's just a real trackpad. :)

Not entirely sure what I did to manage to get it booting. But it's booting. I did fill in the serial numbers yesterday but today I just copied over my whole SMBIOS form my own clover config instead, maybe that was it?

It definitely boots quite a bit faster than my previous build.

 

Somehow though it's made my eGPU really flakey. It will only get recognised maybe <1 in 10 restarts now, and I'm not entirely sure why. I reverted back to my Clover folder and the same behaviour occurs now too, which is annoying.

Some notes on getting it to work (however flakey):

  • Enabling the two thunderbolt pre-boot options (I never had these enabled with my build) in the BIOS means that although the 1060 is recognised in macOS it does not get initialised and simply displays as a "nVidia chip model" in system report. (Still works fine in windows, so not sure what's up with that.)
  • GPUSensors.kext kernel panics with my eGPU plugged in. (So I deleted it.)

There has been another kernel panic on booting I haven't been able to capture as it restarts too quickly and proceeds to boot fine.

 

Reset your BIOS to defaults and re-do the HWP patch. I needed to do that once. Maybe you don't need the Thunderbolt pre-boot options enabled? Try without.

Once you've successfully booted with your config.plist, can you try again with mine? As I briefly mentioned  before, sometimes a reboot/trying again makes everything work. Likely cache-related.

 

Let's see if we can spot the differences.

 

That "fast reboot KP" is FakeSMC-related. I can't read it either, but it only occurs once in a blue moon for me. Haven't seen it come back lately, and it tends to occur after SMBios options get changed (which makes sense, you hopped between MacBookPro13,3 and iMac17,1, and I have some MacBookPro13,3-specific edits in the FakeSMC).

 

Y'know, I wonder if those Thunderbolt pre-boot options have anything to do with post-boot hot plug...

Share this post


Link to post
Share on other sites

Reset your BIOS to defaults and re-do the HWP patch. I needed to do that once. Maybe you don't need the Thunderbolt pre-boot options enabled? Try without.

Once you've successfully booted with your config.plist, can you try again with mine? As I briefly mentioned  before, sometimes a reboot/trying again makes everything work. Likely cache-related.

 

Let's see if we can spot the differences.

 

That "fast reboot KP" is FakeSMC-related. I can't read it either, but it only occurs once in a blue moon for me. Haven't seen it come back lately, and it tends to occur after SMBios options get changed (which makes sense, you hopped between MacBookPro13,3 and iMac17,1, and I have some MacBookPro13,3-specific edits in the FakeSMC).

 

Y'know, I wonder if those Thunderbolt pre-boot options have anything to do with post-boot hot plug...

 

Right, I reset the BIOS and redid the HWP patch (left the two thunderbolt reboot options unticked, I'll try with them ticked in a second.) Didn't achieve much.

 

I'm well aware of the sometimes it just starts working if you restart magic, which is really annoying when I'm trying to debug and I have no idea what actually fixed something.  :rofl:

 

What fixed my flakey eGPU (I think, more restarts needed to test)Seems to have done it:

I increased the timeout in Clover from 5 to 8. (No idea how or why this makes a difference, especially considering I've had it on 5 until now since I started using macOS on my 9560.)

 

FYI, I never used the iMac17,1 SMBIOS in my own working build it's always been a MacBookPro13,3, that was put into the build in my guide because I didn't want to share my serial number  :hysterical:

 

I'll go through the differences in my config.plist and stuff in a second maybe try your SMBIOS again.

Share this post


Link to post
Share on other sites

The info in my SMBios (minus the serials/uuid) is tuned to exactly an MBP13,3--BIOS revision, board-id, and everything.

 

Do you have Fast Boot set to minimal in the BIOS, by any chance? If so, try putting it on "Thorough." That might give you the time it needs to initialize properly instead of having to make Clover do the waiting.

Share this post


Link to post
Share on other sites

Yep just slowly been reverting things back to as close to your build, here's the only differences now, most of them personal preference/WiFi setup stuff:

  • Config.plist
    Timeout 5 > 8 (will experiment with Fast Boot, it was set to Auto)  (Fast Boot on thorough doesn't fix anything)
    Theme
    Boot Volume
    Wifi Card patch
    SMBIOS (will try go back to using yours) (using yours now)
  • Kexts
    FakePCIID_Broadcom_WiFi.kext
    Removed GPUSensors.kext (KP with eGPU)
  • BIOS
    Two thunderbolt pre-boot options unchecked (Will try with them ticked) (Must both remain unchecked for my eGPU to initialise on Mac properly.)
    USB PowerShare off (Don't want/need it)
    SD Card Boot support off (Don't want/need it)

Something I noticed

I have my laptop set to stop charging at 95% in the BIOS, with my build (and I assume batterymanager kext) this would be reported as 95%, in yours it's reported as 100%.

Share this post


Link to post
Share on other sites

On real MacBook Pros 96% = 100% when unplugged. They do this on purpose (Lithium Ion tech can't sustain a full 100% without damage). I'm actually glad to hear that it's doing that on mine. I see that you have an "SSDT-BATC," considering that this laptop only has one battery I'm not sure what that SSDT is achieving here. :/

 

It might be that the BIOS reports 95% as 100% in order for the system to stop charging at 95%. That's how I would do it if I were making the BIOS. Perhaps something was bypassing the BIOS-reported info on yours? Let me investigate a little. Maybe naively that might seem like a good idea, but thinking about it some more maybe not--generally if one changes this setting they're expecting to see it reflected in the OS. Hmm....

 

EDIT: What does Windows say? 95% or 100%?

Share this post


Link to post
Share on other sites

On real MacBook Pros 96% = 100% when unplugged. They do this on purpose (Lithium Ion tech can't sustain a full 100% without damage). I'm actually glad to hear that it's doing that on mine. I see that you have an "SSDT-BATC," considering that this laptop only has one battery I'm not sure what that SSDT is achieving here. :/

 

Really? I never noticed that on my rMBP 2013. Although I know the battery level would slowly drop once it reached 100% as it stopped charging. I'm aware of the damage charging a battery to 100% constantly can do, which is why I've set it to only start charging when battery level drops under 75% and only charge to 95% in the BIOS, in the first place. (My laptops live the majority of their lives plugged in at my desk. My rMBP after over 3 years had only done 350~ battery cycles, battery health was well over 90% iirc)

 

Not using any files from my build anymore, purely your release (plus the changes listed above)

Share this post


Link to post
Share on other sites

Awesome! How's it running so far? How's brightness working? Also, what does the "card" icon in the menubar say (don't turn anything off from it)?

 

Also, what does Windows say the battery is: 95% or 100%?

Share this post


Link to post
Share on other sites

Running great! Been restarting so much to get this eGPU working I haven't had much time to test everything else but seems stable!

Full range of brightness!

 

Card icon crashes with my eGPU plugged in  :hysterical: (This happened on my build too.)

Clicking it removes all the macOS preference icons (Wifi, audio, clock, bluetooth etc.) until it resets itself.

IIRC when I booted without my eGPU I had an option to disable something, the SD Card reader I assume?

 

Windows/Linux/BIOS reports it as 95% (which is the correct behaviour, the laptop is stopping the charge on purpose at 95%, not because it thinks it is at 100%.)
If I set the battery charging settings to default in the BIOS (or via Dell Command Power Manager in Windows) then the laptop will actually charge to 100%.

 

(I've finished experimenting, final differences from your build are in the post above)

Share this post


Link to post
Share on other sites

Running great. Been restarting so much to get this eGPU working I haven't had much time to test everything else but seems stable!

 

Card icon crashes with my eGPU plugged in  :hysterical: (This happened on my build too.)

Clicking it removes all the macOS preference icons (Wifi, audio, clock, bluetooth etc.) until it resets itself.

IIRC when I booted without my eGPU I had an option to disable something, the SD Card reader I assume?

 

Windows/Linux/BIOS reports it as 95% (which is the correct behaviour, the laptop is stopping the charge on purpose at 95%, not because it thinks it is at 100%.)

If I set the battery charging settings to default in the BIOS (or via Dell Command Power Manager in Windows) then the laptop will actually charge to 100%.

 

(I've finished experimenting, final differences from your build are in the post above)

 

Well, about that card icon:

 

With no eGPU plugged in, yes it'll allow you to disable the SD card reader

With a thunderbolt device plugged in, you'd get an option to power off the thunderbolt controller or power off the device connected to the thunderbolt controller (which causes a hard-lock because OS X can't handle either)

With a USB-C device plugged in, you can turn off the USB part of the thunderbolt controller (which works fine, it just shows up as "USB controller")

 

However, with my "Only RP15 _RMV" patch, which enables the SD card reader, you'd think it would simply allow you to see both the SD card reader and whatever else would normally trigger that menu. Well, not so, because that card icon is meant for ExpressCards. For the SD Card reader, that's fine--that's what older MacBook Pros used for their card readers. But, for Type-C hotplug to work, we're basically tricking OS X into treating the Type-C port as an ExpressCard device. This is fine for USB, too, as ExpressCard USB devices exist. It's when you have a Thunderbolt device that things get weird: The OS doesn't know what an ExpressCard Thunderbolt device is, so it freaks out when it tries to query the "strange device." There's possibly a driver conflict between the Thunderbolt driver and the non-Thunderbolt "removable PCI-e" subsystem, whatever that may consist of. So it only breaks when a Thunderbolt device is plugged in.

 

Re: battery--try adding this SSDT-BATC to ACPI/patched & Clover/config.plist. Let me know if that solves the 95% thing.

 

EDIT: What I said about 96% = 100% was outdated; manufacturers now generally state "9x%, Not Charging" instead of the  96% = 100% thing they used to do (circa 2010-2012). I definitely noticed it on my iPhone 4S (2011) and MacBook Pro Mid-2010. D'oh!

SSDT-BATC.aml.zip

Share this post


Link to post
Share on other sites

Re: battery--try adding this SSDT-BATC to ACPI/patched & Clover/config.plist. Let me know if that solves the 95% thing.

 

EDIT: What I said about 96% = 100% was outdated; manufacturers now generally state "9x%, Not Charging" instead of the  96% = 100% thing they used to do (circa 2010-2012). I definitely noticed it on my iPhone 4S (2011) and MacBook Pro Mid-2010. D'oh!

Nope, still reported as 100% with the SSDT.

(I double checked in the BIOS it's definitely at 95% right now.)

 

Ah yes, that's what my MacBook did!

Share this post


Link to post
Share on other sites

Hmm.. try this:

"sudo gem install istats"

"istats scan"

"istats enable all"

"istats"

 

and post the output (should fit in a CMD-Shift-4 screenshot)

 

There are very few differences between your battery-related stuff and mine. Your ACPIBAtterManager is 1.70.2, mine is 1.70.3. There is a difference in poling speed on boot, but that's it. Your build's also got SSDT-BATC. That's all I can find....

Perhaps it's related to ADP1. Do you have an ioreg of your build? I wonder if on Device ADP1 in ioreg it shows rehab_ACPIACAdapter or not...

 

EDIT: Oh, if you never plan on using USB-C or anything that wouldn't be plugged in pre-boot, you can open SSDT-TYPC.aml and under the first _RMV way at the top, make it return 0 instead of 1. It may help with the flakiness.

Share this post


Link to post
Share on other sites

At some point between BIOS revisions, Dell added some code into the Type-C initialization function in the DSDT, which breaks USB-C with your patches (This is what SSDT-YTBT and a DSDT patch in config.plist fix. The RP15 _RMV patch works with SSDT-TYPC to enable USB-C hotplug). The backlight you never had working correctly. Just because you can change the backlight level does not mean you had proper brightness levels. If you use SSDT-PNLF correctly, you also need SSDT-BRT6 (for the XPS), AppleBacklightInjector from RehabMan's ProBook repo, and a kext patch. And that's just for  brightness control. To actually save brightness between reboots, you need SSDT-ALS0 (something me and RehabMan worked out at tonymacx86) to fake an ambient light sensor and "Automatically adjust brightness" enabled in SysPrefs --> Displays.

 

FileVault 2 won't work with PS/2 keyboards (like the XPS). I leave the files there because every time you update Clover they come back.

You dont need to save the information about backlight with a workaround over a faked ambient sensor, you can simply re-set it with saving the value in the pram like on a real mac. of course you need a working pram first.

 

FileVaul2 can be used with the keyboard. You just need the correct extensions. I added them in my testing repository for the 9550 (see https://github.com/wmchris/DellXPS15-9550-OSX/tree/10.12-BIOS1.2.21/10.12/Advanced/FileVault2/Clover-drivers64UEFI ). On my tests it just wouldnt decrypt the filesystem or boot the os while osxaptio was in place.

 

Brightness levels were adapted. See https://github.com/wmchris/DellXPS15-9550-OSX/commit/970e3c6aab0365e3aecf0fadb9a214f7d07c7a00. Seems like i have to update my repository structure. Because i do the primary function updates in the 9550 repository, which have to be pushed in the 9560 manually, some changes are simply not observed or not migrated correctly. May i ask if i would be allowed to use your patches for usb-c in my repo on github? i honestly never upgraded the bios on the 9560 testing machine, so i never realized they've changed something (and i didnt get a bug report either).

 

BTW: not having a Mac in hand doesnt automatically mean you're a pirate. Most people i know only buy a new device if the old one is defective.

Share this post


Link to post
Share on other sites

The problem is we don't have real NVRAM on these laptops. So you have to use the ALS.

 

Can't really risk not being able to recover my data at this point, so I can't safely test FileVault 2.

 

I don't really know what else to tell you about brightness: it works now, properly, and it didn't when I used yours.

 

Yes, but I can count at least 12 SSDTs in your repo that are irrelevant as of May 2017:

SSDT-BATC
SSDT-Debug
SSDT-Fan (The RPM is straight up wrong; you can't get the fan RPM directly from ACPI, only the temperature it's reading)
SSDT-HPET
SSDT-LANC_PRW (this laptop doesn't even have a device called LANC)
SSDT-PS2K
SSDT-RMNE (you don't even have null ethernet)
SSDT-SLPB (the laptop actually has a sleep button connected on FN + Insert, _STA 0xB is a bitmask that tells the system there is no sleep button, which is wrong and doesn't do anything anyways)
SSDT-XE42 (replaced by my YTBT)
SSDT-XHC (USBX gives you power data)
SSDT-XWAK (this laptop doesn't even have an XWAK)
Your GPRW fix doesn't work Scratch that, NONE of the PRW fixes you have work

SSDT-UIAC-9xx0 is used incorrectly; use UIAC properly with USBInjectAll (then you don't need to rename HS12 to HS92)

 

SSDT-TB is replaced by SSDT-TYPC

 

from your clover, you don't need:

Any of the Mutex fixes
Any of the DSDT "fixes" at the top
The HPET fix
The SDSM fix
The ADBG fix
the PNP0c04 fix (the MATH device already loads properly)
SBTN fix
ALSD rename to ALS0 fix (This ALS gets disabled anyways and the OS doesn't even see it)

The _RMV to XRMV patch breaks the card reader

 

You don't need anything that states "EHCI" or "EHC"

 

I don't know why you have 2 different PTS patches, or 4 different WAK patches.

 

On the 9560 you need to drop xh_rvp11, not xh_rvp10

 

If you used SSDT-IGPU/SSDT-HDEF correctly, you wouldn't need any of the "AddProperties" fixes. You would also not need to inject Intel in "Graphics."

 
9560 4K does not need "minstolensize"
 
Don't need to enable TRIM for SSD
 
eDP port patch is insufficient to get HDMI audio working
 
Don't need  to fudge any USB device id.
 
....And then with a few more edits, and using certain kexts instead of SSDTs, you basically have my build. Mostly. Not totally.
..Err.... I think there are some more things that I missed. But I think this all also applies to the 9550.
 
EDIT: Re: Piracy: What I'm saying is if you don't have a Mac, you don't have a legitimate way or license to acquire OS X to begin with. That is piracy, and that is exactly the very reason DSMOS.kext exists. Not whatever you thought I said.
Edited by KNNSpeed

Share this post


Link to post
Share on other sites

Hmm.. try this:

"sudo gem install istats"

"istats scan"

"istats enable all"

"istats"

 

and post the output (should fit in a CMD-Shift-4 screenshot)

 

There are very few differences between your battery-related stuff and mine. Your ACPIBAtterManager is 1.70.2, mine is 1.70.3. There is a difference in poling speed on boot, but that's it. Your build's also got SSDT-BATC. That's all I can find....

Perhaps it's related to ADP1. Do you have an ioreg of your build? I wonder if on Device ADP1 in ioreg it shows rehab_ACPIACAdapter or not...

 

EDIT: Oh, if you never plan on using USB-C or anything that wouldn't be plugged in pre-boot, you can open SSDT-TYPC.aml and under the first _RMV way at the top, make it return 0 instead of 1. It may help with the flakiness.

Here this should cover it. 

I can switch between builds in less than a minute, it's a straight clover folder swap.

 

If you look on mine it's 95%, on yours it's 100% everything related to the values from the battery itself look to remain constant.

KNN is your build, J is mine.

 

EDIT: You can probably test this yourself if you set the BIOS to the settings attached and run down the battery a bit. (the lower threshold probably doesn't matter)

 

Battery.zip

post-452355-0-48579000-1497310552_thumb.jpg

Share this post


Link to post
Share on other sites

Huh. That is really weird. Literally everything else (power-related) is the same (to be specific: the part that I'm looking at). What if you used your version of ACPIBatterymanager in my build?

Share this post


Link to post
Share on other sites

:wallbash:

 

I will try setting it on mine.

Time for the Sherlock Holmes hat and a magnifying glass.

 

EDIT: Found a typo in SSDT-BATC. Whoa this is really weird. (Lol)

 

EDIT2: Right now my battery is off by 5%. 92% in raw numbers (7399/8058) is 97% according to the menubar icon.

post-1024628-0-77184700-1497312079_thumb.png

Share this post


Link to post
Share on other sites

So, I've pretty much combed through everything I can think of, and I'm not getting it to show me an accurate 95%. I've tried putting SSDT-BATC, renaming AC to ADP1 and using SSDT-ADP1 from Jonny's folder (though that's just a _PRW add-on that doesn't make any sense), and otherwise made my system have exactly the same configuration as Jonny4911's and it never gave me an accurate 95%. Even if I take off the 95% power limits, it tells me 95% = 100%. It really looks a lot like this is happening, which is something I know iPhones do (my 6 Plus actually tells me it's at 1% when it's at 20% because machine learning algorithms learned how hard I run my devices).

 

I did notice that there were some keys that differed in FakeSMC between our systems, but adding those in also did nothing (well, they did stuff, but nothing related to this discrepancy).

 

 

I also can't help but notice in the istats image from Jonny's post his battery health is at 90%, while I can see mine is at 95%. However, that does not seem to matter.

 

So, at this point, I can pretty much only state the same thing all these guys are stating:

https://forums.macrumors.com/threads/mavericks-fails-to-calculate-remaining-battery.1666192/

 

Various programs tell me different things as well: Right now, Mac OS is telling me 100%. The old widget iStat Pro gives me 97%. The command

ioreg -n AppleSmartBattery -r | awk '$1~/Capacity/{c[$1]=$3} END{OFMT="%.2f%%"; max=c["\"MaxCapacity\""]; print (max>0? 100*c["\"CurrentCapacity\""]/max: "?")}'

gives me 98.3%. So... Yeah. It's working right. I don't know why it jumps 5%, but 5% looks like the margin of error for the battery indicator.

 

If it really proves irksome, we might be able to use this to "align" the battery indicator with your expectation: https://github.com/RehabMan/OS-X-ACPI-Battery-Driver/blob/master/SSDT-ACPIBATT.dsl

 

EDIT: I just checked my MacBook Pro Late 2013: Guess what? Battery status is also wrong. Same margins as we're seeing here.

Share this post


Link to post
Share on other sites

Hi,

sorry to bother with a silly question, but I was using the 9,1 smbios setup and updating the smbios section for the 13,3 version I find that the model identifier section in system information reports MacBookPro1.

I double checked by entering the serial on everymac that the serial I am using refers to a late 2016 15'' notebook. Any clue of what could be wrong?

Many thanks

Share this post


Link to post
Share on other sites

Not a silly question. the clover smbios truncation workaround seems to be disabled. enable it :-)

 

Hi,

sorry to bother with a silly question, but I was using the 9,1 smbios setup and updating the smbios section for the 13,3 version I find that the model identifier section in system information reports MacBookPro1.

I double checked by entering the serial on everymac that the serial I am using refers to a late 2016 15'' notebook. Any clue of what could be wrong?

Many thanks

Share this post


Link to post
Share on other sites

For the 9560 my build won't work unless you're on the latest BIOS.


Hi,

sorry to bother with a silly question, but I was using the 9,1 smbios setup and updating the smbios section for the 13,3 version I find that the model identifier section in system information reports MacBookPro1.

I double checked by entering the serial on everymac that the serial I am using refers to a late 2016 15'' notebook. Any clue of what could be wrong?

Many thanks

You can't use the same config.plist from the 9,1 setup. The patches (in pretty much every section) are different.

Share this post


Link to post
Share on other sites

Not if you installed Windows correctly. If you mean the Mac installation, it will work much better on the latest BIOS (1.3.3) if you are using my build (for example, USB-C will actually work correctly). You may need to redo setup_var 0x4BC after the update.

 

There is always a risk with upgrading the BIOS, but in general just make sure that you have the AC adapter plugged in, and in msinfo32 the "BIOS Type" is "UEFI." That greatly minimizes chances for error.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×