[Guide] Dell XPS 13 9360 on MacOS Sierra 10.12.x - LTS (Long-Term Support) Guide

[bozma88]

The problem is if PWMMax is not set correctly, the brightness levels may be off.
If it is larger than expected, you will not reach 100% brightness. The degree to which you can detect the problem, is dependent on the degree to which PWMMax is larger than the expected value.
If it is smaller than expected, the display will go dark above a certain brightness level (quite easy to detect).



As noted above, PWMMax setting has nothing to do with the data in AppleBacklight[Injector].kext.



It is possible to set PWMMax to anything. Then the current backlight level (LSW of LEVX) is set as a percentage of that max...
I have no idea on why certain values for PWMMax are used.
We already know that various BIOS will use different values on similar hardware.
And we already know that OS X/macOS uses different values depending on ig-platform-id and graphics platform.



Sounds like you're using subjective observations.
It would be great to confirm that the SKL graphics drivers set PWMMax at boot instead of relying on the firmware to do it.



I have never used DirectHW.kext, but it isn't much of a "backdoor". All hardware registers are available at the kernel level... there is no protection there.

I did read Intel documentation.
If I understood correctly, PWMMax is the frequency divider.
It may be initialised by BIOS at boot, but then at wake it is OS responsibility to re-initialise it.
So the two must match, otherwise we get different scaling pre-post wake.
The frequency divider is responsible for allocating time slots for the various duty cycles interpolated by the array of values you set into the injector plist.
This is why, independently from what you set into that injector, if the frequency divider is less than maximum, you are not able to reach full brightness.
So the simplest way to achieve full brightness is to set frequency divider at the same value as the highest brightness value you find on a properly working system (aka Windows with panel drivers installed).

Am I right, @RehabMan?

As side notes:
- Our panel has a shockingly high PWM frequency: 44000 Hz. Hight PWM usually means high minimum brightness. Our panel goes as low as <1%. Very well engineered.
- Our panel, at 100% brightness, still has a duty cycle of ~50%. This means it could be twice as bright, but I think it's locked in display firmare (just as CABC).
- I think that smooth steps are caused by hardware. It's the PWM controller that gradually changes duty cycle. This can be seen also when system hangs and you issue a hard-reboot, display dims and powers up gradually. So, this may be the same on real Macbooks: hardware-generated smoothing. Hackintoshes with no hardware smoothing will have discrete steps, unless smoothing is SW-emulated, like in IntelBacklight (Am I right, @RehabMan?).

 

[RehabMan]

I did read Intel documentation.
If I understood correctly, PWMMax is the frequency divider.
It may be initialised by BIOS at boot, but then at wake it is OS responsibility to re-initialise it.
So the two must match, otherwise we get different scaling pre-post wake.

Yes. And the problem is macOS/OS X makes an assumption about what it is initialized to...
That assumption may not be the same as what your BIOS actually uses.
Hence the need to initialize it to what macOS/OS X expects via ACPI...

The frequency divider is responsible for allocating time slots for the various duty cycles interpolated by the array of values you set into the injector plist.

macOS does not initialize PWMMax based on any data in AppleBacklight.kext.
It is initialized by the Mac firmware at startup and initialized after wake by the graphics drivers.
The value is in in the ig-platform-id data part of the framebuffer kext.

So the simplest way to achieve full brightness is to set frequency divider at the same value as the highest brightness value you find on a properly working system (aka Windows with panel drivers installed).

The value for PWMMax used by Windows/BIOS is not relevant if you're planning to use AppleBacklight.kext...
Read carefully above...

Did you find out what your native PWMMax as set by BIOS is yet?

- I think that smooth steps are caused by hardware. It's the PWM controller that gradually changes duty cycle. This can be seen also when system hangs and you issue a hard-reboot, display dims and powers up gradually. So, this may be the same on real Macbooks: hardware-generated smoothing. Hackintoshes with no hardware smoothing will have discrete steps, unless smoothing is SW-emulated, like in IntelBacklight (Am I right, @RehabMan?).

There is some support at HW smooth transitions in the Intel docs... but the same docs also imply the feature was removed in later graphics chipsets (may be not accurate). It has now been a while since I read it, but from what I remember, implementing a (approx.) linear transition would require using an interrupt generated by the IGPU...

Most laptops will not have smooth transitions with AppleBacklight.kext. Never was able to determine why, so I wrote it into IntelBacklight.kext with software. Maybe something is enabled (BIOS init) on yours that enables it...

 

[bozma88]

Yes. And the problem is macOS/OS X makes an assumption about what it is initialized to...
That assumption may not be the same as what your BIOS actually uses.
Hence the need to initialize it to what macOS/OS X expects via ACPI...



macOS does not initialize PWMMax based on any data in AppleBacklight.kext.
It is initialized by the Mac firmware at startup and initialized after wake by the graphics drivers.
The value is in in the ig-platform-id data part of the framebuffer kext.



The value for PWMMax used by Windows/BIOS is not relevant if you're planning to use AppleBacklight.kext...
Read carefully above...



There is some support at HW smooth transitions in the Intel docs... but the same docs also imply the feature was removed in later graphics chipsets (may be not accurate). It has now been a while since I read it, but from what I remember, implementing a (approx.) linear transition would require using an interrupt generated by the IGPU...

Most laptops will not have smooth transitions with AppleBacklight.kext. Never was able to determine why, so I wrote it into IntelBacklight.kext with software. Maybe something is enabled (BIOS init) on yours that enables it...

Thank you for the explanation!
So we are pretty lucky, I just tested with a lux-meter and we get exactly the same steps before and after wake, and identical brightness on Mac and Windows. PWMMax is correctly initialised and the value is a close or perfect match with 0x56c.

 

[RehabMan]

Thank you for the explanation!
So we are pretty lucky, I just tested with a lux-meter and we get exactly the same steps before and after wake, and identical brightness on Mac and Windows. PWMMax is correctly initialised and the value is a close or perfect match with 0x56c.

It would be great if you could confirm actual PWMMax as initialized by BIOS...
It is still possible that the SKL graphics drivers are initializing it... We won't know for sure until you capture the value in ACPI _INI.

 

[seijinshu]

What is a good 1TB SSD that has proper 4K support for native NVME drivers?

 

[bozma88]

It would be great if you could confirm actual PWMMax as initialized by BIOS...
It is still possible that the SKL graphics drivers are initializing it... We won't know for sure until you capture the value in ACPI _INI.

will do asap

What is a good 1TB SSD that has proper 4K support for native NVME drivers?

Toshiba (and so OCZ) should all be compatible, but I cannot guarantee. Ask the manufacturer.

 

[kiraraso]

So I just found a quick fix for the power plug/unplug freezing issue:
Just hide the battery status from the menubar (from System Preferences -> Energy Saver), and that's it! You can plug and unplug as much as you like to your heart's content
I guess that means the problem could be caused by some graphical glitch when switching the icons between the charging/discharging states, but even if it's not, we've narrowed it down a lot for sure!
In the meanwhile (until we find a full solution), I suppose we can use something like iStatMenus if you need battery status on the menubar (or just check/uncheck the preference every time you plug/unplug).

Edit: Ok I got a bit too over-excited here... The problem seems to come back after rebooting unfortunately... Will need further investigation to make the fix work again

 

[bozma88]

This is very interesting, but now we have to understand if it's an incompletely patched DSDT and why only on a few computers. Mine, for example, never did it.

 

[kiraraso]

Ok, further testing showed that it had nothing to do with the menubar icon after all.
The fix should be repeatable this way now:
1. Boot into OSX (doesn't matter if plugged or unplugged)
2. Apple -> Sleep, and wait until the power LED goes off
3. Invert the power state (Plug in the AC if you hadn't, and vice versa)
4. Turn machine back on
And now you should be able to hotplug the power on-the-go!

 

[kiraraso]

This is very interesting, but now we have to understand if it's an incompletely patched DSDT and why only on a few computers. Mine, for example, never did it.

Yeah it's very odd how it only happens to some of us... And it seems to be quite a rare issue as I could only find one other laptop with the exact same problem from a few years ago: http://www.insanelymac.com/forum/topic/290010-freeze-when-pluggingunplugging-charger/