Is “jailbreaking” our way to higher SDR brightness on the new miniLED Macs possible?

[mr_roboto]

These days, most of the configuration settings are stored in the read-only volume and as a normal user, you can't really edit those files...

Apple has really locked down macOS in recent versions and made it more and more difficult, if not impossible, for enthusiasts such as ourselves to dig through the OS and make unauthorized changes....

You seem confused about what the read-only volume is for. No configuration settings are stored there. This link provides a description:

Signed system volume security

SSV not only helps prevent tampering with any Apple software that’s part of the operating system, it also makes macOS software update more reliable and much safer.

support.apple.com

The basic idea is that files which make up macOS (the stuff distributed to you when you download a macOS installer or macOS updater from Apple) should not be allowed to be altered by attackers trying to hack your computer. By separating just those system files out into a read-only volume, Apple made that kind of tampering harder. In macOS 11, they extended the concept further by using cryptographic signature checking to "seal" the read-only volume. This lets them detect any tampering done to the system volume while the computer was booted into an alternate OS which doesn't respect the read-only setting on the system volume.

Configuration is not stored on the system volume. If it was, it could not be altered except during a macOS install or update, and therefore it wouldn't be configuration.

Like @leman says, you can still mess with anything you like. Apple's design puts you, the user, in charge of whether you want your system files to be tamperable or not. If you want less protection, you merely reboot into RecoveryOS and change the system security settings there. (They designed this to require the reboot into Recovery so there's no way to script it, which would be handy for an attacker. It also reduces the chances that an attacker can "social engineer" a naive user into downgrading security.)

 

[leman]

The basic idea is that files which make up macOS (the stuff distributed to you when you download a macOS installer or macOS updater from Apple) should not be allowed to be altered by attackers trying to hack your computer. By separating just those system files out into a read-only volume, Apple made that kind of tampering harder. In macOS 11, they extended the concept further by using cryptographic signature checking to "seal" the read-only volume. This lets them detect any tampering done to the system volume while the computer was booted into an alternate OS which doesn't respect the read-only setting on the system volume.

And there is another, very real benefit — much faster updates. If you know that the base volume is a sealed, monolithic thing, you can just apply a diff when updating and be done with it. Same with backups — no need to back it up at all. Once you allow the user to change things, these benefits disappear.

 

[fs454]

Okay, so as most of you are probably already aware, the new miniLED 14 and 16-inch MacBook pros can achieve an incredible 1,000 nits of fullscreen sustained brightness. The catch is that that‘s only available while HDR content is onscreen, which for most people is like 0.1% of the time.

When HDR content is not onscreen, you’re still limited to the same 500 nits, which goes all the way back to the 2016 models. As someone who always has my brightness maxed out and often finds it to still be insufficient, this is super disappointing to me. I thought we would at least get 600 like the miniLED iPad Pro has, which uses the same display technology from the same manufacturer. ._. I have both a 500 nit Mac and a 600 nit iPad Pro and believe me the difference is way more noticeable than you would expect.

Given that these are Macs and we have a much higher level of control over the system compared to something like an iPad, would it be theoretically possible to “hack” our way to higher fullscreen SDR brightness? If so I would love to just raise it to 600, and I’d happily take the battery hit. It seems like something that may be possible given that this is a simple artificial limitation, but I need someone with a deeper understanding of macOS to weigh in.

Who has a solution?

Alright everyone, great news. This is now possible, and it works great. The developer of Lunar got it working and has offered it up in this beta build: https://github.com/alin23/Lunar/issues/417#issuecomment-1067319528

I'm running it now and it's amazing. I don't intend on running the display full tilt at 1600 all the time, but having it (and all levels between 500 and 1600) as an option for when you need better daylight visibility or just more brightness is awesome.

The caveats are that there may be some small bugs and hitches here and there in the OS, which I have not experienced using it so far, and that the display can get hot when running full brightness for extended periods. Apple has built in a thermal throttle for the brightness level similar to how the iPhone does it when it gets above a certain temperature, so I suspect this protection keeps the display within a safe operating temperature at all times. I've not noticed undue additional warmth when running it at what I suspect to be 800-1000 nits.

 

[alinpanaitiu]

Hi everyone!

Lunar developer here. Thanks @fs454 for spreading the word about Lunar!

XDR Brightness is now oficially released since v5.5.1

It is a Lunar Pro feature, but Lunar offers a 14-day free trial, no questions asked.

I wanted it to be free but it required almost 2 months of non stop reverse engineering and I probably lost part of my vision staring into the blinding LEDs of the MacBook Pro.

If anyone's interested in how it was made, you can read about my previous failed attempt here:

Trying to get past the 500 nits limit of the MacBook Pro (and failing)​

The working version is not far from that. I finally found the right APIs in SkyLight and CoreBrightness. I will do a writeup on that and open-source the solution soon.

 

[iemcj]

To the people saying "but but but it'll be too bright! There's no way the screen can handle colors!"

BS. Complete BS.

My 2 year old samsung tv according to Rtings has a Sustained 100% Window 1,665 cd/m² . Which is a 1:1 conversion to nits. Basically my tv is capable of holding a brightness more than 3x and is incredibly color accurate. Some of us live in warm climates with lots of window light where we work and live so these dim little screens get washed out and look terrible unless it's evening time... when all the work is already done.

 

[tmoerel]

To the people saying "but but but it'll be too bright! There's no way the screen can handle colors!"

BS. Complete BS.

My 2 year old samsung tv according to Rtings has a Sustained 100% Window 1,665 cd/m² . Which is a 1:1 conversion to nits. Basically my tv is capable of holding a brightness more than 3x and is incredibly color accurate. Some of us live in warm climates with lots of window light where we work and live so these dim little screens get washed out and look terrible unless it's evening time... when all the work is already done.

You call BS. So I take it you are an Apple engineer who knows all about the XDR screen and the thermals in the MBP.

 

[alinpanaitiu]

To make XDR possible, I had to disassemble macOS internal frameworks and kernel extensions, so I have a little more knowledge about how macOS treats this nits limit.

Maybe I can help clear out some confusion about the subject:

1. macOS has a hard limit on the LED temperature and it will start lowering brightness forcefully way before it can do any damage
2. Yes, the lifespan of the LEDs will be lowered if this is used daily, but no one can say by how much. That's just how LEDs work, heat decreases lifespan because it degrades the junction between the semiconductors.
3. If used with mostly non-white backgrounds/apps, only the really close-to-white pixels will actually reach 1600 nits, while the rest will hover below 1000 nits, so they'll have plenty of time to cool down

I've been using this while working in trains with the sunrise coming from the big train window, and while working in a botanic garden under less than ideal shade. All I can say is that it's a blessing to have this option when you need it.

While sifting through macOS internals, I've discovered a lot of logic for temperature thresholds, local dimming zones to keep pixels at their most efficient brightness, and safe measures for high power usage.

From what I know now, I'd say this is pretty safe to use, given that the system will not allow you to go past unsafe limits.

 

[fs454]

To make XDR possible, I had to disassemble macOS internal frameworks and kernel extensions, so I have a little more knowledge about how macOS treats this nits limit.

Maybe I can help clear out some confusion about the subject:

1. macOS has a hard limit on the LED temperature and it will start lowering brightness forcefully way before it can do any damage
2. Yes, the lifespan of the LEDs will be lowered if this is used daily, but no one can say by how much. That's just how LEDs work, heat decreases lifespan because it degrades the junction between the semiconductors.
3. If used with mostly non-white backgrounds/apps, only the really close-to-white pixels will actually reach 1600 nits, while the rest will hover below 1000 nits, so they'll have plenty of time to cool down

I've been using this while working in trains with the sunrise coming from the big train window, and while working in a botanic garden under less than ideal shade. All I can say is that it's a blessing to have this option when you need it.

While sifting through macOS internals, I've discovered a lot of logic for temperature thresholds, local dimming zones to keep pixels at their most efficient brightness, and safe measures for high power usage.

From what I know now, I'd say this is pretty safe to use, given that the system will not allow you to go past unsafe limits.

Just bought Lunar Pro - thanks again for the work on this! I noticed it seems to help me squeeze a bit more brightness out of my Dell 2721DGF as well (an HDR400 165hz gaming monitor I use sometimes for work as well, 400 nits in SDR mode but can go a little higher in HDR mode when commanded by the content). macOS in general doesn't seem to let me ever have direct hardware brightness control of non-USB-C driven external monitors but it seems like that's what I'm getting with Lunar Pro as well as the great XDR stuff for the builtin display.

Does this also let Pro Display XDR owners drive that display brighter as well?

 

[alinpanaitiu]

macOS in general doesn't seem to let me ever have direct hardware brightness control of non-USB-C driven external monitors but it seems like that's what I'm getting with Lunar Pro

Yes, Lunar's most important function is that it can control the real brightness of the monitors where the system can't do that. Glad it works nicely for you, I didn't expect XDR to have any effect on non-XDR displays.

Does this also let Pro Display XDR owners drive that display brighter as well?

Yes, it has the same effect as for the MacBook display. Both the Pro Display XDR and the MacBook Pro display have the same 1600nits peak and 500nits cap, and Lunar's XDR Brightness will allow the max brightness on both.

The Pro Display XDR has active cooling and huge heatsinks so it should be even safer than the MacBook.

 

[Jazmodo]

For anyone still looking at this, there are a couple of solutions now:

https://forums.macrumors.com/threads/unlocking-1000-nits-on-14-16-macbook-pros-xdr-displays.2341207/

Vivid - https://www.getvivid.app/

BetterDummy - https://github.com/waydabber/BetterDummy/releases/tag/v1.2.0-beta

 

[darngooddesign]

For anyone still looking at this, there are a couple of solutions now:

https://forums.macrumors.com/threads/unlocking-1000-nits-on-14-16-macbook-pros-xdr-displays.2341207/

Vivid - https://www.getvivid.app/

BetterDummy - https://github.com/waydabber/BetterDummy/releases/tag/v1.2.0-beta

And Lunar

Lunar - The defacto app for controlling monitor brightness

Control monitor brightness, adapt using the ambient light sensor, adjust volume, switch inputs and turn off displays without fiddling with clunky buttons.

lunar.fyi

 

[heinzdembowski]

@alinpanaitiu
I bought Lunar for XDR brightness. Thanks so much for that, great work.
Is there a setting so Lunar doesn't do anything but take over brightness control when I increase past 100%? It has so many modes and it seems to always do stuff that I personally am not interested in. So it will turn off my laptop screen or it will change the curve of how regular brightness behaves so it's really choppy. I find myself turning off lunar altogether when not in sunlight but that can't be the solution, right?

 

[StudioMacs]

Wanna see a whiter white?

Wanna see a whiter white? CSS trick/bug to display a brighter white by exploiting browsers' HDR capability and Apple's EDR system

kidi.ng

Does that page work in Safari on the M1 Pro/Max models with XDR displays?

That page works in Safari on any current Apple display (e.g. Studio Display) due to EDR supporting values of white above 1.

Apple’s “EDR” Brings High Dynamic Range to Non-HDR Displays

 

[alinpanaitiu]

@alinpanaitiu
I bought Lunar for XDR brightness. Thanks so much for that, great work.
Is there a setting so Lunar doesn't do anything but take over brightness control when I increase past 100%? It has so many modes and it seems to always do stuff that I personally am not interested in. So it will turn off my laptop screen or it will change the curve of how regular brightness behaves so it's really choppy. I find myself turning off lunar altogether when not in sunlight but that can't be the solution, right?

Lunar is mostly made for adding adaptive brightness to external monitors, and controlling every aspect of them.

XDR brightness is mostly a second thought, albeit with a good implementation as it can use Lunar's screen APIs that were built and improved constantly over the last 5 years.

To minimize what Lunar does in the background:

• Use Manual Mode
• Disable Software Dimming in the Controls menu
• Click on Disable all on the Hotkeys page
• Make sure Auto BlackOut is disabled on the builtin display page
• Disable HDR compatibility and a few other things
  

After all that, Lunar should sit idle in the background and just react when you press brightness keys, or when the screen configuration changes (wake/standby/monitor connection events)

Note that without the HDR compatibility workaround, a macOS Gamma bug will make HDR content look overblown when XDR is toggled. I’m still waiting for a response from Apple on this bug.

it will turn off my laptop screen or it will change the curve of how regular brightness behaves so it's really choppy

This should not happen. Lunar keeps the system adaptive brightness running and doesn’t automatically change the brightness of the MacBook screen.

It has to take over the brightness keys so that it can detect when you increase brightness over 100% to activate XDR, or lower below 0% to activate Sub-zero Dimming. But it uses the same brightness APIs that the system uses, so the curve is the same. If it seems choppy, make sure Brightness Transition is set to Smooth on the Configuration page (that should be the default)

Can you share some more details about the turn off problem? I’m not sure what that means.

 

[heinzdembowski]

@alinpanaitiu
Thanks for this answer. I'm very impressed especially about the links that lead to parts of the App!!
I'll try with your settings. For now. The turning off was the same as clicking the red ON/OFF button in the top right of the picture of the screen. But I think manual mode should take care of this not happening now.

One final difference now is that my brightness keys control both displays at once. Before, they would control the main display and pressing ctrl-brightness up/down would control the builtin display. Can I restore the old behaviour?

 

[alinpanaitiu]

@alinpanaitiu
Thanks for this answer. I'm very impressed especially about the links that lead to parts of the App!!
I'll try with your settings. For now. The turning off was the same as clicking the red ON/OFF button in the top right of the picture of the screen. But I think manual mode should take care of this not happening now.

One final difference now is that my brightness keys control both displays at once. Before, they would control the main display and pressing ctrl-brightness up/down would control the builtin display. Can I restore the old behaviour?

The users are very divided on this behavior so it was hard to choose a default. There’s an FAQ here about going back to the old behavior: Controlling the monitor with the cursor on it

About the turning off, I believe that’s another macOS Gamma bug which started to appear more since the introduction of XDR. The bug zeroes out the RGB Gamma tables causing all the color curves to converge to pitch black. You should be able to see something about zero gamma tables in the Lunar log at ~/Library/Caches/Lunar/swiftybeaver.log

Lunar detects that and tries its best to reset to the default color profile and set generic 0-to-1 Gamma tables but I noticed the bug became worse in Monterey and not even that works until a logout or monitor reconnection.

A lot of bugs that you encounter in Lunar are actually macOS bugs in old APIs that haven’t gotten any attention from Apple engineers for more than 6 years.

 

[ChpStcks]

w

Lunar is mostly made for adding adaptive brightness to external monitors, and controlling every aspect of them.

XDR brightness is mostly a second thought, albeit with a good implementation as it can use Lunar's screen APIs that were built and improved constantly over the last 5 years.

To minimize what Lunar does in the background:

• Use Manual Mode
• Disable Software Dimming in the Controls menu
• Click on Disable all on the Hotkeys page
• Make sure Auto BlackOut is disabled on the builtin display page
• Disable HDR compatibility and a few other things View attachment 1999371

After all that, Lunar should sit idle in the background and just react when you press brightness keys, or when the screen configuration changes (wake/standby/monitor connection events)

Note that without the HDR compatibility workaround, a macOS Gamma bug will make HDR content look overblown when XDR is toggled. I’m still waiting for a response from Apple on this bug.


This should not happen. Lunar keeps the system adaptive brightness running and doesn’t automatically change the brightness of the MacBook screen.

It has to take over the brightness keys so that it can detect when you increase brightness over 100% to activate XDR, or lower below 0% to activate Sub-zero Dimming. But it uses the same brightness APIs that the system uses, so the curve is the same. If it seems choppy, make sure Brightness Transition is set to Smooth on the Configuration page (that should be the default)

Can you share some more details about the turn off problem? I’m not sure what that means.

what's the difference between LunarLite and LunarPro? I don't see the latter in the appstore...

 

[Beau10]

FWIW I use and enjoy Vivid (paid)... it went through some hiccups to start, but now is relatively seamless where it seems like the extra brightness is just integrated into the system. Don't particularly care about bells and whistles, just wish Apple included the extra brightness from the start.

 

[alinpanaitiu]

w

what's the difference between LunarLite and LunarPro? I don't see the latter in the appstore...

LunarLite is just a Software Dimming app, because that’s the only thing allowed on the App Store.

All the other advanced features like hardware brightness control through DDC, XDR Brightness etc. are inside Lunar Pro, which is not on the App Store because it’s not allowed there by Apple’s restrictions.