CGSetDisplayTransferByTable is broken on macOS Tahoe 26.4 RC (and 26.3.1) with MacBook M5 Pro, Max and Neo

Thank you for reporting this — it's a clear and well-documented write-up.

I was able to reproduce this on a MacBook M5 Max running macOS 26.3.1 (25D2128).

I built a small test app that exercises both CGSetDisplayTransferByTable and CGSetDisplayTransferByFormula with several different gamma tables (identity, warm tint, inverted, red-only, gamma 1.8). On the M5 Max:

• Both APIs return kCGErrorSuccess
• Reading back the table with CGGetDisplayTransferByTable returns the correct values that were just set
• No visual change occurs on the display

The same test app works correctly on an M5 (non-Max) machine running the same macOS build — all gamma changes are immediately visible on screen.

This suggests the gamma tables are being stored correctly at the CoreGraphics level, but are not being applied to the display pipeline on M5 Max hardware.

Tested on both built-in and external displays.

I've related your two bugs (FB22273730 and FB22273782) together and attached the sample project I used to reproduce the problem to your bug report.

Please continue to test your software in release and pre-release versions of system software made available to you through your developer.apple.com account. When you do, add details about that into your bug report to keep it up to date. Please see https://developer.apple.com/download/.

Thanks for the thorough write-up and reproduction steps. This is a critical issue for display calibration workflows — tools like DisplayCAL and hardware colorimeters depend on CGSetDisplayTransferByTable for the final LUT upload. The fact that CGGetDisplayTransferByTable reads back correctly but the display pipeline ignores it suggests the disconnect is in the GPU driver or display controller firmware layer, not CoreGraphics itself.

For anyone affected and needing a workaround in the interim: check if setting the ColorSync profile directly via ColorSyncDeviceSetCustomProfiles produces visible changes — it uses a different path to the display pipeline and might bypass whatever is broken in the gamma table application.

An other, related issue with CGSetDisplayTransferByTable() - this is probably not the best place to note this, but since macOS Tahoe there is an inconsistency in how the API works. The 26.4 RC is also affected.

Before macOS Tahoe CGSetDisplayTransferByTable() redefined the color table of the SDR range and clipped the HDR range (much like custom color profiles in macOS usually do the same). In macOS Tahoe it does the same thing for most displays – except for the built-in XDR displays, when auto brightness is enabled and the display is in EDR mode (meaning: there is some HDR content on screen).

When this happens (XDR + auto brightness + EDR mode), the contents of the CGSetDisplayTransferByTable is being used to multiply the entire EDR (SDR+HDR) gamma range instead of overwriting the SDR range and clipping the HDR range. This might be a blessing in disguise for some apps (that use this feature for color adjustments or brightness upscaling like BetterDisplay - as this allows avoiding HDR clipping when a custom color table is being used for image adjustments), but since the behavior is inconsistent (with auto brightness disabled the very same function does affect only the SDR range and clips the enitre HDR range at 1.0 - peak SDR - luminance level as it used to do pre-Tahoe), this is probably just a bug, not a feature. Additionally, when a custom color table is applied to a built-in XDR display while in EDR mode is active, when the user turns of auto-brightness, the color table usually ends up in an inconsistent state (and the screen looks permanently bad until the user changes presets or do something similarly drastic) even after the app using CGSetDisplayTransferByTable() is terminated.

I do not have an FB filed for this one as honestly I saw very low chance of it reaching the appropriate engineers (being such an edge-case) - just wanted this to be out in case somebody in the team working on these things can do something about it. :)

Thank you for the additional detail on the EDR/auto-brightness inconsistency — that's a useful and distinct report.

Please do file a bug report for this second issue. Include a description of the two behaviors (auto-brightness on vs. off) and the inconsistent state you described. I'll check the status next time I do a sweep of forums posts where I've suggested bug reports and post any information about changes I am able to share to this thread. I’m happy to make sure your bug gets routed to the right team.

Bug Reporting: How and Why? has tips on creating your bug report.

Any update on this? Experiencing difficulty with f.lux on my new mbp M5 Max, have to swap my display profile back and forth every night for color changes to occur. Tahoe 26.4

Can we please get a status on this bug/defect and an ETA on fix release date. Than you

Looking at the bugs mentioned in this thread I can see FB22273730 has been assigned to an engineering team for investigation. It is currently open and under investigation. If you are seeing the same problem and it is causing an issue for you, please go ahead and file additional feedback reports so engineering can be aware of how many developers are affected. Thank you.

We are hearing the same from f.lux users on Tahoe 26.5.1 - only M5 Max and M5 Pro seem to be affected.

FB23444164

Maybe relevant here - M5 Pro, macOS 15.1 (24B83)

I cannot use Fine-Tune tool on default Apple color profile on Studio Display, on both 1st and 2nd gen.

When I duplicate the default profile, Fine-Tune is accesible but when I make changes and click "Done", the values are saved but display goes back to default settings despite showing Fine-Tune values are applied to the display unit.

Following this as it causes problems with one of my in-development apps.

Guys at Apple. Its unbelievable - we have now macOS Golden Gate and flux ist still not working since Thaoe. Under Thaoe I could switch the Display Profile and then flux worked. Now under Golden Gaten nothing works anymore.

I thought it would be fixed with Golden Gate. So what's going on? Do we get a fix with 27.1 or does Apple have no interest to fix it? Its already more then a year now.

Please consider filing a bug report about this so our engineering teams can investigate this issue. A resolution may involve changes to Apple's software. If you post the Feedback number here I'll check the status next time I do a sweep of forums posts where I've suggested bug reports.

Bug Reporting: How and Why? has tips on creating your bug report.

For those who have already filed bugs and posted them here I went through all of the bugs and they are still open and under investigation. I will check back again soon.

Hmm. I am not sure how reassuring this response is about the state of things at Apple, after about 7 months of originally reporting this problem. :)