Force RGB Color on M1 Mac

Force-RGB-Color-on-M1-Mac.md

Force RGB Color on M1 Mac

How to Force RGB Color Output instead of YPbPr on your M1 Apple Silicon Mac for an External Monitor.

This step-by-step video tutorial will guide you through the procedure of forcing RGB color output on your M1 Mac.

Here is the direct link to the video tutorial: https://www.youtube.com/watch?v=Z1EqH3fd0V4

The video also has Closed Captions (Subtitles) that you can enable, to make it easier to follow if needed.

Please note that you're doing any changes on your own risk.

Terminal commands used in the video

Here are each of the Terminal commands mentioned in the tutorial, so that you can just copy and paste them:

open /Library/Preferences

plutil -convert xml1

plutil -convert binary1

plutil -lint

The step-by-step procedure on how to force RGB Color Output on M1 and M2 based Macs with Terminal commands

1. Open Terminal and use this command to make Finder select the displays plist file:
   open -R /Library/Preferences/com.apple.windowserver.displays.plist

2. Drag and drop the com.apple.windowserver.displays.plist file to Desktop manually. Don't use the cp command, as it won't add your current user with writing privileges.

3. Convert the file to XML:
   plutil -convert xml1 ~/Desktop/com.apple.windowserver.displays.plist

4. Open the converted file with the default plain text editor (avoid using the built-in TextEdit app if possible, since it might modify the file and make it unreadable by the system)
   open -t ~/Desktop/com.apple.windowserver.displays.plist
   or
   open -a CotEditor.app ~/Desktop/com.apple.windowserver.displays.plist

5. Copy and paste the missing LinkDesription Key under the current display (check the screenshot below for an example of how it should look like):
   

				<key>LinkDescription</key>
				<dict>
					<key>BitDepth</key>
					<integer>8</integer>
					<key>EOTF</key>
					<integer>0</integer>
					<key>PixelEncoding</key>
					<integer>0</integer>
					<key>Range</key>
					<integer>1</integer>
				</dict>

6. Save the file and then convert it to binary again:
   plutil -convert binary1 ~/Desktop/com.apple.windowserver.displays.plist

7. Check if the plist file is valid:
   plutil -lint ~/Desktop/com.apple.windowserver.displays.plist

8. Open the /Library/Preferences/ folder again:
   open /Library/Preferences/

9. Drag and drop the updated com.apple.windowserver.displays.plist file from Desktop to the Library folder manually. Don't use the cp command, as it won't add your current user with writing privileges.

10. Right Click on the com.apple.windowserver.displays.plist file in the Library folder and click on Get Info

11. Check the boxes for Stationery and Locked.

12. Reboot the Mac.

That's it!

(Alternative) Terminal commands to force RGB Color Output on M1 and M2 based Macs and workaround for losing RGB color after waking up from sleep

1. Open Terminal

2. Paste the following commands to edit the User's displays plist file com.apple.windowserver.displays.[UUID].plist using the built-in PlistBuddy function in macOS:

/usr/libexec/PlistBuddy -c "add DisplaySets:Configs:DisplayConfig:DisplayConfig:DisplayConfig:LinkDescription:BitDepth integer" ~/Library/Preferences/ByHost/com.apple.windowserver.displays.*.plist
/usr/libexec/PlistBuddy -c "set DisplaySets:Configs:DisplayConfig:DisplayConfig:DisplayConfig:LinkDescription:BitDepth 8" ~/Library/Preferences/ByHost/com.apple.windowserver.displays.*.plist
/usr/libexec/PlistBuddy -c "add DisplaySets:Configs:DisplayConfig:DisplayConfig:DisplayConfig:LinkDescription:EOTF integer" ~/Library/Preferences/ByHost/com.apple.windowserver.displays.*.plist
/usr/libexec/PlistBuddy -c "add DisplaySets:Configs:DisplayConfig:DisplayConfig:DisplayConfig:LinkDescription:PixelEncoding integer" ~/Library/Preferences/ByHost/com.apple.windowserver.displays.*.plist
/usr/libexec/PlistBuddy -c "add DisplaySets:Configs:DisplayConfig:DisplayConfig:DisplayConfig:LinkDescription:Range integer" ~/Library/Preferences/ByHost/com.apple.windowserver.displays.*.plist

3. Reboot your Mac
   
   

(Workaround) If your Mac loses RGB color after waking up from sleep mode, either Reboot your Mac (recommended) or use this Terminal command to stop the WindowServer and login again (not recommended):

sudo killall -HUP WindowServer

End result

The end result is having your M1 mac output RGB color to your external monitor instead of YPbPr, potentially making the colors more accurate and the text a bit more crisp, even on older 1080p monitors.

Hopefully this tutorial would be useful to someone.

Please feel free to ask in the comment section if you have any questions regarding this procedure.

Background

While doing a lot of testing on how the Dual-Cable workaround makes RGB to work on M1, I've discovered what changes it makes to macOS, and managed to create a more streamlined workaround without the need to use a second cable.

To make things easier, I've created a step-by-step video tutorial of the whole procedure that should force RGB color output on your M1 Mac connected to an external monitor, and works on an HDMI-to-HDMI cable connection.

Credits

Big thanks goes to the amazing community and all their help over the years to solve issues like this:
https://gist.github.com/ejdyksen/8302862
https://gist.github.com/adaugherity/7435890

Useful Sources

Apple Open Source Project Files for Displays and Graphics
https://opensource.apple.com/source/IOKitUser/IOKitUser-1445.60.1/graphics.subproj/IODisplayLib.c
https://opensource.apple.com/source/IOGraphics/IOGraphics-517.17/IOGraphicsFamily/IOFramebuffer.cpp.auto.html

How to Edit and Convert binary plist files
http://hints.macworld.com/article.php?story=20050803111126899
https://apple.stackexchange.com/questions/155393/how-to-beautify-binary-dict-files
https://discussions.apple.com/thread/1768480

How to Edit plist files using defaults and PlistBuddy
https://ss64.com/osx/defaults.html
https://github.com/mathiasbynens/dotfiles/blob/master/.macos

Apps based on this method

@sudowork has created an awesome script written in Phyton that automates the steps and checks for duplicate files.
You can find more info about it here: https://github.com/sudowork/fix_m1_rgb

@dangh has created an alernative script for fishshell.
You can find more info about it here: https://github.com/dangh/force-rgb.fish

@GetVladimir I've also created a Shortcut to Force RGB Color Output using the built-in Shortcuts app.
You can find how to create the Shortcut here: https://gist.github.com/GetVladimir/c89a26df1806001543bef4c8d90cc2f8?permalink_comment_id=4531552#gistcomment-4531552

@entropyconquers has created a script based on this method written in Phyton that automates the steps, makes a backup and checks for duplicate files.
You can find more info about it here: https://github.com/entropyconquers/Force-RGB-Color-on-M1-M2-Mac-Script

Additional notes

Multiple PixelEncoding and Range keys in the same plist file
Note that there might be multiple instances of the PixelEncoding and Range keys in the same file, one for each output of your monitor and for different AirPlay devices. You might need to update the integer on each one to get RGB color output on all displays.

Getting RGB color only before login
There might be multiple duplicate plist files with the same name in different locations.

Make sure that you only have the main modified file in:
/Library/Preferences

Then make a backup and remove duplicate displays plist files from these locations (if any):
~/Library/Preferences
or
/Users/username/Library/Preferences
and
/Users/username/Library/Preferences/ByHost

Please note that you'll need to have administrator privileges in order to modify the file in /Library/Preferences. Thanks goes to @keegandent and @StrategicalIT for pointing this out.

Updates regarding macOS Monterey

USB-C to DisplayPort
From what I've seen, it seems that macOS Monterey 12.0.1 finally outputs RGB color by default on some monitors when using USB-C to DisplayPort cable on M1 Apple Silicone Macs.

You might need to make a backup and delete these 2 files:
/Library/Preferences/com.apple.windowserver.displays.plist
and
/Users/yourname/Library/Preferences/ByHost/com.apple.windowserver.displays.[UDID].plist

Restart your Mac and it should properly output RGB color on the monitor on the next boot.

HDMI to HDMI
The situation with HDMI seems to got a bit more complicated. Now the whole section for the LinkDescription might be missing from the com.apple.windowserver.displays.plist on a clean install and doesn't seem to be recreated when rotating the screen either.

Luckily, the solution still works, but you might need to manually add this whole section in the displays plist file:

					<key>LinkDescription</key>
					<dict>
						<key>BitDepth</key>
						<integer>8</integer>
						<key>EOTF</key>
						<integer>0</integer>
						<key>PixelEncoding</key>
						<integer>0</integer>
						<key>Range</key>
						<integer>1</integer>
					</dict>

The section usually goes right under the CurrentInfo key, and it should look something like this:

This should get your RGB color output working on M1 Mac mini, even when connected with HDMI to HDMI cable.

Multiple monitors when one them is using HDMI to HDMI
Additional thanks goes to @somogyi-ede who tested this with multiple monitors and confirmed that the LinkDescription key needs to be added under each monitor instance in order for all of them to receive RGB color output. Link to the comment

Updates regarding macOS 13 Ventura

USB-C to DisplayPort
The macOS 13 Ventura beta seems to outputs RGB color by default on some monitors when using USB-C to DisplayPort cable on M1 Apple Silicone Macs.

You might need to make a backup and delete these 2 files:
/Library/Preferences/com.apple.windowserver.displays.plist
and
/Users/yourname/Library/Preferences/ByHost/com.apple.windowserver.displays.[UDID].plist

Restart your Mac and it should properly output RGB color on the monitor on the next boot.

HDMI to HDMI
Similar as macOS Monterey, the situation with HDMI on macOS Venturs seems a bit more complicated. Usually the whole section for the LinkDescription might be missing from the com.apple.windowserver.displays.plist on a clean install and doesn't seem to be recreated when rotating the screen either.

Luckily, the solution still works, and you still need to manually add this whole section in the displays plist file:

					<key>LinkDescription</key>
					<dict>
						<key>BitDepth</key>
						<integer>8</integer>
						<key>EOTF</key>
						<integer>0</integer>
						<key>PixelEncoding</key>
						<integer>0</integer>
						<key>Range</key>
						<integer>1</integer>
					</dict>

The section usually goes right under the CurrentInfo key, and it should look something like this:

This should get your RGB color output working on M1 Mac mini, even when connected with HDMI to HDMI cable.

(Optional) Lock the plist file and set it as stationary
After the macOS Ventura 13.3 update, the plist file seems to get overwritten on reboot.

After you make the edits in the file, you can try setting the file /Library/Preferences/com.apple.windowserver.displays.plist as Stationery pad and Locked, so that it doesn't get overwritten on every reboot

To do this, right click on the plist file, click on Get Info and check the boxes next to Stationery pad and Locked

This requires further testing and might cause some issues, like not being able to remember new resolutions or display settings. Please note that you're making any changes at your own risk.

Updates regarding macOS 14 Sonoma Beta

USB-C to DisplayPort
The macOS 14 Sonoma seems to outputs RGB color by default when using USB-C to DisplayPort cable.

HDMI to HDMI
The macOS 14 Sonoma seems to outputs YCbCr color by default when using HDMI to HDMI cable.

• Forcing RGB Color Output still seems to work with the original procedure of modifying the plist files

• Modifying the display plist files still works with the alternative version

• After the plist files are modified, putting the Mac to sleep and waking it, it seem to keep the RGB Color output (this seems to be fixed at least on a M1 Mac mini)

If you have any additional questions, please feel free to contact me.

I have found that as soon as the screen goes to sleep or I unplug it, the fix no longer works. A reboot solves the problem but only as long as you keep the screen awake. Any solution for this?

@esmorun

Paid - Yes.
Free - No.

Best bet would be Sonoma. But its still in beta so not recommended.

@traderdude123 does Sonoma beta fix the problem or just a guess?

@traderdude123 Has it been confirmed fixed in Sonoma? The bug has been around for as long as I have had my M1 air so I wouldn't count on Apple ever fixing the bug.

By the way you should all make sure to send a report to Apple: https://www.apple.com/feedback

@jacek-jablonski
@esmorun

I have not tested on Sonoma. waiting for public release.

But i have read reports from other users who are using beta. They are even getting 4k 120hz RGB 10 bit with AMD 6000 Series cards on hackintosh's as well. This was not possible on Ventura. So its high likely that the sleep issue could be fixed on Sonoma.

if anyone is brave enough to test it on beta. It would be great. If anyone does test it. please let us know.

I've just tested it on Sonoma Developer Beta 3. I've deleted all the display plist preferences files and started fresh.

Here are the results:

• The HDMI to HDMI connection still defaults to YCbCr Color Output (as usual)
• The USB-C to DisplayPort connection defaults to RGB Color Output (as usual)
• Forcing RGB Color output still seems to work with the original procedure of modifying the plist files
• Modifying the display plist files still works with the alternative version
• After the plist files are modified, putting the Mac to sleep and waking it, it seem to keep the RGB Color output (so this one seems to be fixed, at least on a M1 Mac mini)
• There was a strange issue with the Magic Mouse connecting and disconnecting every few seconds after restarting Sonoma a few times. Turning off the Magic Mouse and turning it on seems to fix this for the moment.

@GetVladimir

Thanks for the confirmations. Finally, some progress.

Also the HDMI-HDMI defaulting to YCBCR is actually correct since HDMI is predominantly used by TVs and YCBCR gives the best picture quality. However if you want to use it as a Monitor we need RGB. But normally its not expected that people use TV as monitors.

For monitors , USB-C/DP is primary connection and hence defaults to RGB , which is also the correct thing to do.

But what apple needs to provide is a user selectable option in the Display section of settings for YCBCR or RGB.

@traderdude123 not a problem, thanks for the reply.

Yes, indeed. It seems that Sonoma is getting more optimized than Ventura ever was

Hi @GetVladimir , many thanks for this info, I have just fixed a new M2 mac mini connected to an Acer widescreen monitor via HDMI (for the moment, usb->DP is the next step) using it.

However I am wondering why your examples have the Range key set to 1, which appears to give limited range colour; surely for any computer monitor, and to be honest any modern TV really, you want full range colour, which appears (visually at least, the monitor doesn't report the full format details in its OSD unfortunately) to be the case when the range key is set to 0.

@DeepSubMicronMusic Thank you for the reply and I'm glad that you got RGB color output working.

That's a good question. I don't really have confirmation that the Range key affects full and limited color (even though initially that might make sense).

The reason why I set the Range to 1 in the original tutorial is because macOS ignored the display plist file if you set it to 0.

If you can set it to 0 and macOS still accepts the plist file in the newer versions, you might want to try using that instead

@GetVladimir OK, so although it is a data point of one, I can say that on the latest OS release changing this value to zero for me has the effect that I would expect switching to full range, i.e. blacks are now properly black, and whites are properly white. I wish I still had access to a HDMI analyser to see what was really happening both with the signal format and the infoframes, but sadly that was a former life.

I would suggest giving it another go, for me it made a big difference to the contrast on the UI in dark mode, but more importantly shadow detail on images now looks correct rather than washed out and posterized (which is the problem that actually led me to find this post, because I recognised that it probably meant the output the format was wrong).

@DeepSubMicronMusic thank you for the info, I appreciate it. Those are good points.

I think we might need to test it connected to a TV, since those usually have options in the settings to show when they are receiving limited or full range.

Technically, they should adjust automatically on the receiving and to match the output source, but it's nicer to have full range when possible

Hi Vladimir,

thank you for all your work and detailed instructions but I tried that from your Youtube video but it doesn't work. I still get fuzzy colors wenn switching my Dell monitor to RGB mode.
I have a MacBook Pro 14 (M1 Pro) and MacOS 13.4.1 (c).
Any ideas?

@cooltig thank you so much for the comment and for the details.

I'm guessing this might be the same question posted on the Reddit topic, so I'm going to post the answer here too for future reference.

If your monitor is Dell and uses USB-C to USB-C connection, please make sure to turn off High Data Speed and choose High Resolution instead in the Monitor menu.

As you've mentioned, you might also need to turn off MST and DDC/CI

@GetVladimir Thank you very very much!

@dainiusm07 you're very welcome.

Thank you so much for your comment and I’m glad if you found the guide useful

@GetVladimir A quick update from my playing about. While setting up more things on the new mac I did something (possibly related to using the rectangle window manager or tinkertool to change some dock settings) which caused the display output format to reset again for my login, i.e. it was still fine for the login screen on reboot but as soon as I logged in I was back to the wrong output format.

Having backed out the changes I had been making to the dock settings and uninstalling bits of software running at login that might have been effecting it to no avail and finding that it wasn't something simple like a new display plist file appearing in my local library, I was a bit concerned that I wasn't going to be able to get the output format back to what I wanted. So I had a step back and a bit of a think about what was going on.

I came to the conclusion that the advice to delete the user specific display plist in ByHost was probably mistaken and that the better advice would be to make the same plist property changes to both the system file and the local user version of the file. As I had saved the original before deleting it (I hope everyone has taken that advice) I put it back with the change made and it is now working again. As a side note, this doesn't solve the problem of the screen sleeping breaking it again until reboot, but I think it is a more robust change than simply deleting the user version of the file.

@DeepSubMicronMusic thank you for the update and for the details.

Yes, the alternative method modifies the ByHost display plist file, same as you've suggested: https://gist.github.com/GetVladimir/c89a26df1806001543bef4c8d90cc2f8#alternative-terminal-commands-to-force-rgb-color-output-on-m1-and-m2-based-macs-and-workaround-for-losing-rgb-color-after-waking-up-from-sleep

Losing the RGB color output when waking from sleep was a bug in macOS, and it seems to be fixed in macOS Sonoma Beta

It seems that when RGB output is lost after waking up from sleep it could be restored without restarting the Mac. Manual Log Out is enough to get back the RGB

@dainiusm07 yes, you're right. As long as the ByHost display plist file is modified, it should be re-read on login again.

It should technically be read on wake from sleep, but there seems to be a bug in the later versions of Ventura.

In macOS Sonoma beta, the waking up from sleep seems to be fixed already

I managed to resolve RGB loss on wake up bug by accident on my macbook. For folks using macbooks:

1. Unplug your monitor
2. Restart macos
3. Login
4. Plug your monitor
5. Put macbook to sleep manually & verify that after waking it up RGB is in place

I'm on Macbook Pro M1 with Ventura 13.4.1 (c), plugged via HDMI-HDMI. Also I have edited both plist files in /Library/Preferences and in $HOME/Library/Preferences/ByHost and both files are configured to support RGB on both variants (macbook screen + external monitor & only external monitor)

@dainiusm07 thank you for the details and for the step-by-step guide for the solution.

Let's see if other users can replicate it too.

I'm currently on the Sonoma beta, and it seems to work by default

I can confirm that the procedure from @dainiusm07 worked on my M2 14 mackbook pro too.

@zdenek-jonas thank you so much for checking this and for the confirmation

Unfortunately, the next day to wake up the PC it's flipped again. I am going to try Sonoma Beta

@zdenek-jonas Have you edited both files in /Library/Preferences and $HOME/Library/Preferences/ByHost ? Make sure that your external monitor refresh rate is set to the same value on all variants of monitors combinations & it is the same in both files. Different refresh rates causes external monitor to flash on closing/opening macbook screen and I guess it could cause some kind of issues

@zdenek-jonas Have you edited both files in /Library/Preferences and $HOME/Library/Preferences/ByHost ? Make sure that your external monitor refresh rate is set to the same value on all variants of monitors combinations & it is the same in both files. Different refresh rates causes external monitor to flash on closing/opening macbook screen and I guess it could cause some kind of issues

I have already installed Sonoma Beta. Now it stands RGB. Before that everything worked fine until I closed the laptop once, connected to the monitor. Since then, I've tried absolutely everything but it never worked like it used to. Let's see now.

If anyone willing to pay for an easier solution, buy BetterDisplay app and follow this instruction. There're some great improvement over the plist manipulation method:

• The EDID get re-applied when you turn the monitor on/off automatically, so you don't have to restart your Mac.
• If some other apps mess up your display (Dota 2 in my case), it won't anymore because the display now has a fixed config. Even if it does, you can just re-apply the EDID manually.

This method doesn't work on my M1 MacBook (Monterey). The lines of code to be changed didn't exist in my displays plist file, so I just added them. What I found confusing was that my plist file seemed to contain much more code than Vladimirs. It contains around 650 lines of code with a repeating structure of "Current Info", "Rotation" and "UnmirrorInfo". I inserted the additional code just below the first "Current Info" block, exactly as in Vladimirs screenshot.

I have a Dell U2720Q monitor connected via USB-C. It seems that whenever I first launch the MacBook and then switch on the monitor, the color is set to YPbPr. If I want RGB color I need to reset the monitor to RGB (which results in a pink-green display), then unplug the USB-C cable and plug it in again. Modifying the displays plist file hasn't changed this behavior. I also tried deleting both plist files (including the on in the ByHost folder) and then modifying the one that has been newly created.

@BermudaBen thank you for your comment.

Please check in your monitor setting for an option where you can choose between "High Data Speed" and "High Resolution" and set it to "High Resolution".

If that doesn't work or if you need the faster data on the USB ports of the monitor, please connect the M1 MacBook to the Dell U2720Q with USB-C to DisplayPort cable instead

@GetVladimir Thank you for your reply. The monitor is set to "High Resolution". As for the connection: This would mean I won't be able to charge the MacBook from the Dell monitor, right? Why would it make a difference to use the monitors DP port instead of the UBS-C port? The video signal is DP in both cases. And: Do you know if this is a Dell-specific issue?

@BermudaBen not a problem, thank you for the reply.

When you mentioned that you have over 650 lines of repeating instances of Current Info in the plist file, this usually points to having a dock in the middle of the connection.

It seems that the USB-C to USB-C connection is considered as connected through a dock inside the monitor and then being converted.

The M1 MacBook doesn't seem to see it same as having an actual USB-C to DisplayPort connection.

This might depend on what type of conversion happens in the monitor and it's not isolated to only Dell monitors.

After numerous attempts without success, I finally managed to succeed. I will record what I tried.

[1] I attempted to edit /Library/Preferences/com.apple.windowserver.displays.plist. This method involved changing the refresh rate and other display settings, but it failed.

[2] Next, I tried alternative method, but I couldn't find com.apple.windowserver.displays.[UUID].plist in /Users/username/Library/Preferences/ByHost. However, rotating the screen created a new com.apple.windowserver.displays.[UUID].plist. After executing Terminal commands, I finally achieved RGB!

Thanks to GetVladimir and everyone.

Lastly, I'll provide details about my setup: Mac mini M2, Mac OS 13.4.1 (c), HDMI to HDMI, DELL S2722DC.

@satori-mitora thank so much for your comment and for the detailed steps. Glad to hear that you got RGB color output working

UPDATE: See my latest reply in this gist for complete steps for fixing this problem

If you're stuck with reseting to YPbPr after reboot or sleep here's what worked for me:

1. Take the steps to edit plist in /Library/Preferences
2. Remov plist in ~/Library/Preferences/ByHost
3. Reboot

I removed the plist in ~/Library/Preferences/ByHost in recovery mode because i couldn't log in anymore since i somehow corrupted it .. but i guess it might work in the regular environment as well

okay so that was a short lived fix. here's how i got it to work better now:

• Remove plist in /Library/Preferences
• Remove plist in ~/Library/Preferences/ByHost
• Empty trash
• Reboot
• Connect monitor via HDMI and close the macbook lid
• Copy plist in /Library/Preferences to desktop, convert to xml, add lines below these steps after each <key>CurrentInfo</key><dict>...</dict> entry, convert back to binary, replace original file
• Set the file to Stationary pad and Locked under file info in finder
• Reboot
• Open System Settings > Displays > Rotate your external screen 90deg and back
• Copy plist in ~/Library/Preferences/ByHost to desktop, convert to xml, add lines below these steps after each <key>CurrentInfo</key><dict>...</dict> entry, convert back to binary, replace original file
• Set the file to Stationary pad and Locked under file info in finder
• Reboot

Now every time i start my macbook with the lid closed and connected to the external monitor, the external monitor receives RGB signal upon login.

The login screen for some reason starts in HDR+ mode (lol)

The external monitor for some reason looses RGB mode and switches back to YPbPr mode when disconnecting and reconnecting the HDMI cable though. But i can live with a setup where upon startup things work as expected.

Anyway, waiting for the fall release of the new OS where this nonsense has been fixed..

UPDATE: See my latest reply in this gist for complete steps for fixing this problem

@loucyan thank you for your comment and for the steps on how to fix it

The menu on the LG UltraGear 27GL83A doesn't show the color format, but you can find it in the service menu by doing the following:

1. Turn off the monitor by pressing in the control stick on the bottom
2. Press the control stick left 3 times and right once
3. Turn the monitor back on by pressing in the control stick
4. Open the menu by pressing in the control stick and then pressing it right. This should open the service menu instead of the normal menu
5. Scroll to "DEBUG INFO." using the control stick (pressing it upwards 3 times should loop round to the debug info) and press it right to enter the debug info menu
6. Note the "COLOR FORMAT" displayed

You can exit the debug menu by pressing the control stick left, then exit the service menu by scrolling off the bottom of the menu using the control stick (pressing it downwards twice should do it) and pressing the stick in. Be sure not to accidentally change any values in the service menu!

These steps should hopefully work for other LG monitor models too.

@jackwilsdon that is awesome info! Thank you so much for sharing the detailed steps

@GetVladimir thank you for your work. I couldn't understand why apple put us through this! but thank you and the kind people out their providing this solution. BTW i struggle a bit, until i read about the byHost folder. I delete all the com.apple.windowserver.* files and now my mac m1 behaves.

@ioctlsg Thank you so much for your comment and I'm glad to hear that you got RGB color output working

Anyway, waiting for the fall release of the new OS where this nonsense has been fixed..

Wait, they fixed it? Do you have a source talking about this?

Anyway, waiting for the fall release of the new OS where this nonsense has been fixed..

Wait, they fixed it? Do you have a source talking about this?

@vittau under Sonoma you still have to do the configuration manually, but the wake from sleep and unplugging the external monitor and plugging back in works as expected now as the external monitor retains RGB signal

Here's the steps for Sonoma. Do exactly what it says here, or you will end up with a partially working setup. To my findings all the rebooting is necessary to also capture the login screen configuration.

1. Unplug external display, use only your laptop display for now
2. We want to start with a clean configuration, so delete the two com.apple.windowserver.* plists under /Library/Preferences and ~/Library/Preferences/ByHost
3. Reboot
4. Now we want macOS to set up all configurations that will naturally occur when using our setup. Open System Preferences and set your desired resolution scale
5. Reboot
6. Keep your laptop display open and plug in the external display. Open System Preferences and set your desired resolution scale and assign the desired main display where your dock and main windows will appear
7. Reboot
8. Close your laptop display so only the external display is being used. Open System Preferences and set your desired resolution scale
9. Reboot. Then, reboot again
10. Now we have all possible configuration variants set up in both plists. Copy the two com.apple.windowserver.* plists under /Library/Preferences and ~/Library/Preferences/ByHost to your Desktop manually (cp command will not transfer the needed user privileges)
11. Convert both plists on your Desktop to xml format with plutil -convert xml1 ~/Desktop/com.apple.windowserver.*
12. Open both plists in a text editor. We now want to find occurrences of only the external display and add some additional config lines to them. I'm not sure how to identify them properly, but my external display is 60Hz so that's what i used to differentiate from the 120Hz built-in display configs. Add the code at the bottom of this reply to each external display config in both plists. Consult the screenshot provided in the original gist at the top to where exactly it should be placed
13. Save both plists and convert them back to binary with plutil -convert binary1 ~/Desktop/com.apple.windowserver.*
14. Check if the plists are valid with plutil -lint ~/Desktop/com.apple.windowserver.*
15. Manually copy the updated plists back to their respective folders
16. Right click and Get Info on both, and set them to Stationary pad and Locked
17. Reboot and enjoy

<dict>
<key>BitDepth</key>
<integer>8</integer>
<key>EOTF</key>
<integer>0</integer>
<key>PixelEncoding</key>
<integer>0</integer>
<key>Range</key>
<integer>1</integer>
</dict>

@loucyan thank you so much for the detailed steps and explanation

So when Sonoma was released and theoretically Big Sur won't be getting any more updates I finally upgraded to Monterey 12.7 (I always stay a couple versions back for sanity on my main work machine). I had this RGB mode working under Big Sur but Monterey broke it and I can't seem to get it back.

My main monitor is a 27" Dell S2721QS 4K monitor, connected HDMI-to-HDMI directly to my M1 Mac Mini. My second screen is a 27" LG 27LQ635S-PU FHD TV, connected HDMI-to-HDMI through a USB-C Dock. I'm using a Display Override with "DisplayIsTV" set to false to prevent macOS seeing the HDTV as a TV, so I can set it to 1920x1080 instead of 1080p, which vastly improved text legibility on it, but I have no idea if that monitor is actually in RGB color mode or not, I'm assuming it is because it's not blurry anymore, but text quality did slightly degrade after moving to Monterey.

I had my /Library/Preferences/com.apple.windowserver.displays.plist locked when I upgraded and it was still there and locked after Monterey installed, but doesn't seem to actually be doing anything anymore. I've tried deleting the one "windowserver" file I had in ~/Library/Preferences/ByHost/com.apple.windowserver.displays.[UUID].plist and it respawned but still no RGB mode on my Dell monitor. I also tried adding another file to my Displays Overrides for the Dell also with "DisplayIsTV" set to false, but that didn't work either.

As a side note, Monterey also can't seem to remember my monitor arrangement. I have to reorder them every time I reboot.

At this point, the only reason I care about trying to get the Dell back into RGB mode is because it now randomly experiences the flickering and ghosting problem, which I never saw under Big Sur so long as it was in RGB mode.

In addition to two HDMI 2.0 ports the Dell monitor does have a DisplayPort 1.2 on it too, but I don't have any cables, adapters, or docks for it. I haven't seen anyone talking about using an HDMI-to-DisplayPort cable or adapter, or what color mode that defaults to, but I'm assuming it would have to be an active adapter. Unless a USB-C dock with DisplayPort would be a better option, and then plug my LG HDTV into the Mac's HDMI out? I'd really hate to have to buy new hardware to work around what is clearly a software problem.

@kmhcreative thank you for your comment and for the details.

You might want to try modifying the displays plist file in the ByHost too, as it will take precedence over the one in the Library.

Regarding the monitor arrangements, this was issue in Monterey and I'm not sure if it got resolved.

The workaround is to try a different HDMI port on the monitor and see if that helps

I tried using the "alternative" terminal commands shown above to modify the ByHost plist file and on reboot the Dell monitor is still in YPbPr color mode. I'll try the second HDMI port and see if that at least fixes the arrangement problem.

@kmhcreative thank you for the reply. You will have to modify two UUIDs in the plist file, since you have 2 monitors connected. Each one is only applied for one monitor.

Ok, if I’m understanding you correctly, you’re saying I should have TWO plist UUID files in my ByHost folder, one for each monitor? But I’ve only ever had one UUID plist file in my ByHost folder. If I delete it macOS only recreates one file. I have no idea if this matters, but in the “Mission Control” settings I have “Displays have separate spaces” checked — but I’d think if anything that would make it more likely to create two display files, since it’s not seeing both screens as one space.

And inside that plist file there are ELEVEN sub-arrays under key “Configs” each of which has two main sub-sections, seemingly referring to two separate monitors, one of which has an “OriginX” of “-1920.”

I have this old Ruby script that seems to still pull EDID UUIDs for each monitor. But NONE of the UUID strings in my plist files match the EDID UUIDs that Ruby script pulls. The UUID on the plist filename doesn’t match either of them either.

When I manually rearrange the monitors to their actual positions, instead of updating any of the existing configs, it simply inserts another new array with two sub-sections with UUIDs that don’t match anything else. So now there are an even DOZEN entries in that file.

I should note that only the last three of the Config arrays have “LinkDescription” sections until I run those “alternative” terminal commands. Which, by the way, shouldn’t there be another line on the end that reads:

/usr/libexec/PlistBuddy -c "set DisplaySets:Configs:DisplayConfig:DisplayConfig:DisplayConfig:LinkDescription:Range 1" ~/Library/Preferences/ByHost/com.apple.windowserver.displays.*.plist

Otherwise it sets the Range to 0.

But the terminal commands only add the “LinkDescription” stuff to the first entry under “Config” and as soon as I manually re-arrange my monitors it overwrites it and the “LinkDescription” is gone. Not that it actually did anything in the first place.

Why does my Mac only create only one UUID display file in ByHost? And why does it have nearly a dozen entries, most of which don’t have a “LinkDescription” sub-section? Why does rearranging the monitors just add new entries to the file instead of changing configurations that are already there? Why do NONE of the UUID strings in that file seem to match the EDID UUIDs the Ruby script pulls?

On the other issue, switching HDMI ports on the monitor didn’t fix the arrangement problem. Switching which monitor is plugged into the Mac Mini HDMI and which is connected to the USB-C Dock, does fix the arrangement problem, but it always considers the HD screen the “Main” display, and even if I switch it in settings on the next boot it reverts back. It will ALWAYS set the Mac Mini’s HDMI port to “Main” and it will always position it to the left of the other display.

No changes in System Preferences will persist after a reboot.

I’m about ready to just give up on this. Thanks for your help though.

@kmhcreative you're welcome, glad if it helps.

There is only one displays plist file in ByHost folder.

Inside that file, there should be multiple UUID displays. You can add the LinkDescription to each one manually if you want to be sure.

Please note that you can't use the other scripts as they are only for x86 based Macs and they won't match the Apple Silicon UUIDs.

That being said, if you don't want to bother with this, the easiest workaround is to just connect both monitors with an USB-C to DisplayPort cable directly, without using a dock.

It will take up 2 USB-C ports on your Mac, but the displays should work properly and output RGB color

Fixed it!

Remember how I said that my locked /Library/Preferences/com.apple.windowserver.displays.plist file from Big Sur was untouched after my upgrade to Monterey? That was the problem. I had to trash that file and force macOS to generate a new one. But the XML <dict> literally just had UUID entries in it, nothing else. It wasn't until I went into System Preferences and rearranged my monitors correctly that it updated that plist file with actual configurations for both my monitors. Minus the "LinkDescription" sections, of course.

Then I went through the steps outlined above to add the "LinkDescription" section to each monitor's entry, rebooted, and my display arrangement is correct and my monitors are in RGB mode.

I stupidly assumed that the plist file from Big Sur would just work with Monterey, so the one thing I hadn't tried was getting rid of it and making Monterey generate a new one to edit, and I didn't think I needed to edit the Big Sur plist because it already had the "LinkDescription" sections in it. But Monterey clearly didn't like something in that file, and because it was locked it couldn't update it.

Lesson learned, now I know what I need to do when I eventually upgrade to Ventura so I won't lose my RGB mode again.

@kmhcreative awesome! Thank you for the update and the solution, and I'm glad to hear that you got RGB color output working

@GetVladimir many thanks for the great work that you have put in! I wanted to add a few things.

Alternate terminal way
This is a very nice and quick way to update plists, however, the values should be populated and Range is very important. This is the only way it works on my MacBook M2 Pro with LG C2. Also, if you have a true 10bit display, use BitDepth 10.
/usr/libexec/PlistBuddy -c "add DisplaySets:Configs:DisplayConfig:DisplayConfig:DisplayConfig:LinkDescription:BitDepth integer" ~/Library/Preferences/ByHost/com.apple.windowserver.displays..plist
/usr/libexec/PlistBuddy -c "set DisplaySets:Configs:DisplayConfig:DisplayConfig:DisplayConfig:LinkDescription:BitDepth 10” ~/Library/Preferences/ByHost/com.apple.windowserver.displays..plist
/usr/libexec/PlistBuddy -c "add DisplaySets:Configs:DisplayConfig:DisplayConfig:DisplayConfig:LinkDescription:EOTF integer" ~/Library/Preferences/ByHost/com.apple.windowserver.displays..plist
/usr/libexec/PlistBuddy -c "set DisplaySets:Configs:DisplayConfig:DisplayConfig:DisplayConfig:LinkDescription:EOTF 0” ~/Library/Preferences/ByHost/com.apple.windowserver.displays..plist
/usr/libexec/PlistBuddy -c "add DisplaySets:Configs:DisplayConfig:DisplayConfig:DisplayConfig:LinkDescription:PixelEncoding integer" ~/Library/Preferences/ByHost/com.apple.windowserver.displays..plist
/usr/libexec/PlistBuddy -c "set DisplaySets:Configs:DisplayConfig:DisplayConfig:DisplayConfig:LinkDescription:PixelEncoding 0” ~/Library/Preferences/ByHost/com.apple.windowserver.displays..plist
/usr/libexec/PlistBuddy -c "add DisplaySets:Configs:DisplayConfig:DisplayConfig:DisplayConfig:LinkDescription:Range integer" ~/Library/Preferences/ByHost/com.apple.windowserver.displays..plist
/usr/libexec/PlistBuddy -c "set DisplaySets:Configs:DisplayConfig:DisplayConfig:DisplayConfig:LinkDescription:Range 1” ~/Library/Preferences/ByHost/com.apple.windowserver.displays..plist

Regarding YCbCr444 vs RGB
If you have a Mac with HDMI 2.1 (starting with M2 Pro) and are able to get 10bit YCbCr444 (check screen OSD information, if on LG C2, keep clicking green button on the remote) working by default, I do not recommend messing around. 4:4:4 means no chroma subsampling and you will get absolutely no visual benefits from trying to get RGB to work. In theory, RGB has a slightly wider range, but as long as both your screen and computer are working on the same range (i.e. limited or low black level), it will sort itself out so that no one ever will be able to see any difference (especially at 10bit). Rather focus on getting a good calibration and your creative work.

@Eclipt1c Thank you so much for your comment and for the additional info for 10 bit color.

Regarding the YCbCr444 vs RGB, it seems there is a difference in the default color profile that macOS chooses, which could affect colors and calibration

When connecting to HDMI on my m1 MacBook Air, RGB output was successful, but the gamma value was destroyed (presumed to be an HDMI bandwidth issue).
When connected via DP, ypbpr is still output (in this case, the gamma value is normal).

@mnsk0000 if you're using a Dell monitor, make sure to set the Gamma to PC instead of Mac in the Monitor built-in menu and see if it makes a difference

@GetVladimir I using a Dell monitor, But this model not support Gamma setting menu

@mnsk0000 In that case, you can try changing the gamma in the color profile. Here is how to calibrate it in macOS Sonoma: https://support.apple.com/en-ie/guide/mac-help/mchlp1109/mac

@GetVladimir I can't setting gamma to Display Calibrator Assistant. I was only able to change the color temperature through this.

When connecting to HDMI on my m1 MacBook Air, RGB output was successful, but the gamma value was destroyed (presumed to be an HDMI bandwidth issue). When connected via DP, ypbpr is still output (in this case, the gamma value is normal).

When I connected both hdmi and dp and output to dp, I succeeded in outputting RGB from dp.
However, the gamma value still appears to be destroyed, so it may not be an HDMI issue.

@mnsk0000 Make sure to hold the ALT/OPTION button on your keyboard while clicking on the + on the color profile.

It should appear a checkbox with Expert Mode and the Gamma should be available:

@GetVladimir Thanks you
Have you or anyone else had any gamma issues?
monitor.co.kr The third on this site list is the contrast ratio test.
I couldn't distinguish values ​​above 92 in this test (I could distinguish them in ycbcr state)

@mnsk0000 Thank you for the info. I personally haven't noticed issues with Gamma unless the setting on the Monitor itself is set to the wrong value.

The slider that you've posted might be affected by contrast and brightness also though, as well as high RGB and low RGB (limited RGB and full RGB) range values

@GetVladimir When I connected it with DP
I found that it works as RGB at 30hz and ypbpr at 60hz.

@mnsk0000 that doesn't sound right. Are you sure the USB-C to DisplayPort cable that you use is good for 4K60? (Many usually are)

@GetVladimir The cable is fine. I Connected to DP-DP via Hub.
This could be a case of my hub or monitor being unusual.

@mnsk0000 thank you for the reply and for the info.

You're right, in that case the issue is very likely the hub not supporting 4K60 output.

Connecting your M1 MacBook Air with a direct USB-C to DisplayPort cable to the Dell monitor should solve the issue

Gave up troubleshooting and just got 2 USBC-DisplayPort cables and all works fine in RGB now lol. Appreciate the effort.

@Averyy that is probably the best solution, other than the issue being fixed in macOS.

Thank you for the reply and the update, and glad to hear that you got it working

I'm rocking two U2722D, and they're stuck at YPbPr. I've tried all your suggestions, but I've not been able to force RGB to work with my hardware combo:

• MacBook Pro M1 Pro
• macOS Sonoma 14.2.1
• Two Dell U2722D (1440p, QHD, 60Hz)
• Satechi Type-C Dual Multimedia Adapter with Dual 4K HDMI, connected to the screen with two HDMI cables

Have anyone else managed to get this combo working?

The problem for me, is that the Dell screens generate wierd things if low-light grey text is on the screen, like described in the Reddit post "M1 Mac + Dell Monitor Flickering Issue Fixed - S2722QC - USB-C - Monterey".

Once occurred once (the flickering), it's even visible in the Dell "diagnostics" mode on the screen:

It's not a problem in RGB Color-mode, which I use at home (See Bonus info at the bottom)

I'm still unsure what's going on?

My two old U2515H's was rocking on the same system with no issues what so ever.

I'm using the Satechi-adapter which did work just fine with two U2515H's, so I'm unsure why the two U2722D does not work with the same cables and adapter. I though I upgraded my setup, but it's a pain right now...

Dell did get all the details on WhatsApp, and decided to replace the two U2722D screens with two refurbished U2722D, even though I clearly mentioned that it must be related to software/firmware.

Maybe I need to give the USB-C > DisplayPort cable a go? But, that would require me to manually plug four cables in the laptop at all time, which is not ideal.

Bonus info: At home I'm also using two U2722's and they work just fine, but here I have a DisplayLink dock in between (Lenovo 40AF with DisplayLink), which gives RGB output just fine. I know that's not a solution by itself, as it's requires a dock + adapter to the Lenovo dock, and adds a bit of delay as DisplayLink needs to proces the output, too. And the DisplayLink software to be running in the background as well...

@exetico thank you for your comment and for the useful details.

My guess regarding why the 2515H worked while the U2722D is that the 2515H defaults to RGB when initializing the HDMI connection.

You've mentioned that all 4 ran at the same resolution and refresh rate, so that shouldn't be the issue.

From the image you've posted, it's very strange that they have what looks like image retention, even on the Dell diagnostic screen.

If possible, it might be a good idea to connect both monitors with USB-C directly, just to see if that would resolve both the flickering and the RGB issue

@exetico I've been researching more about the image retention issue that you've mentioned, and I've found more articles about it: https://www.eizoglobal.com/support/compatibility/pc/mac/m1m2/

This is what the article above mentions:

Flicker or image burn-in have been reported in some cases when connecting an external monitor to a Mac computer equipped with Apple M1/M2/M3 series chip.

Although the cause of the phenomenon and the conditions under which it occurs are not confirmed, it is thought to be due in part to the fact that the video signals output from Mac computers equipped with Apple M1/M2/M3 series chip behave differently than Mac or Windows computers with Apple Intel chip or Windows PCs.

When displaying certain images or video, the brightness of the screen fluctuates in short cycles, causing flicker or image burn-in occurs, causing images to persist.
The phenomenon may continue even after switching to another image or signal input.

The video signal output from the Mac computer with Apple M1/M2/M3 series chip is fluctuating in several frame cycles, which may be interfering with the LCD panel control of the external monitor.
Video signal output from a Mac or Windows computer with Apple Intel chip do not fluctuate in this way, so the phenomenon is not likely to occur.

@GetVladimir

My guess regarding why the 2515H worked while the U2722D is that the 2515H defaults to RGB when initializing the HDMI connection.

Good point. I didn't think of that. The old 2515H's are sold now, so I don't have a option to test them.

From the image you've posted, it's very strange that they have what looks like image retention, even on the Dell diagnostic screen.

If possible, it might be a good idea to connect both monitors with USB-C directly, just to see if that would resolve both the flickering and the RGB issue

There's quite a few threads about flickering Dell screens in combination with Apple Arm Silicon. I've also done the same things, as recommended in the article you're recommended. But, sadly I'm still having a hard time.

I'm wondering if there's any ways to enforce the RGB, as the YPbPr flickering are a real pain.

Thank you for your inputs, btw! It's a good idea to test with a USB-C > DP, so I'll do that in the next week. I'm not really sure what to do next. It's crazy that a popular display like the Dell Ultrasharp and the M1 doesn't play nice together, and Dell didn't even manage to mention that while I tried to talk with their support team.

@exetico thank you for the reply.

Other monitors seem to have the flickering issue as well, including Benq and Samsung.

The issue is very likely in the Apple Silicon, since all other Macs, PCs and devices work properly with those exact same monitors.

Dell also have a support page about this issue: https://www.dell.com/support/kbdoc/en-us/000218313/flicker-on-dell-monitors-connected-to-mac-s

Thanks for the research and guide! I was going insane of the blurred text on a new Samsung G7 monitor connected through HDMI to my m1 MBP. However, I cannot get the tricks to work - tried following the guide and using the scripts that wrap the same steps. I apparently have the multi-configuration (I don't know why). So the following hint applies to me:

Note that there might be multiple instances of the PixelEncoding and Range keys in the same file, one for each output of your monitor and for different AirPlay devices. You might need to update the integer on each one to get RGB color output on all displays.

Can you elaborate the "update the integer on each one"? Should the range integer be incremented for each? I tried setting both to 1 and then setting the first to 1 and the next to 2. Same result (blurry text). Are there anything else to try in this scenario?

Note that the blurry text is the only indication of the RGB issue as I cannot find any system information that tells if the signal is RGB or not. But I have tried disabling font smoothing etc (was already done years ago I think), to no avail - and all looks crisp on my old USB-C connected LG display.

Thanks in advance!

@gammelby thank you so much for your comment.

You're right, if there are multiple instances of the DisplayConfig and CurrentInfo, you will need to add the PixelEncoding and Range manually to each one.

You don't need to change the values. They can be exactly the same as the first instance.

If it's easer, you can make a backup and just delete the Displays plist file. It should be recreated again after reboot and resolution change, and it should not have as many duplicated instances.

Regarding the indicator whether RGB color output is enabled or not, the easiest way is indeed if your monitor's built-in menu shows it.

If it doesn't, you can sometimes determine it by going to System Settings > Displays > Color Profile and see if any profiles starting with SD or HD show up as compatible with your monitor (shown above the horizontal line in the list). If they are, you are running in YCbCr mode. If only your Monitor Color Profile is above the line, then it's usually RGB Color Output. This is not always a reliable indicator though.

If nothing else works, it might be for the best to look for an USB-C to DisplayPort cable and connect the monitor with it instead of the HDMI.

@GetVladimir thanks for your message and the hints, I will take a look!

I tried everything, and ended up ordering a Lenovo DisplayLink dock (40AF). Crazy and unnecessary cost, and extra delay. But as it's only running in RGB, my combination now works. If someone finds a good way to do this, I'd be happy to revert back, however, right now, I don't want to spend more time on it. I don't get why Apple does not give more control to the user, to enforce the usage of RGB 🙃 ...

@gammelby you're welcome. Let us know how it goes.

@exetico thank you for the update and glad to hear that it works with the DisplayLink dock.

You're right, it would be so easy for them to add an option menu to choose between RGB and YCbCr, same as they already have on the Apple TV Settings.

At the very least, it should be set to default to RGB whenever possible.

I finally got this working. The trick for me was to make the edit in thebyHost folder file instead of the suggested one. This file seems to override everything else and deleting it doesn't work because it also loses my display settings (e.g scaling, arrangement, refresh rate...). If I then set my settings back to what I need, the file gets regenerated so it overrides the changes I made to the top level plist file.

What I also found very confusing was figuring out what the right display to apply the fix to is. This is complicated because plugging in the same display via different methods (HDMI, usb hdmi dongle, usb) causes the system to create separate entries that look correct but aren't. What worked for me was using Color Sync Utility.app to get the UUID of the display the system is currently using, then looking for the entry in the file that matches and making the changes there.

@albertmonzo thank you so much for your comment and glad to hear that you got RGB Color Output working.

That is a great suggestion for using the built-in Color Sync Utility.app to determine which is the correct UUID of the monitor port that needs to be modified.

And you're right, each port or connection of the monitor has a different UUID.

To clarify, it's not just different ports of the monitor, but even different ways of connecting to the same port. In my case, most of the confusion happened because I had previously connected the monitor via HDMI directly to the HDMI port, but I'm now using a usb-c to HDMI cable (to get 4k@120hz on an M1 Pro). The act of having connected it before created this separate entry that looks identical except the UUID is different...

@albertmonzo thank you for the clarification and additional info.

You're right. That also explains why people that use a dock sometimes seem to get a different UUID on every reconnect, which make is really difficult to modify the correct entry for RGB

Not sure if it was mentioned before, but for those suffering from the blurry image issue on external displays with an M1/M2/M3/.. MBP and DisplayLink-based dock station - enabling "Experimental 3008x and 2560x modes" option in DisplayLink seems to do the trick (https://support.displaylink.com/knowledgebase/articles/1993915)

@maxskorr thank you for your comment and the info.

I haven't seen this feature before. Good info to know for anyone using a DisplayLink based Dock.

Forcing RGB Color Output still seems to work with the original procedure of modifying the plist files

No, it doesn't. I followed the instructions to the letter on Sonoma and it didn't do shit. The "alternate" method was also a waste of time. Stuck with shitty TV colours on a desktop monitor because I'm forced to use the worst operating system ever conceived.

@GetVladimir

Thx for this guide, this is helpful, although I still couldn't make it work :/

A couple of problems:

Copy and paste the missing LinkDesription Key under the current display

How do I find "current display"? I have (for some unknown reason) 27 CurrentInfos:

/Users/janbet  > plutil -convert xml1 -o - /Library/Preferences/com.apple.windowserver.displays.plist | grep CurrentInfo | wc -l     
      27

(I would love to just reset my display settings to factory settings, but if I remove this file then it is again there after reboot, because the same file is in /System/Volumes/Preboot/[many characters]/Library/Preferences directory and I guess it's copied from there. Any solution to this?)

Also, regarding this method - I see message File Doesn't Exist, Will Create: /Users/janbet/Library/Preferences/ByHost/com.apple.windowserver.displays.*.plist and things still don't work (after reboot). I have a new file in my user Library/Preferences/ByHost that has this single LinkDescription somewhere but otherwise is a copy of the file from /Library/Preferences directory.

I have M3 Pro + Sonoma 14.4.1.

@johny-b Thank you so much for your comment and I'm glad if the guide is helpful.

If you use a dock, it's very possible that it creates a new current display or UUID every time you connect the M3 Pro to it.

There is an excellent suggestion by @albertmonzo here that suggests to use the Color Sync Utility.app in order to find the UUID of the current connection.

Although, if it keeps changing the UUID, it's likely that it won't work after reboot or reconnect. If possible, it might be for the best to use a dedicated USB-C to DisplayPort cable for the Monitor, even if you need to plug 2 cables each time.